Quem disse que você não pode fazer milagres na sua UI? Nesse caso entra a TWUIK, é um conjunto de componentes de UI feitos em J2ME. O link para essa maravilha éTWUIK. Confesso que já tentei copiar algum dos componentes. Mas há certos componentes com transparência e efeitos que só com “milagres” e celulares high-end eles são feitos. É lógico que se você reparar nos celulares dos vídeos só tem high-end. Bom, semana que vem começo uma série de tutoriais para criação de componentes em canvas e quem sabe a criação de um concorrente do TWUIK… Sonhar nunca é demais!

Esse é o concurso de programação, patrociando pela Gemalto e Sun Microsystems, na última JVM desenvolvida – um cartão Smart Card como o da figura abaixo:

Essa JVM contêm a especificação Java Card 3.0 que habilita o uso de cartões e outros dispositivos limitados com a tecnologia Java. Mais informações sobre o concurso, acesse: Concurso J2ME e Java Card 3.0

Pessoal, depois de um longo tempo sem escrever volto a escrever. Hoje o assunto é relativo a KVMs para J2ME em Windows Mobile. Bom como vocês já devem ter notado a leva de celulares que saem hoje em dia com Windows Mobile é impressionante. Não sei se vocês leitores já utilizaram um celular com Windows Mobile mas é um Sistema Operacional bom e consistente para celulares. Acontece, porém, que nem todos os celulares que rodam Windows Mobile tem uma KVM nativa, e se tem, as vezes não tem várias JSRs que poderiam ter. Para Palm OS existia a Websphere Microplace da IBM que suportava JSRs de MIDP2, CLDC 1.1, CDC 1.0, JSR 75 e se não me engano JSR 135 com suporte a MIDI. Como tem 2 anos que não mexo em Palms então estou meio por fora. Agora na minha experiência com um HTC S710 com Windows Mobile 6.1 tive problemas ao tentar fazer conexões HTTP na JBED que veio no celular. Procurando em fóruns percebi que a solução era atualizar a versão da JBED. Não irei postar o link aqui porquê a mesma é paga, mas se tiverem esse problema basta uma busca no google e uma atualizada na JBED de seu smartphone que irá resolver alguns dos vários problemas de versão antiga de KVM.

Fica ai a dica para você desenvolvedor que possa ter tido problema com a sua KVM no Windows Mobile.

Pessoal aqui vai um resumo de apis J2ME focadas em desenvolvimento de GUIs para J2ME. Vale a pena dar uma olhada. Não tem todas APIs aqui, mas já é um começo. Até mais.

Apime

Apime é um framework que oferce mais funcionalidades a J2ME/MIDP. O núcleo das funcionalidades é interface gráfica, contendo componentes para construir aplicações com a estrutura do Swing de J2SE. Também inclui classes para controle de arquivos e customização de skins.

byblos

Uma coleção de componentes customizados para J2ME.

Fire (Flexible Interface Rendering Engine)

Fire (Flexible Interface Rendering Engine) é uma biblioteca que foca em prover componentes fáceis de serem utilizados por desenvolvedores J2ME. Fire provê o básico de J2ME (combos, listas, forms, item) mais customizações nesses componentes. Essa biblioteca não depende de aparelho ou tamanho de tela em específico, podendo ser portada para qualquer aparelho.

J2ME Lightweght Visual Component Library (LwVCL)

LwVCL suporta tanto J2SE e .NET. Agora possue uma versão de rascunho para J2ME MIDP.

jMobileCore

A biblioteca jMobileCore é um poderosa ferramenta para criação de GUIs para J2ME. Simplifica a tarefa do desenvolvedor provendo suporte a ricas GUIs e rápido acesso a dados no celular.

MWT (Micro Window Toolkit)

Inspirado no seus irmãos mais velhos como AWT, Swing e SWT, MWT entra em cena para a construção de UIs otimizados para celulares.

Para quem gosta de smartphones (e tem grana pra gastar), vai ai duas sugestões de modelos que são os tops de linhas (tops até as redes 3G, alguém já viu um celular 4G?) e que estão disponíveis no Brasil através de importadoras:
HTC Tytn 2
Nokia E90

Existem outros modelos interessantes mas esses me chamaram atenção pela quantidade de recursos. Pena que o E90 não seja touch screen. Até mais

No ano de 2005 e 2006 realizei uma pesquisa científica na PUC Minas através do FIP. O resultado do trabalho é apresentado num resumo das funcionalidades do aplicativo desenvolvido. Mais características sobre objetos de aprendizagem e outras discussões serão apresentadas nos posts a seguir.

VML

Virtual Modelling Laboratory (VML) é um software educacional composto por quatro componentes e um sistema de ajuda. A tela inicial permite acesso aos 4 componentes que são componentes separados mas que estão integrados.

O primeiro componente, o Construtor de Equações Gráficas, permite transformar equações construídas graficamente em equações de texto passíveis de serem interpretadas. Digitalmente, este componente é representado por um painel de desenho e uma barra de ferramentas, com os quais o aluno pode criar equações gráficas, adicionar componentes de uma equação e inserir equações no diagrama em blocos.

O segundo componente, o Construtor de Diagramas em Bloco, permite a criação de diagramas em bloco. Esta funcionalidade foi atingida a partir da criação de códigos fontes originais. Digitalmente, este componente é representado por um painel de desenho e uma barra de ferramentas, no mesmo estilo do primeiro componente, os quais permitem ao usuário criar seus diagramas em bloco com o simples clique do mouse.

O terceiro componente, o Interpretador de Equações, permite interpretar tanto as equações matemáticas construídas no primeiro componente quanto aquelas que o usuário digitar seguindo uma notação padrão. Permite, também, plotar gráficos dessas equações.

O quarto componente, o Visualizador de Animações, permite a visualização de animações previamente elaboradas. Esta funcionalidade foi alcançada através da definição de um problema real e de sua representação por um modelo matemático apropriado, o qual foi simulado por um modelo computacional, viabilizado por um código fonte que criamos.

Para facilitar a exploração da potencialidade destes componentes pelo aluno, criamos um Sistema de Ajuda, descritor do passo a passo de utilização destes componentes.

VML é um objeto de aprendizagem único para o ensino da engenharia. Ele contém certas funcionalidades presentes no Matlab como plotar e interpretar gráficos de uma maneira fácil. Não há funções avançadas como resolução de Integral e Derivada, mas por ser um software gratuito já oferece recursos básicos para a disciplina de Modelagem presente nos cursos. Pretendo adicionar mais informações e iniciar posts sobre a tecnologia de objetos de aprendizagem. Interessados favor entrar em contato sobre o VML, o mesmo pode ser “desmembrado” e utilizado em outros contextos educacionais, como o ensino de matemática básica, ou até uma calculadora avançada. Até mais

Encontrei nesse site um resumo das JSRs: MobileZoo. Vou traduzi-las aqui para os maiores interessados:

JSR-30
CLDC1.0 Connected Limited Device Configuration 1.0
A Configuração de Dispositivos Conectados Restritos (tenho certeza que já vi tradução melhor…) define o conjunto básico de APIs e a KVM para dispositivos móveis restritos como celulares, pagers e PDAs. Quando utilizada em conjunto com a MIDP, provê uma sólida plataforma para desenvolvimento de aplicativos Java em dispositivos de capacidade limitada.

JSR-139
CLDC1.1 Connected Limited Device Configuration 1.1
Adiciona o seguinte à CLDC 1.0:
— Suporte a ponto flutuante
— Suporte a weak reference. Não vou entrar em detalhes, mas aqui está a parte do javadoc que trata weak reference:CLDC 1.1 WeakReference

JSR-37
MIDP1.0 Mobile Information Device Profile 1.0
Combinado com a CLDC é a Java Runtime Enviroment de todos os dispositivos móveis atuais que suportam J2ME.

JSR-118
MIDP2.0 Mobile Information Device Profile 2.0
Adiciona o seguinte a MIDP1.0:
— UDP/Sockets/Secure Sockets/Server Sockets e acesso a porta serial
— Suporte a novos formatos de imagem (GIF / JPG / WMB)
— Suporte a PCM (Pulse Code Modulation) no formato wave e outros tipos de som sintético
— Proteção de cópia das MIDlet
— Instalação e descoberta de MIDlets através de outros mecanismos (Infravermelho,Bluetooth,etc)

JSR-271
MIDP3.0 Mobile Information Device Profile 3.0
Adiciona o seguinte a MIDP2.0 (resumo de mudanças retirado de MIDP 3.0 Mudanças:
— Comunicação entre MIDlets;
— Bibliotecas compartilhadas, que são chamadas por alguns sites de LIBlets;
— Múltiplas MIDlets rodando na mesma máquina virtual;
— MIDlets rodando em background;
— Jogos mais ricos;
— RMS com questões de seguranças mais sofisticadas;
— MIDlets poderão desenhar em Display(s) secundários;
— Localização e Internacionalização
— IPv6

JSR-185
JTWI Java Technology for the Wireless Industry 1.0
JSR que tem o intuito de diminuir o problema de portabilidade das aplicações J2ME. É uma tentativa de padronizar as JSRs 30,118,120,135 conjuntamente em todos os celulares que suportarem a JSR185.

JSR-172
WSAPI J2ME Web Services Specification
Acesso a web services através do MIDlet.

JSR-211
CHAPI Content Handler API
Define um modelo de comunicação entre aplicações, permitindo se especificar MIDlets como gerenciadores de conteúdo para um ou mais tipos de arquivos.

WMA1.0 Wireless Messaging API 1.0
— Suporte a Short Message Service (SMS), Unstructured Supplementary Service Data (USSD) e Cell Broadcast Service (CBS)
— Habilidades “Push” (executar um MIDlet ao receber mensagem)

JSR-205
WMA2.0 Wireless Messaging API 2.0
— Extende JSR120 com suporte a Multimedia Message Service (MMS), anexos MIME e mensagens multipart
— Proteção de conteúdo MMS usando Digital Rights Management (DRM)

JSR-135
MMAPI Mobile Media API
— MMAPI suporte a aúdio e vídeo no MIDlet
— MMAPI é um superconjunto da MIDP 2.0 e suas capacidades multimídia, adicionando suporte a captura e execução de imagens, sons e vídeos.

JSR-75
PDAP PIM & File Data API
— Adicionar\Remover contatos de telefone
— Eventos de calendário
— Alarme
— Acesso a arquivos e cartões de memória
— Sem acesso de escrita a áreas de sistema protegida

JSR-82
BTAPI Bluetooth API
— Descoberta de dispositivos bluetooth
— Obtenção do perfil e capacidade dos perfis disponíveis
— Abre fluxo entre os dispositivos conectados

JSR-177
SATSA Security and Trust API
— Suporte ao controle de certificados
— Autenticação de usuários utilizando certificados
— Permite MIDlets comunicarem-se com aplicações baseadas em SmartCard e também com aplicações com propósitos de criptografia em geral

JSR-184
M3G Mobile 3D Graphics
— Biblioteca gráfica 3D eficiente baseada em CLDC/MIDP
— Supporte a API scene graph (alto nível) e API imediata (baixo nível, subconjunto de OpenGL)
— Suporte a funções de importação de texturas, meshs, animações, cenas e hierarquias

JSR-129
PB Personal Basis 1.0
— Provê o ciclo de vida de aplicações Xlet e também ciclo de vida de aplicações Java tradicionais
— Provê um framework GUI para componentes lightweight
— Provê a API completa da Foundation Profile, dispositivos menos restringidos como os PDAs por exemplo

JSR-209
AGUI Advanced GUI
— Swing GUI toolkit da J2SE
— Engine gráfico da Java 2D preservado
— Imaging API e Image load/save framework preservado
— Input Method framework preservado

JSR-179
LAPI Location API
Pacote opcional que permite desenvolvedores escreverem aplicações com base em locais, tipo Locale em J2SE.

JSR-256
MSAPI Mobile Sensor API
API para controle de sensores através de Java com suporte a ligar, desligar e ter mais controles a sensores como IR, BT, etc

JSR-257
CCAPI Contactless Communications API
Pacote opcional para comunicação bi-direcional e acesso de dados de leitura apenas. One-way e bi-direcional captura de dados é interessante para uso em conjunto com dispositivos como RFID, código de barras e outros padrões existentes.

JSR-238
MIAPI Mobile Internationalization API
API para correto controle de formatações e ordenamento de strings de textos e outros recursos com base em características culturais, ex: acento em string, chars diferentes, etc.

JSR-234
AMMSAPI Advanced Multimedia Supplements API
Suplemento da MMAPI, mais informações em Comparando as capacidades multimídia do J2ME em celulares

JSR-226
SVGAPI Scalable 2D Vector Graphics API
Renderização de conteúdo 2D utilizando Scalable Vector Graphics.

JSR-180
SIPAPI SIP API
Provê acesso a aplicações SIP em MIDlets.

Fazendo uma pesquisa no Google descobri algumas coisas interessantes sobre streaming em celular. Primeiramente os celulares devem suportar o protocolo RTP ou RTSP (apesar desse último ser baseado no primeiro não necessariamente o primeiro deve estar explicitamente disponível ao desenvolvedor). Mais informações sobre esses protocolos em:RTSP Wiki e RTP Wiki. Caimos no problema da KVM do celular implementar esse tipo de protocolo. Procurando em fóruns descobri que os seguintes celulares suportam nativamente esses protocolos: celulares Nokia S60 3rd Edition (N91, N80, etc). Alguns celulares Sony Ericsson mais recentes (-800, -750, -600, Z520, -550) implementam rtsp e também alguns celulares Motorola 3G (V975/980, E1000).

Uma idéia interessante para simular streaming em celulares que não suportam nativamente (retirada de um fórum de J2ME, a idéia é interessante mas não testei na prática e parece o tipo de POG que funciona, mas continua POG!) é fazer um vetor de players, cada player busca uma quantidade X de dados. Se o seu arquivo tem 400kb, 10 players cada um busca 40kb. Quando um player da fetch e termina de tocar o outro já está realizando o seu fetch e toca assim que o outro acaba e assim por diante. Na prática o que já testei de fetch de player é que é uma operação “cara” e nem todo celular tem processamento suficiente para fazer isso. Mas está ai uma idéia para “streaming” em celular.

Se o celular suporta nativamente basta você pegar uma lista de protocolos implementados para um determinado tipo de conteúdo (content type que eu vou chamar de CT). Para saber quais os protocolos para esse CT, deve-se utilizar o método getSupportedProtocols(String contentType) que retorna um String array. Se você usar esse método com o CT “audio/x-wav” vai retornar com três valores: http, file and capture no wireless toolkit. Esses protocolos permitem ao desenvolvedor saber quais protocolor podem ser utilizados para adquirir um determinado recurso. O desenvolvedor ainda pode recuperar uma lista de CT a partir de um determinado protocolo. O método getSupportedContentTypes(String protocol)realiza essa função, logo se você passar o parâmetro "capture" o método retorna audio/x-wav e video/vnd.sun.rgb565 para o wireless toolkit. Se você passar null para esses métodos vai retornar todos os CTs e/ou protocolos que uma KVM suporta. Mais informações disponíveis em:Multimedia and MIDP 2.0.

Descobrindo-se se o celular suporta tal protocolo basta fazer uma chamada do player da seguinte maneira:createPlayer(“rtp://www.xxx.yyy.zzz”) e o player irá iniciar o stream no celular. O player se encarregará de dar fetch e bufferizar de tempo em tempo o vídeo.

Da parte do servidor de stream podemos citar dois “Stream Servers” um é o Helix Server da Real Network esse não é gratuito mas possui versão para testes disponíveis em:Helix Server. Outro servidor open source é o Darwin Stream Server disponível em:Darwin Stream Server. Devo disponibilizar nos próximos posts um código fonte unindo o Video Player e um Stream Player. Até o próximo post pessoal!

Para tocar vídeo em java é necessário criar um Player e buscar um objeto VideoControl do mesmo. Estou assumindo que os leitores já sabem criar um Canvas básico e fazer algum controle com os keyPressed ou commandAction. Mais referências básicas em J2ME Tutorial, Part 3: Exploring the Game API of MIDP 2.0. Por ventura esse link que passei é um excelente tutorial básico sobre o GameCanvas e o básico de programação de jogos em J2ME, o tutorial está em inglês mas tem uma compreensão muito fácil.
Voltando ao tópico, crie um Canvas ou GameCanvas, dê override no paint e no keyPressed. Até agora você montou um GameCanvas cru sem nada. Importe a seguintes classes:
import javax.microedition.media.Control;
import javax.microedition.media.Manager;
import javax.microedition.media.MediaException;
import javax.microedition.media.Player;
import javax.microedition.media.PlayerListener;
import javax.microedition.media.control.FramePositioningControl;
import javax.microedition.media.control.VideoControl;
import javax.microedition.media.control.VolumeControl;

Depois crie as seguintes variáveis na sua classe.

private Player player;
private VolumeControl volumeControl;
private VideoControl videoControl;
private FramePositioningControl framePositionControl;

Basicamente a variável player retorna todos os outros controles implementados pela VM do celular a ser desenvolvido. Vide o post anterior para uma visão do player. Agora o trabalho reside em realizar os estados do player. Primeiro é necessário definir se o conteúdo vai estar no JAR, no RMS, na URL ou por streaming RTP (que porventura é um assunto delicado se falar em streaming de vídeos em dispositivos móveis atualmente. Assunto para outro post) Vou supor que o conteúdo estará ou em um jar ou em uma URL. Então crie um método para pegar o arquivo:

private void openMediaFile(String path) throws Exception {
synchronized (this) {
if (player == null) {
// Toda url se for local vem com a palavra resource inicialmente
if (url.startsWith("resource:")) {
// Arquivo que se encontra no jar
InputStream ins = getClass().getResourceAsStream(url.substring(9));
// Tira o mime type, os players são dependentes do myme type para criar seu tipo de player
String contentType = "video/3gp";
// Primeira ação criar o player com o myme type e o stream do vídeo
player = Manager.createPlayer(ins, contentType);
}// if
else {
// Se não for local, o player se encarrega de abrir esse arquivo da // internet
player = Manager.createPlayer(url);
}// else
}// if
}// synchronized
}


Crie um outro método para realizar o player:

private void realizePlayer() throws Exception {
player.realize();
}


Crie um método para atualizar os controles que pertecem ao Player referente a vídeo

private void updateControls() throws Exception {
if((videoControl = (VideoControl) player.getControl("VideoControl")) != null) {
// deve ser utilizado com o canvas ou o displayable que você quer exibir
videoControl.initDisplayMode(VideoControl.USE_DIRECT_VIDEO, this);
// aonde esse display vai ficar no canvas
videoControl.setDisplayLocation(0, 0);
// tamanho desse display de vídeo no canvas
videoControl.setDisplaySize(this.getWidth(), this.getHeight());
// deixa ele visível no canvas
videoControl.setVisible(true);
}// if
// restante dos controles
Control[] controls = player.getControls();
for (int i = 0; i < controls.length; i++) {
if (controls[i] instanceof VolumeControl)
volumeControl = (VolumeControl) controls[i];
if (controls[i] instanceof RateControl)
rateControl = (RateControl) controls[i];
if (controls[i] instanceof FramePositioningControl)
framePositionControl = (FramePositioningControl) controls[i];
}// for
}
Dê um prefetch no player:


private void prefetchPlayer() throws Exception {
player.prefetch();
}


Logo depois que o vídeo está todo configurado você pode iniciar ou pausa-ló:


/**
* Método para parar e iniciar o vídeo
*
*/
public void playVideo() {
try {
if (player.getState() == Player.STARTED)
player.stop();
else
player.start();
}
catch (Exception e) {
System.err.println(e);
}
}


Para simplificar você deve fazer as operações em sequência:

/**
* Método que configura o player com o vídeo
* @param path caminho do arquivo de vídeo
*/
public void open(String path) throws Exception {
try {
openMediaFile(path);
realizePlayer();
updateControls();
prefetchPlayer();
}
catch (Exception e) {
// Desaloca o Player
if (player != null) {
player.stop();
player.close();
player = null;
}
}
}

Agora é necessário fazer o uso de keyPressed ou commandAction para usar os controles do Player. Basicamente se você apertar 1 por exemplo você pode usar o volumeControl para aumentar o volume ou utilizar o framePositionControl para avançar ou retroceder o vídeo. As operações básicas desses controles são:

volumeControl.setLevel(int);
volumeControl.getLevel();
volumeControl.setMute(boolean);
volumeControl.isMute();
framePositionControl.skip(int);

Além disso você pode definir a posição do vídeo com:

player.setMediaTime(int);

Simples! Há com certeza melhorias a serem feitas no código mas já dá pra iniciar a “brincadeira” com vídeo em J2ME. Lembrem-se nem todo celular suporta esses controles, consulte nos fóruns que JSRs o celular implementa. Existe um código de um SimplePlayer nos code samples da SUN, quem quiser algo mais aprofundado é só procurar nas pastas de src do WTK. Até mais!

Existem N tutoriais gratuitos na internet e livros bom como o livro Core J2ME que ensinam o básico e o avançado do J2ME. Porém, não existe ainda nenhum que fale a fundo sobre as JSRs que são implementadas a parte. Hoje eu vou introduzir um pouco sobre a JSR-135, a Mobile Media API. Essa API introduziu a capacidade de reproduzir vídeo, aúdio, capturar som e imagens utilizando a J2ME. Um ótimo tutorial introdutório e no qual eu me baseei está no site da Sun em Mobile Media API Overview. A primeira coisa que vem a cabeça do desenvolvedor é: “Agora vou poder fazer meu Winamp no celular”. Acontece que mesmo que o celular toque vídeo ou um determinado tipo de aúdio e mesmo que exista a JSR-135 implementada em seu celular, não necessariamente ele vai tocar todo e qualquer tipo de aúdio ou vídeo. Não há garantia de que ele implemente isso em J2ME. Todo e qualquer fabricante pode capar suas implementações de J2ME e isso torna um inferno para o programador. Um código que funciona em uma JSR-135 de um celular não funcionará necessariamente em outro. Tome por exemplo o V3. O V3 da Motorola possui uma variedade de versões desde CLDC 1.0 a 1.1 e com diferentes JSRs. Todos com a marca V3. Acontece porém que o celular é capaz de tocar vídeos 3GP mas o J2ME não! Isso decorre do fato que todo celular possui um hardware específico e os fabricantes tem que conjugar esse fato na hora de implementar suas KVMs. A única maneira do desenvolvedor manter seu código robusto é capturar as exceções que são lançadas quando um celular não suporta determinada função. Para verificar se o celular que o software rodará basta verificar os developers sheets nos sites dos desenvolvedores. Nos fóruns em específico existem questões relacionadas ao suporte específico de cada celular para as mídias como 3gp, Mp4, MP3, etc.

A Mobile Media API é baseada em quatro conceitos chaves:

1. Um player sabe tocar um determinado tipo de mídia. Um tipo de player consegue tocar som em MP3, outro em 3GP. Todos os objetos Players são representados pela interface javax.microedition.media.Player.
2. Cada player possui diferentes controles (ToneControl, VolumeControl, VideoControl, RateControl) que podem ou não serem implementados. Você pode utilizar esses controles para mudar o comportamento do seu Player, por exemplo aumentado o volume do som. Controles são representados pela implementação das interfaces da javax.microedition.media.Control; existem ainda controles específicos que estão no pacote javax.microedition.media.control.
3. Um player adquire a mídia através de um data source. A mídia pode ser armazenada no JAR, no RMS do celular, obtida através da API FileConnection ou até mesmo de conexão HTTP, streaming através de RTP. A interface que representa um data source está em javax.microedition.media.protocol.DataSource.
4. Finalmente, um manager serve de ponte entre essas interfaces e permite a obtenção de data sources e players.

Essa foi uma pequena introdução de MMAPI. No próximo post posto uma explicação das principais interfaces e posteriormente mostro uma “VideoCanvas”. Até!