Exemplo de uma aplicação: venda de ingressos de cinema

Apresentação em tema: "Exemplo de uma aplicação: venda de ingressos de cinema"— Transcrição da apresentação:

1

2 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

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

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

5 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

6 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)

7 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

8 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

9 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

10 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

11

12 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

13 Recursos XML MVC