sexta-feira, 16 de março de 2012
Java MIDP 3.0 - O que há de novo ?
É indiscutível o êxito do Java no mundo móvel. Principalmente na esfera das relações econômicas de celulares, o Java ME tornou se bastante rápido um conjunto dos processos especiais relativos a tecnologia de programação padrão nesses dispositivos. O desenvolvimento de aplicativos móveis com Java é ágil, percorre em grande extensão e produtivo.
Os fabricantes pregam aplicativos móveis com Java ME em seus aparelhos desde quando saem dos estabelecimentos. Alarme, relógio mundial, calculadora, e agenda são só alguns exemplos básicos. E as operadoras valorizam os aparelhos celulares que vendem complementando com softwares Micro Edition como games e até gerenciadores de paginas pessoais. Acrescentando ainda que as empresas tem sugado as possibilidades de colocar softwares em dispositivos móveis que podem estar sempre on- line na internet,e criaram programas que possibilitam a venda de produtos, execução de serviços, gerenciam entrega de mercadorias,entre outros.
Tamanho êxito move a indústria e os padrões e o MIDP (Mobile Information Device Profile,que é para muitos a principal especificação Java ME,está chegando sua terceira versão,com muitas novas funcionalidades. Sua especificação está aberta como de praxe para que a comunidade discuta e revise os recursos apresentados.
Não podemos falar de MIDP (MOBILE INFORMATION DEVICE PROFILE) sem falarmos um pouco sobre o que é CLDC.
CLDC (CONNECTED LIMITED DEVICE CONFIGURATION)
Seu objetivo principal é definir uma plataforma JAVA padrão mínima para dispositvos microprocessados.
É uma tecnologia core que será usada para um ou mais perfis, a exemplo o perfil J2ME.
É incentivada principalmente pelos desenvolvedores que cada vez mais querem produzir softwares de forma rica e dinâmica para estes tipos de dispositivos.
NOVIDADE
O MIDP 3.0 prossegue incluindo todos os pequenos dispositivos móveis, desde os celulares mais básicos até PDAs.O Requisito de memória volátil mínima pra o runtime o Java(o heap) é de 1 megabyte, bem mais que os 32kb e 128kb exigidos nas versões anteriores do MIDP.Mesmo sendo bem maior a relaçao às versões 1.0 e 2.0,esse número já se ultrapassou na maioria dos dispositivos high-end que trabalham com MIDP2.0;por outro lado representa uma quantidade bem superior aos dispositivos low-end atuais.Em relação ao tamanho da tela,a exigencia mínima para o MIDP 3.0 é de 176x220 pixels,uma área extremamente grande visto que vários dos celulares com custos mais elevados de hoje e com baixa ou sem resolução. O mínimo exigido na configuração para poder utilizar MIDP 3.0 ainda é o bom e o conhecido CLDC1. 0. Porém recomenda se o CDLDC1.1, e a especificação permite a implementação sobre esta versão.Outra relevância importante é que os dispositivos que suportarão o MIDP3.0 devem poder rodar também aplicações nas versões 1.0 e 2.0 do MIDP,permanecendo assim a compatibilidade retroativa.
Verificamos a seguir as novas funcionalidades do perfil:
Bibliotecas
O MIDP 3.0 inseriu o conceito de LIBlets.Uma LIBlet é uma biblioteca compartilhada que pode ser usada por um ou diversos MIDlets em tempo de execução.Cada LIBlets contém uma API com interfaces e classes Java que podem ser utilizadas por várias aplicações,como se encontrasse todas em um único arquivo JAR da MIDlet. LIBlets ajudam a diminuir o tempo de download de programas que faça uso de algum código em comum. Em questao de segurança, a Liblet utiliza os mesmos critérios associados ao MIDlet que está sendo rodado ou seja suas permissões de acesso e seu sao iguais a do MIDlet. O conceito de domínios de proteção foi introduzido no MIDP 2.0 e define permissões de acesso a recursos.
Telas de Splash
Uma pequena novidade, mas de grande valor é a facilidade de carregar a tela de splash da aplicação. Em antigas versões MIDP, uma tela de splash era feita normalmente em uma classe separada,estendendo a classe canvas e colocando uma imagem nesse componente.O Controle do tempo mostraando a tela de splash também era manual. A proposta da nova especificação é,através de um atributo no arquivo JAD(descrição do MIDlet estiver sendo executado.A definição do atributo do arquivo JAD é feito da forma:Splash-Screen-image:/imagens/imagemSplash.png
Protetores de tela
Muitos desenvolvedores vinham solicitando há tempos protetores de tela em JavaME. Os protetores de tela propostos no MIDP 3.0 se comportam de maneira bastante parecida com uma aplicação comum, diferencia pelo fato de que o Application Management Software (o software do dispositivo que gerencia o download e o ciclo de vida das MIDlets) carrega o método destroyApp() do MIDlet quando alguma tecla é ativada,ou quando algum evento ocorre.Para declarar um MIDlet como protetor de tela,é usado um novo parâmetro no aquivo JAD que identifica a categoria do MIDlet:
Midlet-1:MeuScreenSaver,/ícone.png,com.jm.MeuScreenSaveMIDlet
MIDlet-category:screenSaver
Midlets concorrentes
As especificações das versões anteriores do MIDP não proibiam executar Midlets concorrentemente, entretanto não tinha nenhum procedimento que descrevesse o comportamento para a concorrência. O MIDP 3.0 estabelece procedimentos básicos no tratamento desse aspecto. Todos são baseadas na execução independente - uma aplicação que está rodando não pode interferir em outra sobre nenhum aspecto: valores de atributos, dados,erros, instancias. Colocando, duas classes contendo o mesmo nome em duas aplicações diferentes devem ser distintas, e uma aplicação não deve usar nem interferir na classe de mesmo nome da outra aplicação. No caso em que dois MIDlets da mesma suíte estejam em execução concorrentemente e ambos tenham referencia para uma mesma classe compartilhada como sendo apenas da própria aplicação.Sendo assim ,o estado da classe de uma aplicação não deve interferir no estado da classe de outra aplicação.
Eventos
O MIDP 3.0 estimula que as aplicações possam enviar e receber eventos; também podem ser inicializadas quando algum acontecimento ocorrer. Este acontecimento, por exemplo, pode ser,a abertura do flip do celular, nível baixo da bateria , uma chamada de voz,a saída de áudio ativada e até eventos postados por aplicações para que outras aplicações possam captura-los.
É possível assim, por exemplo, sinalizar uma aplicação que recolhem os dados em campos para que receba um evento quando a bateria estiver com mais de 90% da carga utilizada, permitindo com que o programa envie automaticamente os dados já recolhidos.
RecordStores
O MIDP 3.0 conceitua novas peculiaridades para os Record Stores (o meio de persistência de informações).
Entre as funcionalidades está o conceito de Tags .Ao incluir um registro, faz com que a associação de uma tag seja possível para o registro.Permitindo que quando utilizamos o Records comparator e o recordsfilter.Antes,todos os registros com uma determinada tag sejam passados,agilizando assim filtros e ordenações. O Record Stores é outra funcão proposta pela especificação. Tem como objetivo criar um padrão para de enviar dados na instalação de um MIDlet,persistindo-se esses dados como Record Stores. Para que não ocorra o tráfego de grande quantidade de informações, propõe-se o uso do formato binário para o envio. Arquivos no formato binário conteriam basicamente os nomes Record Stores e os dados, bem como a tag e if de cada registro.
Conectividade
Uma novidades do MIDP 3.0 é o suporte ao IP versão 6. o que implica dizer que a implementação poderá ser capaz de fazer parte de um endereço Ipv6 quando uma conexão for solicitada,por exemplo. Há possibilidade ainda de incluir a JSR-307(Network Mobility and Mobile Data API) no MIDP 3.0.Embora essa JSR tenha sido lançada recentemente e ainda esteja em estado incipiente,o líder das duas JSRs é o mesmo e a idéia é que se consiga fazer um bom alinhamento entre duas JSRs. E como a especificação do MIDP 3.0 abre a possibilidade de executar o MIDlets concorrentemente,nada natural que haver uma maneira de dois MIDlets poderem trocar informações entre si.A especificação apresenta o IMC(Inter-MIDlet Communictions),incluindo as interfacesIMMCCOnnection e IMCServerConnection que estendem as já conhecidas interfaces StreamConnection e StreamconnectionNotifier,ambas do pacote javax.microeditio.
Interface com o usuário
Uma das idéias do novo MIDP é que o MIDlet tenha acesso a vários displays. Por exemplo celulares com flip, pode ter um display interno e outro externo,sendo um o principal.O display principal deve suportar recursos do pacote javax.microedition. Contem (a API de interface gráfica do MIDP). Porém outros displays podem não ter espaço suficiente para mostrar alguns objetos que estendem a classe Screen(parte mais alto-nível da LCDUI).Portanto ,o MIDP 3.0 define que alguns grupos de componentes de alto nível sejam suportados: Commands, Input Events,forms,ticker e Title,Alerts,List e TexBoxes.Displays secundários podem não suportar qualquer um desses grupos,mas o canvas deve estar disponível para todos os displays.
No alto nível da API de interface gráfica,novas classes estão sendo criadas.Algumas que se destacam são Animatedlmage,fileSelector,MenuCommand e TabbedPane.A classe Animatedlmage estende image possibilita a exibição de imagens animadas no estilo GIF.Já a classe FileSelector permite escolher um arquivo do sistema de arquivos do dispositivo,mostrando um seletor onde é permitido selecionar um arquivo FileConnection da JsR-75.(No seu estado atual,a especificação do MIDP 3.0ainda não deixa claro se a classe FileSelector é opcional para o dispositivo que não implementam a API e FileConnection da Jsr-75,ou se é obrigatória a implementação.)
MenuCommand é uma extensão de Command suportando o agrupamento de comandos.Essa classe ajuda a evitar a poluição visual de muitos comandos numa tela.Além disso para gerenciar abas,é definida TAbbedPane,que herda da classe Screen.Com ela é possível gerenciar outras classes Screen, como Form,Liste Texbox.Podem também ser definidos ícones para cada aba.
Jogos e mídia
A Game API não apresenta nenhuma mudança em relação a versão anterior do MIDP conforme publicada no EARly Draft .Já os gerenciadores de mídia,o MIDP 3.0 está tornando obrigatória a incorporação da versão 1.1 da MMAPI, tornando obrigatório apenas uma parte. No MIDP 3.0, o suporte à MMAPI deve ser completo.
Conclusões
Provavelmente a maioria dos desenvolvedores, já ouviram falar do MIDP (MOBILE INFORMATION DEVICE PROFILE), utilizado juntamente com a tecnologia J2ME que é quem nos possibilita o desenvolvimento para sistemas microprocessados, como: celulares, PDAs, etc.
As novas possibilidades propostas pelo MIDP 3.0 vêm atender também necessidades relatadas pelos programadores. Apesar do avanço mostruoso das tecnologias móveis o MIDP conseguiu mais uma vez acompanhar, de forma geral, toda essa evolução. Fazendo com que tenhamos disponível todos os recursos que estes dispositivos apresentam em JAVA ME.
Fonte: Revista Java Magazine Edição 44
Assinar:
Postar comentários (Atom)
Muito bom, agora sim estamos vendo que o java começou a acompanhar a evolução atual. Parabéns pela excelente postagem, MX2! XD
ResponderExcluirObrigado!
ResponderExcluirO MIDP 3.0 foi lançado em 2009 e até agora nenhuma fabricante jogou a ideia pra frente, pro Java melhorar as fabricantes teriam que colocar memória heap e jar ilimitadas, implementar a multitarefa e colocar o MIDP 3.0, eu sei que alguns modelos Java minimizam e tem memória heap ilimitada mas seria legal se todas as fabricantes principalmente a Nokia fizessem essas melhorias no Java . Se a Nokia fizesse isso, os s40 ficariam show, se colocasse multitarefa, memoria heap e jar ilimitadas e colocasse logo MIDP 3.0 que inclusive, acredito eu, que fosse possível atualizar o software dos s40 v5 e v6 do MIDP 2.1 para o 3.0
ResponderExcluirLeon
ResponderExcluirO asha vem com a versão antiga se não me engano.
por que diachos a nokia nao utiliza logo esse midp 3.0?Prefere ficar insistindo em uma versao antiga ao inves de ver o que essa nova versao tem a nos oferecer ela deveria inclui-lo nos novos asha ou melhor nos futuros asha pow nokia acorda aff
ResponderExcluirque legal ! deveriam ter criado um app para pc para poder tirar o java antigo do celular e colocar a versão mas recente ! bom deveria existir a versão 3.1 com suporte mas avançado e que tivesse outro modelo de java ex: que suportasse jar e um outro 'jax' que fosse um novo e que fosse um app binário do jar mas exemplos quando criassem um app jar dentro desse jar ia ter um binário jax que podesse fazer ficar o app um pouco rapido ex: um emulador de snes ! o app snes.jar/jax poderia rodar os jogos bem mas rapidos sem algum erro é também deveria que no proximo midp java tivesse mas suporte jar jad jadx e jax ia ser mas legal !
ResponderExcluir