Boa madrugada..
Há alguns dias atrás, palestrei no evento WebDays, com o tema “Aplicativos Mobile Payment através da Java ME”. Até aquele momento não tinha encontrado aparelhos celulares que implementassem esta API. A Payment API, segundo Ricardo da Silva Ogliari: define um pacote opcional para a plataforma Java ME, permitindo iniciar transações de pagamento de forma segura entre o cliente (aplicativo móvel) e operadoras externas. Porém, andei lendo um pouco sobre a plataforma JP-8 da Sony Ericsson, e descobri que ela implementa a Payment API. Sendo assim, peço desculpas as respostas incorretas que repassei até este exato momento. O fato é que, já existem dispositivos com a JSR 229 implementada.. huhuhuh
Att.
Ping
Bom dia..
É crescente a percepção das pessoas com a qualidade que os telefones da Sony Ericsson vem demonstrando, pessoalmente, pretendo reservar meu dim-dim da próxima aquisição para um celular da Sony. Falando por mim, to ficando impressionado com os telefones da série JP-8 da Sony, devido a presença de APIs Java ME que podem fornecer subsídios pra construção de aplictivos poderosos com Java, claro, com outras plataformas também, mas não vou falar do que não tenho conhecimento :). Olhem a imagem abaixo:
Gostaria de chamar destaque pra quatro delas, vou listá-las a seguir por ordem de importância (na minha opinião):
Payment API (JSR 229). Com esta API, podemos criar aplicativos Mobile Payment com Java ME. Por exemplo, em um sistema que faz a busca dos cinemas mais próximos e, mostra a lista de filmes e horários de cada um deles, será possível integrar um módulo onde é possível efetuar a compra do bilhete.
Mobile Sensor API (JSR 256): A leitura de diversos sensores torna-se possível, no link que passarei abaixo, tem dois exemplos, um para ler o nível da bateria e outro para ler o nível de intensidade do sinal de cobertura da rede de telefonia celular.
AMMS (JSR 234): As capacidades multimídia dos aplicativos Java ME ganha um “up” considerável. Por exemplo, é possível aplicar som 3D, flash nas fotos etc.
Open GL ES (JSR 239): Enfim o casamento entre Java ME e Open GL foi oficializado.
Para ler um pouco mais sobre a plataforma JP-8, leia o texto “Update to Sony Ericsson’s Java Platform 8 (JP-8)“.
Att.
Ping
Boa tarde..
O trabalho Analysis of J2ME™ for developing Mobile Payment Systems que descobri no ZDNet, de Anders Cervera, é um trabalho antigo, lá de 2002, porém, tem algumas informações bem relevantes. O texto é todo em inglês. É necessário criar uma conta no site primeiro.
Fica aí a dica de leitura.
Att.
Ping
Boa tarde..
Hoje estou voltando a série de posts sobre relatos de erros absurdos que quase me enlouqueceram, vamos a mais esta pérola.
Estava programando um aplicativo Java ME no NetBeans 6.0 que fazia uso extensivo de RMS (Record Management System), usando a versão 2.5 do Sun Wireless Toolkit. Porém, o programa apresentava inconsistência no início, verifiquei que ele sempre trazia vetores vazios da busca de dados do RMS. Consequentemente, descobri que os Record Stores estavam sempre vazios. Bem, no início pensei o seguinte: como eu não baixei o Mobile Pack, mas sim o NetBeans e o WTK de forma separada, a persistência dos dados deve ficar restrita ao WTK.
Pulei pro Eclipse versão européia. Porém, o Eclipse dava uns erros de memória, indescritíveis, quando tentei rodar o mesmo projeto. Lutei a tarde toda contra esse comportamento insano do Eclipe, acabei desistindo. Porém, pensei comigo, mas eu já programei diversos programas no NetBeans da mesma forma e ele sempre armazenou os RMS. Então abri outro projeto e verifiquei que a única diferença era que estava usando a versão 2.5.2 do WTK.
Voltei para meu projeto em desenvolvimento e configurei o projeto para usar a versão 2.5.2 do WTK. Resultado, era isso. Não consegui descobrir qual o problema entre o NetBeans e a versão 2.5 do WTK, porém, no meu caso, eles me tiraram um dia inteiro de trabalho.
Att.
Ping
Bom dia..
Encontrei sem querer uma API no meio das 83 JSR´s para Java ME: “JSR 242: Digital Set Top Box Profile - ‘On Ramp to OCAP’“. Algumas questões retiradas do site da JCP.
2.1 Please describe the proposed Specification:
The requested specification will define a Java 2 Platform, Micro Edition (J2ME) profile based on the Connected Limited Device Configuration (CLDC) appropriate for use by small-footprint, cable television set top boxes. The profile will consist of Java 2 APIs for I/O, networking, graphics, etc. appropriate for small-footprint cable television set top boxes and a subset of the Java TV API appropriate for such devices.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
The target Java platform is J2ME CLDC.
Implementations of this specification are intended to be downloaded to existing deployed cable set-top boxes. They are not intended to be used in new OCAP-capable boxes, which are expected to support the full OCAP specification ( http://www.opencable.com/specifications). Please see below for an explanation of OCAP.
Pena, que como a maioria das 83 API´s que comentei antes, a JSR 242 parece que também ainda não foi implementada, porque nãoi encontrei nenhum dispositivo com esta API.
Att.
Ping
Bom dia..
Na revista TIInside, de Julho de 2008, podemos encontrar a matéria “Na mão, no olho e no sangue: Estudo da Frost & Sullivan projeta que a adoção de biometria por instituições financeiras vai crescer mais de 20 vezes até 2013, mas qual será a técnica dominante e como esse fenômeno será absorvido no país?”.
Bem, o título da matéria praticamente diz tudo, porém, selecionei alguns parágrafos pra vocês.
Um mercado 20 vezes maior que em 2006, saindo de US$ 117,3 milhões há dois anos para a soma de US$ 2,7 bllhões em 2013.
O revista afirma que será difícil ver essa proporção aqui no Brasil, porém cita um exemplo:
A exceção, no Brasil, é o investimento do Bradesco no tema, que começou ainda em 2006. Não apenas por ser uma das maiores instituições financeiras do País, como também pela técnica escolhida, no caso a Pal Vein, um sistema de leitura com sensores capazes de reconhecer o padrão das veias da mão.
Só pra fazer um link com Java ME, a JSR 256 (Mobile Sensor API) poderá ser muito útil. Segundo sua documentação: The JSR 256 Mobile Sensor API allows Java ME application developers to fetch data easily and uniformly from sensors. A sensor is any measurement data source. Sensors vary from physical sensors such as magnetometers and accelerometers to virtual sensors, which combine and manipulate the data they have received from other kinds of physical sensors. Examples of virtual sensors could include, for example,
battery level sensor indicating the remaining charge in a battery, or a field intensity sensor that measures the reception level of the mobile network signal in a mobile phone. The sensor may be connected to the mobile device in different ways, represented by the connection type, examples of which are embedded, short-range wireless, wired, and remote connection type.
Ainda, a documentação cita como um dos casos de uso o seguinte:
Identify the user with biometric sensors making misuse of a device more difficult and customizing user experience with identity-based profiles.
Como hoje estou pros links, vou fazer mais um. A Mobile Sensor será tema de alguma série de posts que este blog irá publicar, além de ser tema da minha palestra “Futuro do Java ME: Conheça algumas das APIS que estão sendo aprovadas pelo JCP”, que será ministrada no evento WebDays Developer 2008.
Att.
Ping
No site do Programa de Desenvolvedores Nextel encontrei um ótimo texto: “APIs Java ME recentemente desaprovados no Motorola i876“.
Texto retirado do site: O novo aparelho Motorola i876 inclui vários câmbios ao entorno Java ME. Isso inclui algumas APIs que foram desaprovadas e não serão incluídas mais pelo fato de serem redundantes ou porque já existem APIs padrão Java (conhecidos como JSRs) com mais funcionalidade. As APIs desaprovadas, e as APIs que as substituem no i876 são as seguintes:
E o mais interessante disso tudo é que a maioria das APIs que não são mais usados, foram substituídas pelas APIs de uma JSR, principalmente a MMAPI (JSR 135), isso é ótimo para a padronização.
Att.
Ping
Boa noite..
O Blog “De Idéias a Projetos” publicou o post “MSA 2.0 (JSR 248) está chegando“, fazendo referência a JSR 248. Bem, vamos as explicações:
Na plataforma Java ME existem alguns pacotes opcionais pra características avançadas dos dispositivos, como Location API (para dados de geo-referenciamento, como o GPS), MMAPI (dados multimídia) e diversas outras. Quando falo diversas são dezenas. Sendo assim, a Sun criou a JTWI (Java Technology for the Wireless Industry) - JSR 185 e a MSA (Mobile Service Architecture) - JSR 248. A JTWI, segundo a Sun, defines the industry-standard platform for the next generation of Java technology-enabled mobile phones. JTWI is defined through the Java Community Process (JCP) by an expert group of leading mobile device manufacturers, wireless carriers, and software vendors. JTWI specifies the technologies that must be included in all JTWI-compliant devices: CLDC 1.0 (JSR 30), MIDP 2.0 (JSR 118), and WMA 1.1 (JSR 120), as well as CLDC 1.1 (JRS 139) and MMAPI (JSR 135) where applicable. The specification raises the bar of functionality for high-volume devices, while minimizing API fragmentation and broadening the substantial base of applications that have already been developed for mobile phones. Ou seja, quando um telefone celular tem a JTWI, ele automaticamente possui a WMA e a MMAPI. Já a MSA define as APIs ilustradas na Figura abaixo:
Depois dessa berve explicação o leitor pode perceber a importância do surgimento da MSA 2.0 - JSR 249. Para saber mais sobre ela veja o texto “Mobile Service Architecture 2 — Coming Your Way“. A Figura abaixo mostra as APIs que a nova MSA define, lembrando que a mesma traz 3 subdivisões: Limited, Subset, e Full.
Pena que um telefone celular com a MSA 2.0 Full implementada vai demorar um pouco para aparecer.
Att.
Ping
Bom dia..
Olhem este link que interessante: Pstros NDS - MIDP for the Nintendo DS.
Trecho do site: Pstros NDS is a MIDP implementation running on the CLDC java machine compiled for the Nintendo DS. It allows you to run some java programs and games written for the mobile phones on your NDS. To achieve this goal one needs a java machine for processing the bytecode and a program library that implements the MIDP api. In this case the Sun’s KVM java machine was used (thanks to Torlus and davr for porting it for the NDS and providing the source) and an altered version of the Pstros was used as the MIDP library. Both parts were built into the single binary to simplify the execution of the java code on the NDS.
Pena que não tenho um nintendo aqui para testar.. 
Att.
Ping
Boa noite..
Texto retirado do blog “De Idéias a Projetos“: Para os interessados em desenvolvimento em Mobile com Bluetooth e especialmente com o novo Mobile Sensor API ( JSR 256), Bruno Ghisi em seu blog lançou um pequeno tutorial mostrando como desenvolver um pequno jogo em JavaFX utilizando um celular através do bluetooth. Detalhe importante é que o controle é baseado em sensores de acelerômetro e o framework Marge! Dêem uma melhor olhada no post publicado aqui.
O texto do Bruno realmente está muito interessante.. vale a pena dar uma lida.. e lembrando que no WebMedia 2008, a Mobile Sensor vai ser tema de uma de minhas palestras.. :)..
Att.
Ping
