Arquitetura de aplicativos para Smart Devices O problema que vamos resolver será a construção de um backend para uma imobiliária. Ele deve ter uma parte web e outra para Smart Devices, para ser utilizada pelos agentes imobiliários em seu trabalho móvel. Para isso, criamos uma KB; a transação Property para registrar as propriedades imobiliárias em venda ou aluguel, e definimos que o backend web será gerado em Ruby.
Para implementar a parte de Smart Devices, aplicamos o padrão Work With for Smart Devices à transação Property, e criamos um objeto Dashboard como ponto de entrada. Decidimos, num primeiro momento, gerar só em Android, a plataforma automática. Para pensar a arquitetura por trás das soluções para Smart Devices com GeneXus, devemos partir do conhecido: os aplicativos Web. Temos, de um lado, um Servidor e, do outro, um cliente. No servidor temos o aplicativo web e, no cliente, um Browser. Executamos o aplicativo Web a partir de uma URL, por exemplo, a da home page, web panel, ou, a título de exemplo, a de transação para registrar propriedades imobiliárias. Provavelmente, o objeto requerido deverá consultar a base de dados. Em seguida, devolve a informação ao cliente, para que o Browser arme o layout (HTML) que se apresentará ao usuário como resposta a seu pedido.
Uma possibilidade seria executar o aplicativo no Smart Device como um aplicativo Web Mobile, através do Browser do dispositivo. Mas, se queremos que o aplicativo seja nativo, interagindo com as funcionalidades do dispositivo (como a agenda de contatos, o calendário, o GPS) e que tenha um look & feel similar ao resto dos aplicativos nativos do dispositivo, devemos encontrar outra solução. Suponha que alguns dos objetos do aplicativo que processam e desenvolvem dados estruturados (ou seja: transações, procedimentos e data providers) possam ser consumidos por outros programas diferentes. Para isso, uma boa alternativa, se queremos um intercâmbio leve, é pensá-los como recursos (com o que estaremos dentro da arquitetura de desenho Rest) e exibi-los como Web Services Rest. Desta forma, qualquer programa, conhecendo a URL de qualquer deles, poderá chamá-los através do protocolo http (com os métodos GET, POST, PUT e DELETE de acordo com o correspondente). O serviço será executado no Server, chegando à base de dados e devolvendo
como resposta ao Cliente um arquivo com a representação do recurso (no formato JSON). O cliente deverá saber decodificar esse JSON para agir conforme seus requerimentos. Por exemplo, se o pedido for um data provider que no JSON devolve a lista de propriedades imobiliárias, ele deve aparecer na tela do Smart Device. Por tanto, a recuperação e manipulação de dados nos dispositivos será através de serviços Rest. --------------------------------------------------- Demo Recordemos que ao aplicar o padrão Work With a uma transação criava-se automaticamente o Business Component, exibindo-o como serviço Rest. Além disso, criará automaticamente data providers para recuperar a informação do nó List, e também o Detail de cada Seção do mesmo, que também serão expostos como serviços rest. Agora, vejamos, não é um browser. Então, que aplicativo é o que pede estes serviços Rest a partir do dispositivo? E sabe decodificar os JSON recebidos para em seguida desenhar a tela que aparece para usuário? E onde se encontra a informação de desenho de layout, que permite aparecer na tela a informação extraída do JSON seguindo esse desenho? Temos duas opções: executar uma espécie de Browser especial criado pela Artech, conhecido como KBN, ou instalar o aplicativo compilado. Estudaremos ambas as alternativas.
Em ambos os casos, será mantida uma metadata com a informação dos objetos que compõem o aplicativo para Smart Devices, seus layouts, as URLs (Urls) dos serviços Rest que devem ser chamados para conseguir as informações, etc. Concluindo, a informação dos padrões work with, assim como os dos dashboards e painéis para Smart Devices estarão encapsulados nesta metadata. Comecemos pela primeira opção nomeada: utilizar o KBN, Knowledge Base Navigator É um intérprete leve instalado no dispositivo, que é baixado do market place correspondente a cada plataforma. Tem capacidade para: Ler a metadata e as imagens do aplicativo (que, com esta solução, estarão no servidor web) utilizando a arquitetura Rest (através dos requests http correspondentes) e executar os web services Rest que sejam necessários, obtendo os arquivos JSON com as respostas e os dados e, a partir da metadata lida e dos dados devolvidos, criar a interface no dispositivo. Também é capaz de interpretar algumas ações que o usuário dispara ao operar com o aplicativo (tocando ou escolhendo alguma opção do menu) e produzir novos requests ao servidor para satisfazer as necessidades manifestadas pelo usuário.
Portanto, o KBN permite aos usuários navegar através dos aplicativos para Smart Devices criados com GeneXus. Dado que mostra as URLs correspondentes a objetos main do aplicativo, permitindo assim chegar à metadata (presente no servidor) e trabalhar com as entidades e relações envolvidas. Por exemplo, lê na metadata a informação do Dashboard da URL escolhida (as imagens que deve utilizar neste caso, uma correspondente à única opção), o texto da opção e a quem deve chamar ao clicar sobre a mesma e, com base nisso, cria e mostra a interface no dispositivo. Quando o cliente clicar sobre a opção, na metadata, junto com toda a informação de desenho, vem a URL para executar o recurso: o data provider correspondente à List de propriedades. Por isso, o KBN o executa via http Rest e a resposta é um JSON, com a lista de propriedades, que cria dentro da interface, cujo desenho extraiu da metadata na primeira instância. --------------------------------------------------- Demo Ao clicar F5, como temos um único objeto para Smart Devices o dashboard RealEstate que havíamos criado será aberto no emulador o Knowladge base navigator com uma única URL para selecionar: a correspondente a esse dashboard. Clique sobre a mesma e veja que o dashboard é carregado com a única opção que tinha configurada.
Outra alternativa, que é a que utilizaremos quando desejarmos colocar em produção, é encapsular a URL correspondente ao ponto de entrada do aplicativo (por exemplo, o dashboard), junto com toda a lógica do KBN e a metadata, em um arquivo compilado na linguagem do dispositivo e descarregar e instalar esse compilado. Desta forma, não será requisitada do KBN, e apenas deverá chegar ao server para executar os Rest Web Services que manipulam os dados (dado que a metadata estará incluída no pacote compilado e instalado no próprio dispositivo). Cada plataforma de Smart Devices tem sua própria linguagem e, portanto, sua própria extensão para o arquivo compilado. Agora: como obtemos o compilado? Indicando nas propriedades do gerador Smart Devices qual é o Startup object. Fazendo isso, no próximo F5 GeneXus entenderá que deve compilar o aplicativo. Particularmente para ios, será requisitado um Mac conectado em rede com o PC de desenvolvimento. Veremos isso em outro vídeo. --------------------------------------------------- Demo Assim, configuremos para o gerador de Smart Devices o Startup Object desejado: o dashboard RealEstate F5 Como estamos prototipando na nuvem em Android, ao abrir o Developer Menu Web, além de exibir os links para executar o aplicativo web (como de costume), vemos que está aparecendo o QR Code que está encapsulado na URL deste compilado. Desta maneira, tendo um dispositivo Android, através do programa para leitura de QR codes que tiver instalado, é possível ler e descarregar e instalar no próprio dispositivo.
Além disso, como podemos ver, no emulador está sendo aberto automaticamente o objeto Startup Object selecionado, ou seja, o dashboard RealEstate. Devido à arquitetura que acabamos de apresentar com a utilização dos objetos como serviços Rest, em particular das transações expostas como business component, com o qual estamos reutilizando todas as regras do negócio, estamos fazendo uso de toda a potência que o servidor nos oferece. Em outros vídeos, abordaremos os detalhes da prototipação, publicação e produção.