Para compreendermos como é o funcionamento destes clients de dispositivos móveis (Windows Mobile, Android, BlackBerry e iOS) do Magic xpa, primeiro temos que voltar no tempo, mais especificamente na versão 1.8 (em Junho/2009) do uniPaaS (hoje, Magic xpa), quando foi lançada a plataforma RIA do Magic.
Dê uma olhada neste post: http://blog.magicsoftware.com.br/?p=2109
A proposta do RIA Magic é permitir que as aplicações Magic xpa possam ser executadas em três camadas: cliente da aplicação, servidor da aplicação e gerenciador de dados.
Na estrutura clássica, original, as aplicações rodavam em duas camadas: cliente da aplicação e gerenciador de dados:
Agora, com o RIA, temos a nova figura do “servidor de aplicação”:
Existem dois ‘deployment modules’ (runTimes) para executar a aplicação.
Um deles, chamado de servidor, roda sem interatividade (em background) e o usuário não tem acesso a ele.
O outro, chamado de cliente, é acessível ao usuário e responsável por toda interface visual, entrada e saída da aplicação.
E o runTime “cliente” conversa com o runTime “servidor” através de um canal de comunicação. Como este canal é baseado nos protocolos HTTP/HTTPS, significa que o “servidor” pode estar localizado tanto na intranet (rede local/vpn), quanto na internet (web).
Daí é que vem o (I) do RIA. Quando o “servidor” está na internet, nós temos uma aplicação “internet”, que no caso do RIA Magic, é livre de web browser: utiliza um client do próprio Magic, nativo da plataforma onde está rodando.
Ok. São dois deployments (runTimes) envolvidos na execução da aplicação (programas/tarefas).
Mas eles não são iguais.
O deployment que ficará do lado do servidor, e será o “servidor da aplicação”, é o runTime completo, full, que possui todos os recursos do produto. Nos sistemas MS-Windows, é o “MgxpaRuntime.exe”. Em outros sistemas, como Linux, Unix, AS/400, etc… ele possui outros nomes.
- Localizar e conectar ao “Servidor da Aplicação”, via HTTP/HTTPS.
- Transferir dados para o ‘Servidor da Aplicação’ (runTime Magic xpa que está do lado do servidor) .
- Receber dados do o ‘Servidor da Aplicação’ (runTime Magic xpa que está do lado do servidor).
- Desenhar as telas dos programas interativos, para o usuário.
- Capturar e processar as ações (teclado & mouse) do usuário.Executar algumas instruções, que não necessitam do ‘Servidor da Aplicação’ (runTime Magic xpa que está do lado do servidor).
Esta última atribuição do runTime cliente da arquitetura RIA do Magic (Executar algumas instruções), trata de um aspecto importante e que merece alguns comentários: o particionamento da lógica de negócio entre o “cliente da aplicação” e o “servidor da aplicação”.
Na arquitetura RIA do Magic, isso é automático, decidido pelo próprio Magic.
Quando se está desenvolvendo um programa/tarefa do tipo “Rich Internet” (que irá rodar nesta arquitetura distribuída – RIA), o Studio do Magic xpa utiliza um sistema de cores para mostrar quais partes do programa serão executadas em um ou outro runTime:
S : Esta instrução será executada do lado do “servidor” (runTime que roda no servidor).
C: Esta instrução será executada do lado do “cliente” (runTime que roda no cliente).
U : Só na hora da execução será decidido se esta instrução rodará no “cliente” ou no “servidor”.
Toda a manipulação de base de dados (leitura/escrita) é feita apenas do lado do servidor, por exemplo. Logo, apenas o deployment Magic do servidor é que se conecta ao Gerenciador de Dados.
Para que esta divisão de lógica (entre cliente e servidor) ocorra na prática, uma cópia do programa/tarefa em execução sempre está nos dois runTimes (servidor e cliente):
Quando o deployment do ‘cliente’ encontra uma instrução no programa, que é do tipo “servidor”, ele interrompe a execução e faz uma chamada (requisição) HTTP/HTTPS até o servidor. Nesta requisição é pedido para que ele (servidor) execute a próxima instrução do programa (o mesmo programa/tarefa também está aberto no servidor), que é de sua responsabilidade. Quando o servidor termina de executar estas instruções, ele avisa ao “client”, que retoma a sua execução (a próxima instrução do tipo “cliente”).
O documento “RIA Tutorial.pdf”, instalado junto com o Magic xpa, explica a respeito desta divisão “server side” e “client side”, e dá dicas que como melhorar a eficiência do particionamento e diminuir a quantidade de requisições que o cliente precisa fazer ao servidor.
Os programas/tarefas Magic são carregados no Magic do Servidor, quando o arquivo .ecf da aplicação é aberto (quando o Magic servidor inicia a executar). Já no Magic do Cliente, eles são baixados (download) à medida que precisam ser executados. O Magic do Ciente possui um sistema interno de cache, para evitar baixar várias vezes o mesmo programa, sem necessidade.
Logo, há três informações importantes aqui:
- A primeira execução de um programa/tarefa é sempre mais lenta que as próximas, devido à necessidade de download do código.
- Programas/tarefas do tipo Rich Internet devem ser pequenos, leves. Basicamente, conter apenas entrada, saída e validação de dados. A lógica “pesada” deve ser colocada em programas/tarefas do tipo “batch”, que são “server side”(rodarão no lado do servidor).
- Os clients RIA do Magic são sempre On-Line: precisam ter uma conexão ativa/válida com o Magic do Servidor, para poderem executar.
Bom, este é um resumo da arquitetura de soluções RIA do Magic xpa.
Mas o que isto tem a ver com os clients para mobile?
Simples.
A base da execução de aplicações Magic, em dispositivos móveis, é a arquitetura RIA. Cada client para dispositivo móvel (Windows Mobile, BlackBerry, Android ou iOS) não é nada além de um “Client RIA Magic”.
O que muda entre eles são as tecnologias usadas no seu desenvolvimento, e a plataforma (sistema operacional) a que se destinam:
| Plataforma de Destino | Tecnologia do Módulo Deployment | Nome do Módulo Deployment |
| MS-Windows | MS .NET FrameWork | MgxpaRIA.exe |
| *Windows Mobile | MS.NET Compact FrameWork | <alguma coisa>.cab |
| *BlackBerry | Java ME | <alguma coisa>.jad |
| *Android | Java | <alguma coisa>.dpk |
| *iOS | Objective-C | <alguma coisa>.ipa |
(*) Sistema operacional para dispositivo móvel
As diferenças entre uma e outra plataforma são muitas.
A tecnologia utilizada para criar um e outro módulo de deployment (runTime), também muda.
Mas a funcionalidade de todos eles (guardadas as restrições específicas de cada plataforma) são as mesmas:
Conectar no Magic do Servidor, transferir dados, baixar programas/tarefas, desenhar telas, capturar teclado, etc…
Esta é a mágica que permite usar uma única ferramenta, um único paradigma de desenvolvimento, e atingir diferentes plataformas (móveis ou não).
Veja um pouco do que o Magic xpa lhe oferece em termos de recursos para desenvolvimento de aplicações:
- Paradigma ágil e eficiente, orientado a metadados.
- IDE (Studio) único
- Particionamento automático de lógica (cliente e servidor)
- Aplicação em três (no mínimo) camadas
- Clients para diversas plataformas, incluindo os principais dispositivos móveis do mercado (Windows Mobile, BlackBerry, Android e iOS)
O Magic xpa é, sem dúvida, uma excelente escolha!
