Mobilidade é tudo

Boa tarde..

O blog jmeBrasil publicou um interessante post chamado “Documento de APIs“, passando o link de um documento PDF com uma listagem de devices Java ME-Enabled e suas respectivas Apis.

Att.
Ping

Boa noite..

Através de um post do blog Mobits tomei conhecimento do artigo “J2ME Google Maps API“, publicado no forum Nokia. Esse texto mostra como é possível publicar um mapa direto do Google Maps para seu aplicativo Java ME. Muito interessante..

Vale muito a pena..

Att.
Ping

Bom dia..

Na lista de discussão Markmail, encontrei uma discussão sobre a chamada de serviços nativos no Java ME, utilizando uma ponte com o Symbian. O mais importante dessa discussão foi o link para um texto chamado “Extending the Reach of MIDlets: how MIDlets can access native services”. O texto explica como podemos chamar serviços nativos Symbian em Java ME, utilizando uma conexão socket entre as duas plataformas. Realmente a leitura é muito válida.

OBS: o link baixa um .zip para você, neste arquivo encontramos o PDF assim como os arquivos para você testar em seu dispositivo. Tentei testar em um Nokia E51 mas não instalava o .sis no aparelho. Quem quiser testar, por favor teste os resultados aqui no blog. Além disso, se alguém souber a causa da minha falha está convidado a revelar minha ignorância.

Att.
Ping

Boa tarde..

Através do post “Artigo sobre o futuro de java para dispositivos móveis“, do blog Mobideia, tive acesso ao excelente artigo “Will Java have a place in the future of mobile devices?“, do blog Developing.

O texto fala sobre o futuro do Java ME. Dentre os pontos que mais me chamaram a atenção do artigo estão:


Mobile industry is transforming rapidly. Mobile operating systems and runtime stacks are at the center of this change. Mobile Linux, Android, and the lately announced Symbian Foundation, the trend is clear. The Mobile OSs are becoming license free and in most cases open source. The same trend can also be observed on the runtimes that run on these mobile platforms as well. WebKit, br>is license free and open source. Python, license free and open source. Flash runtime, has no license fees and open source. Java, NOT free and NOT really open source for the manufacturers to ship.



The obvious scenario is it will cease to exist in mobile space by time with the exception of Android. Motorola lately announced that it reduces the software platforms that it uses and will start using Android as one of its preferred platforms. This is significant for two reasons because Motorola is still one of the major phone manufacturers and it is the specification lead for the MIDP3 JSR in JCP. MIDP3 is under specification work for almost 4 years now and I guess we will be waiting for it some more. Although the features and innovation of the MIDP3 is not significant anymore but the delays of its arrival is an indication.



Android is a confusing player in the mobile space. Officially it is not Java. It uses the Java language and Sun appears to like it (I can’t really figure out why), at least Android was the main mobile demo platform in the last JavaOne.


Bem, apesar de concordar que a Sun, que detém o Java ME faz muita coisa errada para a expansão da plataforma, não acredito em tudo que o artigo diz. Creio em tudo que está escrito, não acredito que o Java ME vá deixar de existir, quem sabe seja remodelado, subtituído pelo Java FX Mobile (que é uma promessa que não está se concretizando), ou a MIDP 3.0 finalmente saia das cortinas para o mundo. Porém, é visível para todos que o Java ME não tem mais o império que tinha a alguns anos atrás, nada anormal.

Att.
Ping

Boa tarde..

Aqui no blog a gente já falou algumas vezes sobre a Mobile Sensor API, um pacote opcional presente na Java ME - MIDP, que permite a recuperação de dados de sensores internos ou externos ao aparelho celular. Bem, infelizmente esta API não está presente em um número razoável de aparelho. Porém, pelo menos para o aparelho Nokia 3220’s Xpress-on™ Fun Shell, existe uma solução. Navegando pelas ondas da internet, encontrei o texto “Security settings required to access tilt sensor on the Nokia 3220 Xpress-on Fun Shell cover“.

Na sequência, deixo aqui o overview da matéria:
You can access the tilt sensor on the Nokia 3220’s Xpress-on™ Fun Shell cover by creating a DatagramConnection to the cover. Note that SecurityException is thrown if an additional permission is not used in the MIDlet’s JAD file. The MIDlet should be also signed to the Trusted 3rd Party Domain

E também, a description:
The DatagramConnection to the Fun Shell cover can be created as follows: “coverConnection = (DatagramConnection) Connector.open (”lcif://GAME/joystick/1.0″);”. To make this work, an additional permission needs to be added to the MIDlet’s JAD file: “javax.microedition.io.Connector.lcif” and the MIDlet should be signed. Otherwise SecurityException is thrown.


Achei super interessante saber disso, apesar de não encontrar muitos Nokia 3220 no Brasil, mas aí já é outro problema.

Att.
Ping

Bom dia…
Encontrei um texto que fala de forma bem sucinta e direta sobre o mecanismo de Push Registry da MIDP 2.0 e, de bônus, fala sobre a ativação automática de MIDlets através de mensagens SMS ou CBS. Vale a pena.

O link está aqui

Att.
Ping

Boa tarde..

Estaba navegando pelos blogs quando encontrei o post “Sun lança uma versão (Early Access) do seu novo JavaME SDK 3.0” no Mobideia. Parte do post diz o seguinte: A Sun acabou de lançar um versão de testes da sua nova SDK para desenvolvimento da plataforma Java ME. A versão 3.0 perrmite que você desenvolva aplicativos para diversos tipos de plataforma como CLDC, CDC e até Blu-ray Disc Java (BD-J). Tudo isso em um único SDK! De acordo com o site, ele será o novo sucessor do famoso Java Wireless Toolkit 2.5.2 e o Java Toolkit 1.0 para CDC. Parece também que ele provê emulação do aplicativo direto no aparelho móvel!! Pow isso seria uma mão na roda para os desenvolvedores! Totalmente integrado com o Netbeans e inclusive com uma máquina virtual para Windows Mobile!

No site oficial do SDK encontrei outras novas features que merecem destaque:

Optimized MSA 1.1 Stack with Extensions
Java ME Platform SDK contains an optimized CLDC/MIDP stack. This implementation supports multitasking and is built upon CLDC 1.1 and MIDP 2.1. It also contains the following new JSRs:
* Mobile Sensor API (JSR 256)
* XML API for Java ME (JSR 280)
* Java Binding for the OpenGL ES API (JSR 239)
Até que enfim um SDK com suporte pra Mobile Sensor!!!!!!

Lightweight UI Toolkit (LWUIT) integration: The open-source Lightweight UI Toolkit has recently generated a lot of interest and Java ME Platform SDK is the first developer’s kit that comes with a built-in LWUIT library, resource manager and demo application. O LWUIT já foi discutido aqui no blog.

Uma pena que ele precisa de 1G de memória, e meu notebook tem só 512M, mas o note novo tá chegando… Se alguém já testou e quiser comentar este post sinta-se em casa.

Att.
Ping

Boa tarde..

A partir da versão 2.0 da MIDP, os programadores Java podem permitir que aplicativos Java ME (MIDlets) possam ser iniciados de forma automática, sem intervenção do usuário. Este mecanismo é chamado de Push Registry. O objetivo desse post não é explicar de forma detalhada o Push Registry, porém, de forma sucinta, basta saber que é possível programar sua MIDlet pra iniciar automaticamente após um intervalo de tempo ou, com eventos externos, como chegada de mensagem SMS, MMS, Bluetoooth, conexão por socket etc.



A Figura anterior mostra as formas de ativação de uma MIDlet. A “Manual Activation by user” é a forma normal, onde o usuário vai até o menu de aplicativos do dispositivo e inicia a aplicação. Os dois modos de ativação ao lado foram adicionados com o advento do Push Registry.

Bem, dito isso, uma das formas de ativação de MIDlet é com conexão Bluetooth. Para fazer isso, podemos usar a JSR-82, um pacote ocional do Java ME para troca de dados entre dispositivos através de uma conexão Bluetooth ou, utilizar a API Marge. Esta API criada por brasileiros, facilita a criação de aplicativos que utilizem Bluetooth, escondendo um pouco a complexidade da JSR-82.

Para adicionar o mecanismo de Push Registry a um aplicativo tem duas formas: estática ou dinâmica. A forma estática é a mais simples, basta adicionar uma nova linha ao descritor da aplicação, o famoso .JAD. Além disso, é preciso dar permissão de uso para algumas classes. Veja as duas linhas que precisei colocar no arquivo JAD do meu projeto:


MIDlet-Permissions: javax.microedition.io.PushRegistry, javax.microedition.io.Connector.bluetooth.server, javax.microedition.io.Connector.bluetooth.client
MIDlet-Push-1: btspp://localhost:D0FFBEE2D0FFBEE2D0FFBEE2D0FFBEE2,hello.HelloMIDlet,*

A linha de permissões é auto explicativa, a linha MIDlet-Push-1 define um push registre estático. O btspp define o protocolo, a seguir definimos o dispositivo (localhost) e seu UUID como D0FFBEE2D0FFBEE2D0FFBEE2D0FFBEE2. Este UUID é um número de 32 bits que define um identificador único universal. Porque coloquei este número hexadecimal? Porque criei um servidor Bluetooth anteriormente no celular e mandei mostrar no display qual era o UUID que o servidor criado recebia, com isso, fiquei sabendo qual o código universal do aparelho. Depois da vírgula defini qual a classe que será iniciada com esse evento de push resgistry. Finalmente, no último parâmetro é possível criar filtros, no meu caso não coloquei nenhum, passando apenas *.

Bem, o leitor deve ter percebido que para fazer isso precisa conhecer o UUID do aparelho, oque não é muito usual, levando em conta que seu aplicativo será distribuído para N plataformas. Então, a solução é o push registry dinâmico, construído via código fonte. A listagem de código abaixo demonstra como criar um push registry dinâmico:


1: public void registra()
2: {
3:    ServerConfiguration config = new ServerConfiguration(this);//communicationListener
4:    config.setMaxNumberOfConnections(10);
5:    getFrmMain().append(”UUID: “+config.getUuid().toString());
6:    communicationFactory.waitClients(config, this);
7: 
8:    String midletClassName = this.getClass().getName();
9:    String url = “btspp://localhost:”+config.getUuid().toString();
10:    String filter = “*”;
11: 
12:    try
13:    {
14:       PushRegistry.registerConnection(url, midletClassName, filter);
15:    }
16:    catch (ClassNotFoundException ce)
17:    {}
18:    catch (IOException io)
19:    {}
20: }


Na linha 3 crei uma instância de ServerConfiguration, passando como parâmetro a própria classe que implementa a interface CommunicationListener. A linha 6 poderia ser removida, porque apenas inicia o servidor bluetooth e espera por conexão de clientes, porém, o objetivo aqui é só saber o UUID, mas, deixei a linha de código no lugar até para uma questão de aprendizado. As linhas 8, 9, e 10 definem os parâmetros que serão usados para a criação do push registry. Destaque para a linha 9, que utiliza o código config.getUuid().toString() para recuperar a UUID que é usada pela instância de ServerConfiguration que criei. Finalmente, na linha 14 é onde cria-se de fato o push registry.

Bem, acho que é possível notar que não é dificil fazer um Push Registry através de Bluetooth e, fica bem bacana.

Att.
Ping

Boa tarde..

Hoje aconteceu uma coisa muito estranha com um programa Java ME que eu fiz, simplesmente não há explicação plausível para o comportamento do aplicativo, então, quero apresentar pra vocês e, se alguém souber a resposta, sinta-se a vontade para matar minha ignorância nos comentários deste post.

Estava procurando uma forma de emular a Mobile Sensor API (JSR 256) no emulador da Sony Ericsson, versão 2.5.0.2, infelizmente o emulador parece que não emula isso. No meio de minhas pesquisas no google encontrei uma referência a classe com.samsung.util.Acceleration que poderia fazer isso. Depois de baixar a documentação da classe e seu .class neste endereço, li sobre como utilizá-la, vou descrever oque diz sua própria documentação:


Class Acceleration implements acceleration functions for acceleration game.
To use acceleration function, follow the next step.

1. Check whether a device supports the acceleration function or not by calling isSupported.
2. Create new Acceleration instance to start measurement of acceleration.
3. Get the roll and pitch degree by calling getRollNPitchDegree.
4. stopCalAngle SHOULD be called at the end of the game (namely, destroyApp()).

Bem, com o .class em mãos o meu amigo Robison do Paraná, gerou o .java pra mim na ferramenta Gel. Engraçado que o código da classe é muito estranho, vejá só:


package com.samsung.util;
import java.io.PrintStream;
<
public class Acceleration
{

   public Acceleration()
   {
   }

   public static boolean isSupported()
   {
      return true;
   }

   public short[] getRollNPitchDegree()
   {
      System.out.println(”SeungHee Acceleration.java grpd”);
      short aword0[] = new short[2];
      aword0[0] = 1;
      aword0[1] = 2;
      return aword0;
   }

   public void reCalAngle()
   {
   }

   public void stopCalAngle()
   {
   }
}


Pelo que vi o código simplesmente não faz nada, não é? Mas resolvi arriscar e gerar o executável mesmo assim, pra saber oque mostraria em um celuluar da Samsung mesmo. Gerei o seguinte código fonte:


short[] dados = ace.getRollNPitchDegree();
if (dados != null)
{
   short[] dados = ace.getRollNPitchDegree();
   if (dados != null)
   {
      fmMain.append("dados.lenght: "+dados.length);


      for (int i = 0; i < dados.length; i++)
      {
         fmMain.append("dados["+i+"]: "+dados[i]);
      }
   }


No emulador da Sony mostrou oque o código da classe Acceleration devia fazer, mostrou: dados[0] = 1 e dados[1] = 2.

Depois disso gerei o jar e coloquei no Samsung SGH-D880, e olha que impressionante, mostrou: dados[0] = 0 e dados[1] = 0.

Agora a pergunta que não quer calar, daonde ele tirou aqueles valores “0″ ali?

Att.
Ping

Boa tarde..

Você saberia me responder rapidamente como saber se o aparelho implementa a JSR 82 (Bluetooth)? Bem, se o aplicativo a ser desenvolvido fosse para um aparelho específico, como o Nokia 6280 por exemplo, você olharia no forum.nokia.com e verificar a especificação do celular, pronto. Agora, se você quisesse saber disso em tempo de execução do aplicativo? A primeiro resposta seria, usao System.getProperty() da seguinte forma:

System.getProperty (”bluetooth.api.version”)

Porém, segundo esta lista de discussão, esta propriedade de sistema não é implementada na versão 1.0 da API, ou seja, mesmo com a implementação da API no dispositivo ele retornará null para o getProperty anterior.

Neste caso, como no W850i por exemplo, o único modo de saber se há implementação é usando a linha de código:

javax.bluetooth.LocalDevice.getProperty(”bluetooth.api.version”)

Eu não sabia desta “falha”, mas é bom ficar sabendo..

Att.
Ping