Projeto - JEDI - Desenvolvimento - de - Aplicações - Moveis - Java - 164 - paginas, Manuais, Projetos, Pesquisas de Informática

Baixe Projeto - JEDI - Desenvolvimento - de - Aplicações - Moveis - Java - 164 - paginas e outras Manuais, Projetos, Pesquisas em PDF para Informática, somente na Docsity!

Módulo 5

Desenvolvimento de Aplicações Móveis

Lição 1

Introdução

Versão 1.0 - Set/

Autor A. Oliver de Guzman Equipe Rommel Feria John Paul Petines Necessidades para os Exercícios Sistemas Operacionais Suportados NetBeans IDE 5.5 para os seguintes sistemas operacionais:

• Microsoft Windows XP Profissional SP2 ou superior
• Mac OS X 10.4.5 ou superior
• Red Hat Fedora Core 3
• Solaris™ 10 Operating System (SPARC® e x86/x64 Platform Edition) NetBeans Enterprise Pack , poderá ser executado nas seguintes plataformas:
• Microsoft Windows 2000 Profissional SP
• Solaris™ 8 OS (SPARC e x86/x64 Platform Edition) e Solaris 9 OS (SPARC e x86/x64 Platform Edition)
• Várias outras distribuições Linux Configuração Mínima de Hardware Nota: IDE NetBeans com resolução de tela em 1024x768 pixel Sistema Operacional Processador Memória HD Livre Microsoft Windows 500 MHz Intel Pentium III workstation ou equivalente 512 MB 850 MB Linux 500 MHz Intel Pentium III workstation ou equivalente 512 MB 450 MB Solaris OS (SPARC) UltraSPARC II 450 MHz 512 MB 450 MB Solaris OS (x86/x Platform Edition) AMD Opteron 100 Série 1.8 GHz 512 MB 450 MB Mac OS X PowerPC G4 512 MB 450 MB Configuração Recomendada de Hardware Sistema Operacional Processador Memória HD Livre Microsoft Windows 1.4 GHz Intel Pentium III workstation ou equivalente 1 GB 1 GB Linux 1.4 GHz Intel Pentium III workstation ou equivalente 1 GB 850 MB Solaris OS (SPARC) UltraSPARC IIIi 1 GHz 1 GB 850 MB Solaris OS (x86/x Platform Edition) AMD Opteron 100 Series 1.8 GHz 1 GB 850 MB Mac OS X PowerPC G5 1 GB 850 MB Requerimentos de Software NetBeans Enterprise Pack 5.5 executando sobre Java 2 Platform Standard Edition Development Kit 5.0 ou superior (JDK 5.0, versão 1.5.0_01 ou superior), contemplando a Java Runtime Environment, ferramentas de desenvolvimento para compilar, depurar, e executar aplicações escritas em linguagem Java. Sun Java System Application Server Platform Edition 9.
• Para Solaris , Windows , e Linux , os arquivos da JDK podem ser obtidos para sua plataforma em http://java.sun.com/j2se/1.5.0/download.html
• Para Mac OS X , Java 2 Plataform Standard Edition (J2SE) 5.0 Release 4, pode ser obtida diretamente da Apple's Developer Connection, no endereço: http:// developer.apple.com/java (é necessário registrar o download da JDK). Para mais informações: http://www.netbeans.org/community/releases/55/relnotes.html

1. Objetivos Nesta lição, discutiremos as características dos dispositivos móveis e a forma de iniciar o desenvolvimento de aplicações para estes dispositivos. Realizaremos uma introdução à Java Platform, Micro Edition (Java ME) incluindo a importância das configurações e perfis. Ao final desta lição, o estudante será capaz de: - Identificar as características dos dispositivos móveis - Descrever a arquitetura JME - Conhecer a personalização das configurações e perfis (CLDC e CDC) - Identificar as bibliotecas fornecidas pelo MIDP - Descrever o ciclo de vida de um MIDlet

2. Dispositivos Móveis Dispositivos móveis podem variar em tamanho, projeto e layout, mas eles possuem algumas características em comum que são totalmente diferentes de sistemas desktop.

• Pequenos em tamanho Dispositivos móveis são pequenos em tamanho. Consumidores desejam dispositivos pequenos pela mobilidade e conveniência.
• Memória Limitada Dispositivos móveis também possuem pouca memória, tanto primária (RAM) quanto secundária (disco). Esta limitação é um dos fatores que afetam a escrita de classes para estes tipos de dispositivos. Com quantidade limitada de memória, devemos fazer considerações especiais acerca da conservação no uso de recursos preciosos.
• Poder de processamento limitado Sistemas móveis não são poderosos como são os sistemas desktop quanto a sua organização. Tamanho, tecnologia e orçamento são alguns dos fatores que influenciam a condição desses recursos. Como o disco de armazenamento e RAM, apenas pequenos pacotes se adequam a estes recursos.
• Baixo consumo de energia Dispositivos móveis possuem baixo consumo de energia em relação às máquinas desktop. Estes dispositivos necessitam poupar o uso de energia, pois possuem um limitado abastecimento através de baterias.
• Robusto e confiável Por serem dispositivos móveis provavelmente serão carregados. Precisam ser robustos o suficiente para suportarem a força de impacto, movimento e ocasionalmente quedas.
• Conectividade limitada Dispositivos móveis têm baixa largura de banda, alguns deles não suportam conexão. Outros destes usam conexões de rede sem fio.
• Curto tempo de inicialização Estes dispositivos inicializam-se em segundos. Tomemos o caso de telefones móveis: eles se iniciam em segundos e as pessoas não ficam com estes desligados mesmo à noite. PDAs inicializam no segundo em que é pressionado o botão de ligar.

3.2 Visão Geral do JME

A Plataforma Java Micro Edition (Java ME) é um conjunto de especificações e tecnologias que têm o foco em dispositivos pessoais. Estes dispositivos têm uma quantidade limitada de memória, menor poder de processamento, pequenas telas e baixa velocidade de conexão. Com a proliferação dos dispositivos pessoais, desde telefones, PDAs, videogames portáteis a aplicações domésticas, Java fornece um único ambiente portátil de desenvolvimento e execução destes dispositivos. Classes JME, assim como todas as classes Java, são interpretadas. Elas são compiladas em byte codes e interpretadas por uma Máquina Virtual Java (JVM). Isto significa que estas classes não são afetadas pelas peculiaridades de cada dispositivo. O JME fornece uma interface consistente com os dispositivos. As aplicações não têm que ser recompiladas para poderem ser executadas em diferentes aparelhos. No núcleo do JME estão uma configuração e perfis. Uma configuração define um ambiente de execução básico para um sistema JME. Isto define as características das bibliotecas principais, da máquina virtual, segurança e comunicação em rede.

Aplicações

Perfis

Pacotes

Opcionais

OEM

APIs

Configuração {

Sistema Operacional do Dispositivo

Bibliotecas

Máquina Virtual Java

Figura 2 : Arquitetura do JME Um perfil adiciona uma biblioteca para certas classes de dispositivos. Os perfis fornecem bibliotecas da API de interface com o usuário, persistência e mensagens, entre outras. Um conjunto ou pacote opcional de bibliotecas que fornecem classes funcionais adicionais. A inclusão destes pacotes no JME pode variar porque depende da capacidade do dispositivo. Por exemplo, alguns dispositivos MIDP não possuem Bluetooth , logo as APIs de Bluetooth não são incluídas nestes dispositivos.

3.3 Configuração

Uma configuração define características mínimas de um ambiente de execução Java completo. Para garantir ótima portabilidade e interoperabilidade entre vários tipos de requisitos de recursos de dispositivos (restrições de memória, processador e conexão), as configurações não contêm as mesmas características opcionais. Uma configuração JME define um complemento mínimo da tecnologia Java. Ela baseia-se nos perfis para definir bibliotecas adicionais (opções possíveis) para uma determinada categoria de dispositivo. Uma configuração define:

• o subconjunto da linguagem de programação Java
• a funcionalidade da Máquina Virtual Java (JVM)
• bibliotecas do núcleo da plataforma
• características de segurança e comunicação em rede

3.4 Perfis

Um perfil define um conjunto adicional de bibliotecas e características de empresas, de categoria, de dispositivo ou de indústria. Enquanto uma configuração define uma base de bibliotecas, perfis definem as bibliotecas que são importantes para construir aplicações efetivas. Estas bibliotecas incluem a interface com o usuário, comunicação em rede e classes de armazenamento.

compilar (javac) pré-verificar verificar (execução) interpretar File.java File.class File.class

Máquina de

Desenvolvimento Dispositivo

Instalação Figura 3 : Processo de Verificação em duas fases

4.4. O Framework Genérico de Conexão (GCF)

O Framework Genérico de Conexão fornece as APIs básicas para conexão em CLDC. Este framework fornece uma base comum para conexões como HTTP, Sockets e Datagramas. O GCF fornece um conjunto genérico e comum de APIs que abstraem todos os tipos de conexão. Note-se que nem todos os tipos de conexões são exigidas para serem implementados em dispositivos MIDP. A hierarquia de interface extensível do GCF torna a generalização possível. Novos tipos de conexões podem ser adicionados neste framework através de extensões desta hierarquia. StreamConnectionNotifier Connection DatagramConnection InputConnection OutputConnection StreamConnection ContentConnection Figura 4 : A Hierarquia de Conexão GCF

5. CDC A Configuração de Dispositivo Conectada (CDC - Connected Device Configuration ) é um super- conjunto da CLDC. Ela provê um ambiente de execução Java mais amplo que o da CLDC e é um ambiente mais próximo do da JSE. Figura 5 : Visão da CDC A Máquina Virtual Java CDC (ou CVM) é uma Máquina Virtual Java completa. A CDC contém todas as APIs da CLDC. Ela provê um subconjunto maior das classes da JSE. Como a CLDC, a CDC não define nenhuma classe de interface com o usuário. As bibliotecas de interface com o usuário são definidas pelos perfis desta configuração. As classes incluídas na CDC vêm dos seguintes pacotes: - java.io - java.lang - java.lang.ref - java.lang.math - java.net - java.security - java.security.cert - java.text - java.util - java.util.jar - java.util.zip CDC também inclui o Framework de Conexão Genérica. Ela requer tipos de conexão adicionais como suporte para arquivo e datagrama.

7. MIDP O Perfil de Dispositivo de Informação Móvel (MIDP - Mobile Information Device Profile) é contruído sobre a CLDC. Não se deve escrever aplicações móveis úteis apenas usando as APIs CLDC. É na MIDP que as APIs de interface com o usuário são definidas. A especificação MIDP, assim como a CLDC e outras APIs, foi definida através do Java Community Process (JCP). Foi envolvido um grupo de profissionais de mais de 50 empresas, composta de fabricantes de dispositivos móveis, operadoras e desenvolvedores de software. A MIDP está continuamente evoluindo, com futuras versões passando pelo mesmo rigor do processo do JCP. Versões futuras do MIDP terão compatibilidade com as versões anteriores, como no caso do MIDP1 e MIDP 2.0. A especificação MIDP define que um dispositivo MID deve ter as seguintes características, no mínimo: - Visor: - Tamanho da Tela: 96x - Profundidade do Visor: 1-bit - Pixel aspect ratio : aproximadamente 1: - Entrada: - Um ou mais dos seguintes mecanismos de entrada: teclado de uma mão, teclado de duas mãos ou tela de toque - Memória: - 256 kilobytes de memória não volátil para a implementação MIDP, mais o que for requerido pela CLDC - 8 kilobytes de memória não volátil para os dados persistentes criados pela aplicação - 128 kilobytes de memória volátil para o ambiente Java (ex. Java heap ) - Rede: - Sem fio, duas vias, possivelmente intermitente, com largura de banda ilimitada - Som: - A habilidade de tocar sons, via hardware dedicado ou via software MIDP define o modelo de aplicação, a API de interface com o usuário, o armazenamento persistente e a rede, API de mídia e jogos, políticas de segurança, entrega da aplicação e provisionamento over-the-air.

8. MIDlet Uma aplicação MIDP é chamada de MIDlet. O software de gerenciamento da aplicação (AMS - Application Management Software ) do dispositivo interage diretamente com o MIDlet com os métodos de criar, iniciar, pausar e destruir o MIDlet. O MIDlet é parte do pacote javax.microedition.midlet. Necessita estender a classe MIDlet. E pode requisitar parâmetros do AMS conforme definido no descritor da aplicação (JAD – Java Application Descriptor ). Um MIDlet não utiliza o método public static void main(String[] args). Caso possua, este não será reconhecido pelo AMS como o ponto de início do programa.

8.1. Ciclo de Vida do MIDlet

A vida de um MIDlet começa quando ele é instanciado pelo AMS. Ele inicialmente entra no estado pausado após ser criado com comando new. O AMS chama o construtor público sem argumento do MIDlet. Se uma exceção ocorrer no construtor, o MIDlet é colocado no estado destruído e é descartado imediatamente. O MIDlet entra no estado ativo depois de se chamar o método startApp () pelo AMS. O MIDlet entra no estado destruído quando o AMS chama o método destroyApp (). Este estado também é atingido quando o método notifyDestroyed () retorna com sucesso para a aplicação. Observe que o MIDlet entra no estado destruído somente uma vez no seu tempo de vida. Ativo Pausado Destruído destroyApp() destroyApp() startApp() pauseApp() new Figura 7 : Ciclo de Vida do MIDlet

8.2 MIDlet Suites

As aplicações de MIDP são empacotadas e entregues aos dispositivos como MIDlet suites. Um MIDlet suite consiste em um Arquivo Java (JAR) e, opcionalmente, um descritor de aplicação Java (JAD). Um arquivo JAD é um arquivo texto contendo um conjunto de atributos, alguns dos quais são requeridos.

Módulo 5

Desenvolvimento de Aplicações Móveis

Lição 2

Como Começar

Versão 1.0 - Set/

1. Objetivos Nesta lição, escreveremos e construiremos aplicações Java ME utilizando o emulador e empacotador de aplicações. A IDE que utilizaremos será o NetBeans 5.5 (www.netbeans.org) com o pacote adicional denominado NetBeans Mobility Pack 5.5 (pode ser obtido no mesmo site). Uma IDE ( Integrated Development Environment ) é um ambiente de programação com um construtor de GUI, um editor de código ou texto, um compilador e/ou um interpretador e um depurador. No nosso caso, o NetBeans vem também com um emulador de dispositivos. Isto permite ver como o programa parecerá num dispositivo real. Ao final desta lição, o estudante será capaz de: - Entender a estrutura de um MIDlet - Criar um projeto Mobile no NetBeans - Criar e executar um MIDlet no NetBeans

public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void commandAction(Command c, Displayable d){ if (c == exitCommand){ destroyApp(true); notifyDestroyed(); // Exit } } } A seguir, dissecaremos o primeiro MIDlet , focando em cada linha de código: public class HelloMidlet extends MIDlet implements CommandListener { Como dito anteriormente, é criada uma subclasse de MIDlet para criar nosso programa MIDP. Nessa linha, foi criada uma subclasse de MIDlet estendendo-a e dando o nome HelloMidlet. Além disso, implementaremos a interface CommandListener. Veremos sua função mais a frente. Display display; Command exitCommand = new Command("Exit", Command.EXIT, 1); Alert helloAlert; Estes são os atributos do MIDlet. O objeto Display (existe somente um display associado por MIDlet ) será utilizado para desenhar na tela do aparelho. O objeto exitCommand é um comando que poderemos inserir na aplicação, por exemplo, para que possamos finalizar o programa. Se não fosse colocado qualquer comando de saída, não haveria forma de finalizar um MIDlet de forma normal. Este será montado da seguinte forma: public HelloMidlet(){ helloAlert = new Alert( "Hello MIDlet", "Hello, world!", null, AlertType.INFO ); helloAlert.setTimeout(Alert.FOREVER); helloAlert.addCommand(exitCommand); helloAlert.setCommandListener(this); } O construtor inicializa o objeto Alert. A classe Alert será discutida nas próximas lições. O método addCommand () do objeto Alert mostra um comando "Exit" na tela. O método setCommandListener () avisa o sistema para passar todos os eventos de comando para o MIDlet. public class HelloMidlet extends MIDlet implements CommandListener { O código "implements CommandListener" serve para controlar o pressionamento das teclas e comandos, de forma que o programa seja capaz de manipular eventos de "command". Se a classe implementar a interface CommandListener, deve ser criado o método commandAction(), como se segue: public void commandAction(Command c, Displayable d){ if (c == exitCommand){ destroyApp(true); notifyDestroyed(); // Exit } } Usamos o commandAction () somente para as requisições de saída. Finalizamos a nossa classe utilizando o método notifyDestroyed () se o comando “Exit” for enviado. public void startApp() { if (display == null){ display = Display.getDisplay(this); } display.setCurrent(helloAlert);

Este é o ponto de entrada da nossa classe, uma vez que está pronta para ser iniciada pelo AMS. Lembre-se que o método startApp () pode ser incluído mais de uma vez no ciclo de vida do MIDlet. Se um MIDlet é pausado ( paused ), por exemplo, quando ocorre uma chamada telefônica, neste momento entramos em estado de pausa ( pauseApp ). Após a chamada o AMS pode retornar o nosso programa e executar novamente o método startApp (). O método estático setCurrent (), da classe Display , informa ao sistema que queremos que o objeto alerta seja mostrado na tela. Podemos iniciar o objeto da exibição chamando o método estático getDisplay () da mesma classe. O Netbeans cria automaticamente um Java Application Descriptor (JAD) para o nosso projeto. E insere o arquivo JAD na pasta "dist" localizada na pasta do projeto. Este é um exemplo de arquivo JAD criado pelo Netbeans: MIDlet-1: HelloMidlet, , HelloMidlet MIDlet-Jar-Size: 1415 MIDlet-Jar-URL: ProjectHello.jar MIDlet-Name: ProjectHello MIDlet-Vendor: Vendor MIDlet-Version: 1. MicroEdition-Configuration: CLDC-1. MicroEdition-Profile: MIDP-2. Agora estamos prontos para compilar e rodar o nosso primeiro MIDlet.