Exemplo de uma aplicação: venda de ingressos de cinema Funçoes que os usuarios podem ativar usando um dispositivo movel: Criar uma conta com a qual ele possa entrar na aplicaçao Navegar por uma lista personalizada de salas de cinema e horarios de filmes Reservar acentos e comprar ingressos do filme

Fluxo da Aplicaçao Java de venda de ingressos de cinema

Arquitetura de Alto Nivel da Aplicaçao Java de venda de ingressos de cinema

Arquitetura de Alto Nivel da Aplicaçao Java de venda de ingressos de cinema Uma MIDLet oferece a interface com o usuario no dispositivo movel A MIDLet se comunica com um servlet Java via HTTP seguro O servlet despacha as solicitaçoes do cliente para o enterprise beans para gerenciamento de contabilidade, listagem dos filmes e compra de ingressos Os beans acessam uma base de dados atraves da API JDBC

Uso do Padrão MVC para o desenvolvimento da aplicação exemplo Para tirar vantagem das capabilidades do MIDP, a porção cliente da aplicação pode usar o padrão tradicional MVC Modelo Contem os dados para a aplicação (coleção de filmes, salas de exibição, horários de apresentação do filme e plano dos assentos para um filme especifico) Apresentação Contem todo o código relacionado com a apresentação dos dados e a coleta de dados proveniente do usuário (telas com a listagem dos filmes, canvas interativo com o plano de assentos) Controlador Governa o fluxo lógico da interface com o usuário Controla como as interações afetam o modelo de dados e vice-versa Na aplicação exemplo, o controlador pede ao usuário para criar uma conta caso seja sua primeira vez na aplicação Retém uma copia local, persistente do login do usuário Em usos subseqüentes, o controlador prossegue a partir do logon (já sabe que o usuário tem uma conta)

Benefícios do Uso do Padrão MVC Pode aumentar o tamanho do código (grande parte no controlador) – o que e uma desvantagem Separando o controlador do modelo e da apresentação, o fluxo da aplicação e’ isolado desenvolvedores podem entender a perspectiva do usuário apenas olhando o controlador O fluxo da aplicação pode ser alterado modificando-se o controlador sem (ou com pouca) alteração do restante do código Separando o modelo da apresentação, o modelo e isolado de alterações a apresentação Desenvolvedores podem alterar a aparência da interface do usuário sem ter que mudar o modelo Separando a apresentação do modelo, a apresentação e poupada dos detalhes de como funciona o modelo O modelo pode pegar seus dados de um armazenamento local, através da API RMS, de um servidor usando HTTP, de uma cache de memória ou de uma combinação dessas fontes

Mais Benefícios do Uso do Padrão MVC Para usar a rede intermitentemente e ainda permanecer útil quando desconectado, a porção cliente da aplicação deve decidir: Quando buscar os dados do servidor Quando buscar os dados do armazenamento local Estratégias de dados locais podem ser baseadas em cache ou sincronização para melhorar a responsividade e manter a coerência dos dados O particionamento destes detalhes no modelo (do MVC) torna a implementação, teste e manutenção mais fácil do que se estivessem espalhados pela aplicação

Mais restrições para o projeto de aplicações sem fio Oferecer interfaces uteis e utilizaveis frente a tamanho limitado da tela, capacidade de entrada de dados, poder de processamento, memoria, armazenamento persistente e vida da bateria Em termos de conectividade, os dispositivos moveis esperam encontrar: alta latencia largura de banda limitada conectividade intermitente Quais devem ser os objetivos de um cliente MIDP frente a estas restriçoes: Conectar a rede apenas quando necessario Consumir da rede apenas os dados que realmente precisa Permanecer util mesmo quando disconectado

Conectando a porção cliente ao servidor Apesar do MIDP não incluir mecanismos de comunicação cliente-servidor sofisticados (tais como RMI ou JAX-RPC – Java API for XML Based RPCs), desenvolvedores podem projetar um protocolo de mensagem usando o formato e transporte que quiserem Para a maioria das aplicações HTTP funciona adequadamente como a base de um protocolo de mensagem (preferível ao socket e datagrama) Todos os dispositivos MIDP devem suportar HTTP => aplicações sobre HTTP serão portáveis para outros dispositivos Nem todos os MIDPs suportam comunicação baseada em sockets e datagramas => aplicações que as usam podem não ser portáveis HTTP e’ “firewall amigável” => A maioria dos servidores são separados dos clientes moveis através de firewalls. HTTP e um dos poucos protocolos que os firewalls deixam passar As APIS Java de rede facilitam a vida do desenvolvedor MIDP inclui suporte para HTTP 1.1 e APIs para gerar solicitações GET, POST e HEAD,manipulação básica de cabeçalhos, consumo e geração de mensagens baseadas em fluxos API Servlet Java oferece extensa estrutura para tratar solicitações HTTP e gerar respostas

Comunicação entre um cliente MIDP e um Java Servlet O cliente codifica uma solicitação da aplicação e a empacota numa solicitação HTTP O servlet recebe a solicitação HTTP e decodifica a solicitação da aplicação. O servlet ou algum delegado (tal como um enterprise bean) executa o trabalho especificado pela solicitação O servlet codifica uma resposta a aplicação e empacota numa resposta HTTP O cliente recebe a resposta HTTP e decodifica a resposta da aplicação que ela contem. O cliente pode instanciar um ou mais objetos e executar algum trabalho sobre esses objetos locais

Recursos XML http://java.sun.com/webservices/docs/ea1/tutorial/doc/WSPackTutorialTOC.html MVC http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html