Android x JME Alexandre F. Zimmermann - 134669 Ivo E. Seitenfus Neto - 118971

Android x JME

Alexandre F. Zimmermann - 134669Ivo E. Seitenfus Neto - 118971

Características do ambiente de programação para sistemas embarcados

Dispositivos Móveis tem algumas características especiais que devem ser levadas em conta no momento de desenvolvimento, tais como:

Bateria: Aplicações devem ser econômicas, minimizando o uso da CPU quando possível (em inatividade por exemplo);

Execução das aplicações: Elas podem ser interrompidas por chamadas telefônicas ou Mensagens SMS por exemplo. Devemos deixar a aplicação em background, e ter o cuidado de quando ela retornar, manter o estado em que estava, sem prejudicar o usuário.

Memória: Deve ser usada com critério, pois os ambientes embarcados possuem menos memória que os ambientes desktop.

Poder de processamento: Também é limitado em comparação com ambientes desktop.

Usabilidade: O design das aplicações devem ser modelados com cuidado, em muitos casos não temos um teclado qwerty e não existe um mouse.

Interface com o usuário: O design deve ser feito pensando que não temos uma tela de 15 polegadas ou mais a nossa disposição. Existem diversos dispositivos, com resoluções diferentes, teclados diferentes, etc.

Java

A plataforma Java se divide em três edições, cada uma com seus objetivos.Basicamente:

Standard Edition (Java SE) – Computadores Pessoais

Enterprise Edition (Java EE) – Aplicações Corporativas

Micro Edition (Java ME) – Dispositivos móveis

Java EE, SE, METodas as edições são similares no seu nível fundamental

e tem características gerais iguais, como garbage collector automático e plataforma independente através do uso da máquina virtual.

Java Micro Edition tem por finalidade oferecer um framework padrão para desenvolvimento de aplicações Java para dispositivos embarcados, que geralmente tem um ambiente com memória limitada.

Java ME compartilha alguns pacotes com Java SE e Java EE, o que significa que um programador que já saiba programar em Java SE ou EE terá uma facilidade maior para programar em Java ME.

Java

Java Todas as edições são similares no seu nível fundamental e

tem características gerais iguais, como garbage collector automático e plataforma independente através do uso da máquina virtual.

Java Micro edition tem por finalidade oferecer um framework padrão para desenvolvimento de aplicações Java para dispositivos embarcados, que geralmente tem um ambiente com memória limitada.

Java ME compartilha alguns pacotes com Java SE e Java EE, o que significa que um programador que já saiba programar em Java SE ou EE terá uma facilidade maior para programar em Java ME.

Por que Java? Java powers more than 4.5 billion devices including: 850+ million PCs 2.1 billion mobile phones and other handheld devices

(source: Ovum) 3.5 billion smart cards Set-top boxes, printers, Web cams, games, car navigation

systems, lottery terminals, medical devices, parking payment stations, and more.

(http://www.java.com/en/about/)

JME

A plataforma Java ME (antigamente conhecida com J2ME) tem dois subconjuntos de bibliotecas, chamados de Configurações:

CLDC (Connected Limited Device Configuration): Como o próprio nome diz, é mais limitado, pois é direcionado para dispositivos com pouca memória. Usado principalmente em celulares. A máquina virtual (a KVM) é implementada utilizando a linguagem de programação C, existindo algumas diferenças como por exemplo no suporte de operações de ponto flutuante.

CDC (Connected Device Configuration): Mais poderoso que o CLDC, contudo requer mais hardware. Usado em Smartphones, PDA ́s, Set-top boxes, gateways, TV ́s, ...

CDLC x CDC Requerimentos:

# 16-bit or 32-bit CPU com Clock de16 MHz ou superior.

# Pelo menos 160 KB ROM alocados para as bibliotecas e maquina virtual CLDC

# Pelo menos 192 KB RAM disponíveis para a plataforma Java.

Requerimentos:

# 32-bit CPU

# 2.5 Mb ROM alocados para as bibliotecas e maquina virtual CDC

# 2.0 Mb RAM disponíveis para a plataforma Java.

Perfis JME

Um perfil é um conjunto de APIs que auxiliam os dispositivos com diferentes capacidades e recursos. Existem perfis específicos desde máquinas de venda até (set-top boxes). Para telefones por exemplo, MIDP é o mais predominante. O MIDP (Mobile Information Device Profile) é dedicado a complementar a configuração CDLC, sendo responsável pela interação com o usuário(GUI API, Display). É o padrão de facto para jogos de celular.Quase todos os novos telefones já vem com uma implementação MIDP.MIDP foi desenvolvido sobre a Java Community Process.

MIDlet MIDlet é como são chamados as aplicações escritas para o perfil MIDP.

Para ser classificado como MIDlet, a aplicação Java deve:

Estender a classe abstrata javax.microedition.midlet.MIDlet, a qual controla o ciclo de vida da MIDlet.

Ser distribuido em um arquivo Java ARchive (JAR).

Incluir o MANIFEST.MF junto com o .jar

Incluir o arquivo Java Application Descriptor (JAD)

Possuir todos arquivos .class pré-verificados antes do deploy. No Java ME tools atual, a pré-verificação é feita automaticamente durante o processo de construção.

• APIs do MIDlet podem usar pacotes opcionais determinados de acordo com a necessidade da aplicação, mas nesse caso não há garantia de portabilidade.

Threads

• Podem ter níveis de prioridade – As de prioridade alta são executadas com maior frequência.

• A máquina virtual Java associa cada thread viva com uma instância do java.lang.Thread. Essa classe é usada para iniciar novas threads e para ajuste da prioridade. O código pode obter acesso a thread a qualquer momento invocando Thread.currentThread().

Threads – CDC & CLDC

• No CLDC não é suportado thread group (somente podem ser criadas no nível de aplicação) e daemon threads .

• A classe de Threads da CDC, por outro lado, possui todas as funcionalidades da JSE, incluindo suporte para threads em grupo e daemon threads. Ela não é identica a versão JSE porém, pois não inclui métodos obsoletos (deprecated), incluindo aqueles que param ou interrompem threads.

• Para sincronização, podemos utilizar o velho e conhecido synchronized (que atua como monitor).

Threads - CLDCAs threads CLDC's tem somente esses métodos:

activeCount()

currentThread()

getPriority()

isAlive()

join()

run()

setPriority()

sleep()

start()

yield()

Criação de Threads

• Para começar uma nova thread, precisamos de:

• Uma instância de java.lang.Thread.

• Um objeto que implementa a interface java.lang.Runnable.

• A interface Runnable define um método run() sem argumentos e sem valor de retorno.

Criação de Threadspublic class DoSomething implements Runnable { public void run(){ // here is where you do something }}...DoSomething doIt = new DoSomething();Thread myThread = new Thread( doIt );myThread.start();...Vale lembrar que, como visto em aula, também podemos criar threads através extensão

da classe Thread. Não existem diferenças funcionais nos dois métodos, porém ao implementar a interface Runnable em uma classe, nós evitamos o overhead de definir uma classe nova. Esse overhead é minimo, mas estamos em um ambiente limitado, no qual alguns telefones limitam as aplicações JME à 30kb.

RMI

Pode ser usado somente em dispositivos CDC que suportam a JSR 66.

Suporta as operações cruciais do JSE, como exportação de objetos remotos, garbage collector distribuído, etc.

Foram retirados métodos, classes e objetos obsoletos, protocolo de multiplexação RMI, entre outros (de funcionamento secundário)

ANDROID: Introdução

• Plataforma para dispositivos móveis.• Composto por um sistema operacional, um middleware e aplicações chave desenvolvidas em Java.• Construído sobre um Linux Kernel.• Criado pela Google e desenvolvido pela Open Handset Alliance.• Ao contrário do JME, o Android é um sistema operacional, e não um ambiente de execução.

ANDROID: Funcionalidades• Dalvik VM: Máquina virtual otimizada para dispositivos móveis. Não é uma máquina virtual JAVA.• Handset layouts: adaptada tanto para dispositivos VGA como para Smartphones.• Conectividade: Bluetooth, GSM / EDGE, 3G, EV-DO e Wi-Fi.• SQLite para armazenamento de dados estruturados.• Web Browser: baseado na Framework WebKit.• Mídia: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG e GIF.• Suporte a câmaras de vídeo, telas sensíveis ao toque (touchscreen), GPS, bússolas, acelerômetros, e aceleração de gráficos 3D.• Excelente ambiente de desenvolvimento, incluindo emulador, ferramentas para debug. Possui plug-in para a ferramenta de desenvolvimento Eclipse.

ANDROID: Arquitetura

ANDROID: Arquitetura

• Applications: Podem usar elementos de outras aplicações. Sem ponto de entrada padrão, componentes essenciais são instanciados e executados como Activities, Services, Broadcast Receivers e Content Providers.• Application Framework: API utilizada pelas aplicações básicas e aplicações desenvolvidas.• Libraries: Conjunto de Bibliotecas C/C++ utilizadas pelos componentes do sistema Android.• Runtime: Fornece a maior parte das funcionalidades disponíveis nas bibliotecas da linguagem JAVA. Uma instância da Dalvik VM para cada processo, o qual roda uma aplicação.• Kernel: Abstração do Hardware para o Software. O Android confia ao Kernel o núcleo de serviços do sistema como segurança, gerenciamento de memória e processos.

ANDROID: Aplicação

• Cada aplicação possui um XML associado que especifica quais partes compõem a aplicação.• Activities: Interface visual para o usuário que representa uma ação ou funcionalidade específica. Sem relação de hierarquia. Uma activitie pode chamar ou iniciar outra.• Services: Sem uma interface visual. Rodam em background e interagem com as activities.• Broadcast Receivers: Recebem eventos globais, dessa forma as aplicações podem decidir a quais eventos devem responder.• Content Provider: Disponibiliza um determinado conjunto de dados para que as aplicações possam acessá-los quando necessário.

ANDROID: Aspectos de PDP

•Cada instância da máquina virtual Dalvik possui ao menos uma Thread principal rodando quando começa sua execução. Mas tipicamente existem mais de uma thread em cada instância da VM.• Por default, todos os componentes de uma aplicação rodam na mesma thread e processo linux que é dedicado à esta aplicação.• A aplicação deve decidir quando disparar novas threads para tarefas específicas.


• Para a execução de cada componente de uma aplicação é possível criar um processo específico, e dentro deste, o programador decide quando criar novas threads.• Se um componente for executar uma operação dispendiosa, então isto deve ser feito em uma nova thread, a fim de não bloquear todo o programa até o final da operação.• É muito importante que activities que disparem operações dispendiosas façam isso em novas threads, visto que são as activities responsáveis pela interação com usuário e com isso tenta-se evitar a falta de resposta da aplicação.


Threads são criadas usando Java Threads:

private void mainProcessing() {Thread thread = new Thread(doBackgroundThreadProcessing);thread.start();}

private Runnable doBackgroundThreadProcessing = new Runnable() {public void run() {

backgroundThreadProcessing();}

};private void backgroundThreadProcessing() {[ ... operation ... ]


• Threads na mesma VM interagem e se sincronizam por meio de objetos compartilhados e monitores associados com estes objetos. Métodos synchronized e parte da API da classe Object permitem que threads cooperem entre si.• Cada thread possui uma prioridade, que é um inteiro e basicamente determina a quantidade de tempo de CPU que a thread ganha.• Uma thread pode ser uma deamon, o que faz com que ela seja executada em background.

ANDROID: Aspectos de PDP• A Classe Handler permite que sejam enviadas e processadas mensagens e objetos runnable associados com a classe MessageQueue (fila de mensagens) de uma thread.• Cada instância do Handler é associado a uma única thread e com a fila de mensagens dela. Ou seja, as threads podem se comunicar através da classe Handler.• Quando um processo é criado pela aplicação, a thread principal se dedica a executar uma fila de mensagens responsável pelo gerenciamento dos objetos de mais alto nível das aplicações e as janelas por eles criadas.• Outras threads podem ser criadas e se comunicam com a thread principal da aplicação através do Handler. Isto pode ser feito pelos métodos post() e sendMessage(). A mensagem é recebida pela fila de mensagens e processada quando for apropiado.

ANDROID: Aspectos de PDPExemplo de uso do Handler:

// Initialize a handler on the main thread.private Handler handler = new Handler();private void mainProcessing() {

Thread thread = new Thread(doBackgroundThreadProcessing);thread.start();

}private Runnable doBackgroundThreadProcessing = new Runnable() {

public void run() {backgroundThreadProcessing();}

};

ANDROID: Aspectos de PDPExemplo Handler (cont.)

// Method which does some processing in the background.private void backgroundThreadProcessing() {

[ ... Time consuming operations ... ]handler.post(doUpdateGUI);

}// Runnable that executes the update GUI method.private Runnable doUpdateGUI = new Runnable() {

public void run() {updateGUI();}

};private void updateGUI() {

[ ... Open a dialog or modify a GUI element ... ]}


• Outras threads podem ser criadas e se comunicam com a thread principal da aplicação através do Handler. Isto pode ser feito pelos métodos post() e sendMessage(). A mensagem é recebida pela fila de mensagens e processada quando for apropriado.• Por usar as principais funcionalidades das bibliotecas da J2SE, o Android da suporte eficiente para programação multi-thread em dispositivos móveis, utilizando os métodos de criação de thread, mecanismos de sincronização e troca de mensagens entre as threads.

ANDROID: Aspectos de PDPSincronização

• A implementação de monitores é como na J2SE, com um monitor associado a cada objeto, e utiliza a mesma semântica de wait() e notify().• A biblioteca java.util.concurrent.* presente no Android possui a implementação de lock e semáforos, e a semântica é a mesma utilizada na J2SE.• A sincronização por troca de mensagens (classe Handler) também pode ser feita entre as threads.


• Pela necessidade de comunicação entre processos o Android da um suporte simplificado a RPC via passagem de objetos entre processos diferentes.• É simplificado por que o processo remoto deve estar rodando no mesmo dispositivo do processo local e não em um dispositivo remoto.• Android Interface Definition Language (AIDL) é a ferramenta para o desenvolvimento da interface de RPC. É ela quem se encarrega de criar interfaces para que dois processos se comuniquem via objetos.


• Tipicamente o Processo remoto é gerenciado por um componente do tipo service. • As chamadas remotas são síncronas, ou seja, o processo local fica bloqueado até receber a resposta do processo remoto.• O Android possui algumas das principais bibliotecas da J2SE, mas não todas. No site do Android developers não foi encontrada nenhuma referência a biblioteca java.rmi e portanto o Android não da suporte a RMI.

Android x JMEAspectos Básicos

JME não é dedicado somente a celulares como visto anteriormente, ao contrário do Android.

Dessa forma, o Android possui uma interface gráfica muito mais poderosa que o JME, pois seu sistema operacional (responsável pela GUI) está logo acima da camada de hardware.

O JME possui a vantagem da portabilidade. O MIDP é muito usado para jogos de celular, e compatível através da máquina virtual java com vários sistemas operacionais, ao contrário de um jogo desenvolvido para a plataforma Android.

Android x JMEProgramação paralela

Por ser um sistema operacional completo, o Android tem vantagens na programação paralela, na medida que podemos ter threads e processos. Pode instanciar várias máquinas virtuais.

No JME, temos somente uma instância da máquina virtual, desse modo podemos trabalhar somente com threads, sendo que ainda existem algumas limitações na CLDC(daemon e group threads).

Conclusões(óbvia) O Android é um sistema operacional completo, podendo

possuir mais de uma máquina virtual, enquanto o JME é apenas uma máquina virtual.

O Android é uma plataforma mais restrita, na medida que podemos usar JME para outras finalidades além de dispositivos móveis(TVs, Set-top boxes, máquinas de venda, etc).

JME também é mais amplo visto que pode ser usado em celulares de baixo custo, ao contrário do Android, que visa (ao menos por enquanto) celulares mais possantes.

O Android não é compativel com aplicativos MIDP, porém já existem emuladores e/ou conversores para plataforma Android.

Bibliografia http://www.forum.nokia.com/document/Java_Developers_Library_v2/?content=GUID-

356142DC-B0EF-48C1-88A8-3F556B7A313F.html

http://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition

http://en.wikipedia.org/wiki/Mobile_Information_Device_Profile

http://en.wikipedia.org/wiki/Connected_Device_Configuration

http://en.wikipedia.org/wiki/Connected_Limited_Device_Configuration

http://java.sun.com/products/rmiop/overview.html

http://www.android.com/

http://developer.android.com/guide/index.html

http://pt.wikipedia.org/wiki/Android

Documents

Android x JME Alexandre F. Zimmermann - 134669 Ivo E. Seitenfus Neto - 118971