Dispositivos Móveis – av2

- Classes para produção de jogos como por exemplo GameCanvas, Layer, Sprite, TiledLayer e LayerManager.

O conjunto de cinco classes do pacote javax.microedition.lcdui.game forma a Game API, oferencendo poder de simplicidade a criação de jogos para celulares. É composto pelas seguintes classes: GameCanvas, Layer, LayerManager, Sprite, TiledLayer.

A Classe GameCanvas é reponsável pelo ciclo básico do jogo, ou seja, verificar os estados das teclas (se elas foram ou não pressionadas), gerenciar o buffer gráfico e enviar as imagens para a tela.

A Classe Layer tem duas subclasses concretas, a classe Sprite e a TiledLayer.

Em um jogo existe um tipo especial de gráfico chamado Sprite que pode ser um personagem ou um monstro e geralmente eles são animados e sofrem algum tipo de ação. Com a classe Sprite é possível criar uma animação a partir de vários quadros e oferece métodos para a verificação de colisão, rotação e movimentação. A criação de um sprite é simples, basta criar uma classe que estenda a classe Sprite public class Aluno extends Sprite

A classe LayerManager facilita a renderização de objetos Sprite e TiledLayer. Com ela, em vez do programador chamar o método paint() de cada objeto individualmente, ele adiciona ao LayerManager e chamar o método paint() desta classe, que fica responsável por desenhar as imagens na ordem determinada.

---------x------------ High level API:

Em High-level API não é permitido o desenho na tela, como é feito na Low-Level API (Canvas) onde é possível fazer desenhos no formato que você desejar, mas na High-level API temos algumas facilidades como, Alert, List, TextBox e Form que herdam da classe screen, veja no gráfico abaixo como é composta a High-Level API.

O ciclo de vida de uma MIDlet possui pauseApp(), startApp() e destroyApp().

Itens de um form:

ChoiceGroup: é uma lista de escolha, podendo ser múltiplo ou exclusivo.

DateField: Field para data e/ou hora.

ImageItem: mostra uma imagem instanciada anteriormente.

StringItem: mostra um texto simples.

Command: através dele que os botões são controlados.

Adicionar comando à interface: form.addComand(command);

Para sua aplicação responder aos comandos do Command você deve utilizar o setCommandListener() associado ao seu display: form.setCommandListener(this);

Alert : mensagens de alerta

List:lista uma sequência de textos e/ou imagens.

TextBox: é um campo de texto que ocupa a tela toda.

-------------------------x--------------------

- Classe Canvas:

É uma classe estendida de Displayable, que nos permite trabalhar livremente com gráficos em mais baixo nível; é uma classe para aplicações que necessitam manipular eventos de baixo nível e realizar chamadas para desenhar no display.

A partir da classe Graphics é que podemos desenhar figuras primitivas, imagens e textos em qualquer lugar dentro do espaço de resolução da tela do dispositivo. Também é a partir de Canvas que podemos desenvolver animações como jogos e apresentações, usando-se de recursos de Threads (processamento concorrente).

A classe Canvas necessita que o desenvolvedor implemente o método paint(), que recebe como parâmetro um objeto da classe Graphics e é o sistema quem chama esse metodo. Pode-se forçar a renderização da tela chamando o método repaint(). Em uma animação esse método fica dentro de um laço, renderizando a sequência da animação. Isso que dá movimento ao jogo.

Estratégias de controle de movimentação que podem ser adotadas em um jogo: dependentes de frame (quadro); dependentes de tempo; dependentes de evento; sendo a dependente de tempo a mais importante para games.

Como em outras subclasses de Displayable, a classe Canvas permite que a aplicação registre um listener para comandos, porém ela precisa ser uma subclasse.

-----------------------x------------------------ Web Service para comunicação com dispositivos móveis (padrão de mensagens e comunicação):

É uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis.

Os web services são componentes que permitem às aplicações enviar e receber dados em formato XML.

O Web Service faz com que os recursos da aplicação do software estejam disponíveis sobre a rede de uma forma normalizada.

Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efetuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes.

Os Web Services são utilizados para disponibilizar serviços interativos na web, podendo ser acessados por outras aplicações, como por exemplo, o protocolo SOAP.

O objetivo dos Web Services é a comunicação de aplicações através da Internet.

SOAP – Protocolo Simples de Acesso a Objetos - é um protocolo para troca de informações estruturadas em uma plataforma descentralizada e distribuída. Ele se baseia na Linguagem de Marcação Extensível – XML – para seu formato de mensagem, e normalmente baseia-se em outros protocolos da camada de aplicação.

SOAP pode formar a camada base de uma pilha de protocolos de web services, fornecendo um framework de mensagem básico sob o qual os serviços web podem ser construídos. Este protocolo baseado em XML consiste em três partes:

-um envelope que define o que está na mensagem e como processá-la

-um conjunto de regras codificadas para expressar instâncias do tipo de dado definido na aplicação

-uma convenção para representar chamadas de procedimentos e respostas.

O diagrama abaixo mostra as mensagens trocadas entre cliente e servidor em uma comunicação SOAP. Existem duas aplicações se comunicando, um Clinet Wrapper e um Server Wrapper que estão disponibilizando a transparência para as aplicações. Entre eles só trafega XML, seguindo o protocolo SOAP sobre HTTP.

---------------------------x----------------------- Classe RecordStore:

Assim como em aplicações desktop, as aplicações desenvolvidas para dispositivos portáteis podem, em determinadas situações, necessitar armazenar de forma mais “segura” ou menos volátil determinados tipos de dados por elas produzidas. Um porém é que todo esse trabalho deve ser feito levando-se em consideração as limitações existentes nos dispositivos portáteis. A solução oferecida por JME para o armazenamento de informação em memória não volátil é o RMS (Record Management System) o Sistema de Gerenciamento de Gravação.

O RMS trabalha persistindo as informações geradas pela aplicação em uma espécie de tabela ou arquivo(RecordStore) e posteriormente recorrendo a ela(s) para recuperar as informações necessárias.

Uma forma de se imaginar o RMS é como uma tabela composta de linhas sendo que cada uma dessas linhas irá possuir um identificador, uma chave, através da qual os registros serão recuperados. Cada linha dessa tabela nós chamamos de Record, sendo que cada Record composto por um id (chave), que é um inteiro, e um array de bytes onde são armazenados os dados. Essa tabela composta  por Records chamamos de RecordStore.

Antes de tudo, a classe RecordStore não possui construtor. A obtenção de um RecordStore se dá através do método openRecordStore(String nome, boolean criarCasoNãoExista). Nesse método o parâmetro nome se refere a identificação do RecordStore e o criar trata da opção de que seja criado um RecordStore com aquele nome, caso ainda não exista nenhum.

closeRecordStore():serve para fechar um RecordStore aberto.

deleteRecordStore(String nomeDoRecordStore): Esse método é utilizado para se apagar um RecordStore.

As operações para manipulação do record store são:  

Adicionar um registro Deletar um registro Alterar um registro Recuperar um registro Enumerar todos os registros