Tutorial Symbian C++: Desenvolvimento de um Aplicativo (Final) : Parte 3

1. Desenvolvimento para Symbian C++

Dando continuidade ao tutorial sobre Symbianc C++, irei nessa seção explicar o desenvolvimento de um aplicativo em Symbian C++ para smarthphones Serie 60 (S60) usando a arquitetura tradicional através de um exemplo.

Interessados podem acompanhar a última parte deste tutorial , explicando toda a estrutura de um aplicativo Symbian e seus conceitos aqui.

10. Exemplo usando a arquitetura tradicional

Para ilustrar o uso da arquitetura tradicional foi desenvolvido um exemplo simples que escreve "Olá " na tela e quando o usuário apertar o botão "Próximo" , a mensagem é trocada para "Mundo" e o item do menu é trocado para "Voltar".
As mudanças de tela são controladas pelo softbutton da esquerda no celular. Softbuttons são teclas especiais (esquerda,direita e meio) que podem ter funções definidas pelo programador como por exemplo: aceitar, cancelar, sair ou ativar. A figura 1 abaixo ilustra os softbuttons presentes nos aparelhos S60.

Figure 1: Softbuttons presentes em um aparelho S60



Além das classes mostradas no tutorial anterior, existem ainda outros elementos que compõem a aplicação, como o arquivo de recuros, os arquivos de internacionalização, e os arquivos de definição de componentes e especificações de projeto. Esses elementos serão explicados através do próprio código da aplicação desenvolvida.


10.1 Estrutura das pastas de uma aplicação

Antes de detalhar a fundo os elementos da aplicação, é importante antes entender como está estruturada a aplicação. A figura abaixo ilustra a estrutura das pastas da aplicação utilizada nesse exemplo. Lembrar que esse é um padrão utilizado e os nomes das pastas são convenções utilizadas para desenvolvimento e testes nos emuladores S60.

O exemplo contém a seguinte estrutura de pastas:

Figure 2: Estrutura de Pastas do Exemplo HelloWorld


  • data, o qual contém os arquivos de recurso (.rss) que são usado para interface gráfica e localização (linguagens e internacionalização);

  • help, o qual contém arquivos para criação da documentação e arquivos de ajuda;

  • gfx, a pasta que abriga os arquivos gráficos usados no exemplo;

  • group, a pasta que contém os arquivos de configuração e especificação do projeto (.mmp e bld.inf) utilizados para definir as propriedades dos componentes do projeto de uma forma indenpendente de plataforma e compilador;

  • inc, pasta que contém os arquivos-cabeçalho (.h) do projeto (Neles contêm as declarações de classe e variáveis utilizadas nos arquivos - fonte (.cpp));

  • sis, pasta que abriga os arquivos de instalação e execução necessário (.sis) para instalar o aplicativo no aparelho móvel;

  • src, contém os arquivos-fonte da sua aplicação.



10.2 Arquivo de Recursos

O arquivo de recursos (.rss) é um arquivo texto encontrado na pasta data e é usado para especificar elementos visíveis para o usuário. Outra função é especificar layout de componentes como menus, caixa de diálogos e outros. A sintaxe é similar a de um arquivo C++, mas com algumas particularidades. os comentários são no mesmo formato e as declarações de pré-processamento como #include , #define, #if, #else e #endif são aceitas. O arquivo é dividido em cabeçalho e corpo.
O cabeçalho do arquivo de recurso do exemplo é mostrado na figura 3. Primeiro (linha 1) é o campo NAME que é um identificador de 4 letras que não deve ser igual a outro arquivo de recurso do programa ou do sistema. A área de include (linhas 2 a 7) funciona como em um arquivo C ou C++. O campo RSS_SIGNATURE (linha 8) pode ser deixado em branco pos seu conteúdo é ignorado, mas ele deve existir no arquivo para não causar um erro de compilação. Na linha 10, o recurso define o documento default usado pela aplicação. É obrigatório estar no cabeçalho , mesmo estando vazio.


Figure 3: Cabeçalho do Arquivo de Recurso (HelloWorld.rss)


Na linha 11, definimos o recurso EIK_APP_INFO, que é a estrutura padrão para a definição do itens a serem construídos (como o menu bar) e os botões (Control Button Area CBA) na tela usados na aplicação. A declaração na linha 13 (cba) usa propriedades existentes do arquivo avkon.rsg (R_AVKON_SOFTKEYS_OPTIONS_EXIT) , o que para o arquivo de recursos provê o texto "Options" em cima do botão esquerdo do aparelho e "Exit" do lado direito.


Figure 4: Menu Inicial do Exemplo


Para definir um menu, tipo o apresentado na figura 4 e quais itens devem aparecer nesse menu, é utilizado o recurso denominado MENU_BAR (linha 1) mostrado na figura 5. Normalmente, um MENU_BAR contém um único MENU_TITLE (linha 3). Ele especifica o título do menu e o nome do recurso que vai definir os itens do menu. No Série 60, o item txt que define o título não é utilizado e pode ser omitido no código. O MENU_PANE (linha 4) contém os itens do menu como mostra a parte de baixo da figura 5.


Figure 5: Declaração do Menu e itens no arquivo de recurso


Nesse menu existem 2 itens. O primeiro, após selecionado, avança e o outro volta à tela que o chamou. O MENU_ITEM tem dois campos, o nome no campo "txt" e o ID do comando (linhas 7 e 8). O comando indica qual evento deve ser retornado pelo framework da aplicação quando uma opção é selecionada e o nome txt provê o nome que será escrito no item do menu.

Os comandos são definidos em arquivos separados com a terminação .hrh e estão armazenados na pasta inc do projeto. Para não haver conflitos com os IDs dos comandos do sistema, é recomendável que os IDs definidos pelo usuário comecem com 0x600 como mostrado na figura 6. No arquivo HelloWorld.hrh também definimos o UID3 (linha1) utilizado para diferenciar os aplicativos Symbian dentro do aparelho. (Mais informações ver o primeiro tutorial postado aqui.)
Para exemplo foram definidos 2 comandos e seus respectivos ids: o comando "Próximo" (ECommand1) representado na linha 2 e o comando "Voltar" representado na linha 3.

Figure 6: Arquivo de definição dos IDS dos comandos do menu (HelloWold.hrh)


Dentro do arquivo de recursos (HelloWorld.rss) também se encontra outras declarações de recursos como TBUF que podem ser lidos durante a execução do código através da classe StringLoader. Esse recurso funciona como atalhos já preparados para uso posterior no código.
Há também outro recurso LOCALISABLE_APP_INFO que define as informações sobre a localização da aplicação como o identificador e ícone da aplicação que irá aparecer no menu do Symbian S.O. A figura 7 abaixo ilustra os recurso citados acima.


Figure 7: Declaração de recursos de localização e constantes


10.3 Definição de Comandos

Os menus são criados nos arquivos .rss mas as ações são tomadas pelas funções:

  • HandleCommandL(), nas classes CAknAppUI ou derivadas de CAknView() e;
  • ProcessCommandL(), nas classes derivadas de CAknDialog()
A figura 8 mostra um exemplo de implementação de como manipular os eventos do menu mostrado na figura 5. A implementação é basicamente apenas um switch que usa os IDs como parâmetro e encontra-se na classe AppUI da aplicaçã0 (nesse exemplo HelloWorldAppUi.cpp). Além dos dois itens do menu, que são ativados pelo softbutton da esquerda, é necessário manipular o evento de saída que é gerado pelo softbutton da direita (EAknSoftKeyExit). Outro evento que é obrigatório a ser manipulador é o EEikCmdExit, que é o evento gerado pelo sistema operacional quando o usuário deseja fechar a aplicação.
A ação ECommand1 muda o texto mostrado na ela e muda o valor da flag que define quais itens do menu devem aparecer. De forma semelhante, o ECommand2 faz a mesma coisa mas com diferentes valores para as duas ações. A implementação da função MudaTexto é explicada posteriormente nesse tutorial.
Uma observação importante é a referência ao caso em que nenhum dos comandos foram tratados, ou seja, se for chamado um comando não referenciado. Isso causa uma operação anormal do sistema que o leva a gerar o código desse erro pela função Panic a ser tratado pelo usuário. Detalhes sobre Panic e tratamento de erros serão tratados em um próximo tutorial.


Figure 8: Código para manipular eventos do menu (HelloWorldAppUi.cpp)


Outra funcionalidade dos menus é a possibilidade de esconder e mostrar dinamicamente os itens. A figura 9 mostra como foi feito para esconder o item "voltar", o item "próximo" da tela e como foi usada a variável flag (conforme a figura 8) declarada no arquivo-cabeçalho HelloWorldAppUi.h para controlar isso. O parâmetro aResourceId de entrada deve ser usado para saber qual recurso (no caso o menu) deve ser alterado. A função SetItemDimmed() é responsável por definir a visibilidade dos itens e tem dois parâmetros de entrada. O primeiro é o ID do comando que vai ser selecionado e o segundo é um booleano que deve ser ETrue (lembre-se que os tipos primitivos são diferentes do padrão C++) para esconder o item e EFalse para mostrar o item.

Figure 9: Código para criar um menu dinâmico (HelloWorldAppUi.cpp)

10.4 Constantes no arquivo de recurso

A forma mais recomendada para inserir textos na sua aplicação é utilizar a conhecida técnica de internacionalização. As strings devem ser agrupadas em um arquivo . rls encontrado na pasta data. As strings e constantes definidas são armazenadas nesse arquivo (HelloWorld.rls). Para utilizar essas strings dentro do aplicativo, é necessário criar um recurso denominado TBUF no arquivo de recursos e a sintaxe é mostrada no trecho de código da figura 7. Para chamar dentro do aplicativo esse r_label_text, deve ser usado caixa alta em todo o nome como mostra o trecho do HelloWorldAppUi.cpp do parâmetro de entrada da função MudaTexto() chamada dentro do switch-case demonstrada na figura 8.
O texto do menu pode ser usado diretamente como mostrado na figura 5 e não é necessário criar um recurso TBUF.
Um exemplo de constantes criadas é mostrada na figura 10 abaixo onde definimos o nome identificador do aplicativo (linhas 2 e 3) e texto de botões e menus (linhas 4,5 e 6,7 respectivamente).

Figure 10: Definição dos textos e constantes da aplicação (HelloWorld.rls)

10.5 Função para iniciar e mudar o texto

A função para mudar o texto exibido na tela é mostrado na figura 11. Basicamente, ele utilizao ID de um recurso de texto fornecido como parâmetro de entrada (mostrado com mais detalhes no item 10.4 do tutorial), cria um objeto para converter o recurso em uma string (linhas 4 e 5) que pode ser usado pelo objeto iLabel (definido no arquivo-cabeçalho HelloWorldAppView.h), que é responsável por mostrar o texto na tela (linha 6). Depois deve usar a função SizeChanged () (linha 8) para mudar o tamanho que deve ter esse iLabel na tela.

Figure 11: Função para mudar o texto na tela (HelloWorldAppView.cpp)



A posição e tamanho do texto na tela é definida por uma constante KLabelPosition e pelo tamanho mínimo necessário para se escrever o texto na tela (linha 1). Essa constante KLabelPosition é definida mais acima no arquivo fonte HelloWorldAppView.cpp conforme mostrado na figura 12.



Figure 12: Função para iniciar o texto na tela (HelloWorldAppView.cpp)

A inicialização da tela do aplicativo (chamada da função ConstructL) com o texto também segue o mesmo procedimento que a mudança de texto pela função MudaTexto. Apenas a diferença é que ele inicializa a variável iLabel (membro da classe) . Lembrar que o uso de variáveis locais como labelText (String) devem ser destruídas após o seu uso, por isso a chamada da função PopAndDestroy().
A figura 12 mostra o construtor ConstructL da AppView e inicialização da tela.

10.6 Gerando o Projeto

Para gerar o projeto, inicialmente é necessário o arquivo de definição de componentes, bld.inf. Este arquivo não tem nenhuma mudança com relação ao descrito para a aplicação em texto. Este arquivo apenas aponta para o arquivo de especificações de projeto (mmp). O código do bld.inf e do mmp podem ser visto nas figuras 13 e 14 respectivamente. É fácil ver que esta aplicação inclui mais arquivos de código fonte e bibliotecas, além de arquivos de recursos.

Figure 13: Código do arquivo bld.inf



Com relação ao alvo (target) (linha 1) e ao tipo de alvo (targettype) (linha 2), ambos denotam uma aplicação executável (exe). Isso define que esta aplicação tem uma interface gráfica, definindo assim o número do UID1.
O campo UID (linha 3) tem dois números: o primeiro 0x100039CE, indica que esta é uma aplicação exe com interface gráfica, e o segundo é o UID3 da aplicação, que identifica unicamente esta aplicação Symbian. O valor usado para o UID3, 0xE91FFE76, foi escolhido dentro da gama de números de teste (disponível para desenvolvedores Symbian). Caso esta aplicação fosse uma aplicação comercial, um valor deveria ser pedido para a Symbian.

Figure 14: Código do arquivo HelloWorld.mmp

O outro campo diferente é o camp LANG (linha 4) , este representa a lingua disponível pela aplicação através de 2 dígitos definido no arquivo e32std.h. O padrão adotado é o SC (lingua inglesa padrão internacional).

Por fim, para compilar o código é necessário executar os mesmos passos mostrados no artigo Introdução ao Symbian C++ : Usando o Carbide C++ aqui.


10.7 Conclusão

As figuras 15 e 16 abaixo ilustram o aplicativo descrito nesse tutorial em execução. A figura 15 mostra a tela inicial e a figura 16 a tela final da aplicação.

Figure 15: Menu da Tela inicial do Exemplo


Figure 16: Menu da Tela Final do Exemplo

Pode ser observado que o desenvolvimento de uma aplicação com interface gráfica em Symbian é uma tarefa mais complexa, tendo em vista os detalhes necessários para a implementação. Entretanto, desenvolver em Symbian C++ pode valer a pena, pois como é uma aplicação nativa no ambiente no qual ela irá rodar, pode significar acesso facilitado a diversos recursos do aparelho, tais como câmera, caixas de som, microfones, etc. Ainda tem a velocidade que é muito mais rápida do que outras aplicações.

O objetivo deste artigo foi apresentar os conceitos introdutórios de desenvolvimento de uma aplicação Symbian, permintindo que se tenha conhecimento mínimo sobre o uso da linguagem Symbian C++ para posterior desenvolvimento de aplicativos mais complexos .


O código fonte exemplo dessa aplicação para download encontra-se nesse link.

10.8 Referências

http://wiki.forum.nokia.com/index.php/Criando_um_Hello_Word (Forum Nokia Wiki em Português)

http://www.forum.nokia.com/document/Cpp_Developers_Library/ (C++ Developer Library 1.1)

http://mobideia.blogspot.com (Blog Mobidéia por Marcel Caraciolo)

Revista WebMobile, número 5. Artigo Desenvolvimento C++ para Symbian: Interface Gráfica. Autores: Eduardo Peixoto e Renato Faria.






Apenas postando algumas idéias interessantes que venho tendo para possíveis projetos de desenvolvimento mobile!

*** Abertura de Portões Automáticos ***
Utilizar aparelhos móveis para substituir controles de portões de garagem automáticos. A idéia é usar alguma tecnologia de comunicação sem fio (Zigbee, Bluetooth, etc.) para estabelecer a comunicação entre os sensores do portão e o celular. Também usar algum tipo de criptografia ou maneira de identificar o usuário. Pois, tem o problema de o aparelho ser furtado ou ter sido perdido.

*** Repositório de Atualizações de aplicativos ***
A idéia seria ter um repositório de todos os aplicativos instalados no seu celular e através de um aplicativo, ele possa avisar sempre quando há algum atualizacão ou nova versão daquele aplicativo disponível para download.

O serviço permitiria que os desenvolvedores pudessem fazer o uploado dos seus aplicativos gratuitamente no serviço (servidor). Já no smartphone, o aplicativo cliente iria consultar o serviço via Web e informar ao usuário sobre atualizações e novas versões de aplicativos para os usuários.

Os benefícios dessa aplicação seriam a não necessidade de checar manualmente diferentes sites se existe uma nova versão disponível de algum aplicativo instalado no smarthpone e a criação de até uma lista de recomendações baseado na lista de aplicativos do usuário ("usuários que tem tem o aplicativo X instalado também instalou aplicativo y)

Para desenvolvedores, seria uma solução centralizada e gratuita para fornecer seus aplicativos e não teria a necessidade de desenvolver alguma aplicação caseira para automatizar o processo de atualizações dos seus aplicativos.

Para os donos do serviço, poderiam ter propagandas no inventório do cliente. Propagandas baseadas na localização do usuário, linguagem, aplicações instaladas, etc. Ainda há possibilidade de o dono desse serviço se associar a empresas que tem soluções comerciais que seriam facilmente entregues através deste seviço.

*** To-do list ***

Construção de um to-do list que fosse integrado tanto via web como via celular e permitiria que o usuário pudesse adicionar e consultar informações e tarefas a serem realizadas. Isso poderia eliminar agendas e poderia facilmente ajudar ao usuário final que também deseja editar e consultar tas informações no seu pc/notebook pela internet.

Motorola pretende separar sua divisão de telemóveis

Fiquei um pouco surpreso ao ver essa notícia sobre a possibilidade de venda da divisão de celulares da Motorola. A Motorola ao ver que seu lucro nesse setor não está mais o mesmo, principalmente depois de perder o segundo lugar em vendas de aparelhos para a Samsung, decidiu separar a sua divisão de telefones móveis após o anúncio do fechamento das bolsas de valores. Não sei porque, mas acho que isso pode significar o mesmo futuro que a Siemens/Benq teve. A Siemens que tinha também uma divisão de telefones começou a dar prejuízo no mercado. Então decidiram vendê-la a Benq formando a Benq Siemens. O que de fato é que nem a Benq também conseguiu tanto sucesso e hoje está quase sumida sem lançar mais aparelhos novos. Espero que a Motorola também não tenha esse mesmo desfecho. Afinal de contas, a Motorola é uma empresa de grande porte e histórico com altíssimo nível e de grandes feitos no cenário de tecnologia móvel.
A notícia pode ser lida aqui na Info Online.
Através do blog Mobilidade é tudo, descobri um projeto bem interessante da operadora VIVO. O projeto que já está implantado em São Paulo, em uma das lojas da Vivo oferece a seus visitantes o Vivo Asteroids. Esse é um jogo que permite que os visitantes da loja controlem o jogo que acontece em uma TV de plasma na entrada principal da loja. O controle é pelo próprio celular do usuário através da tecnologia Bluetooth! Muito boa a idéia da Vivo em incentivar os seus usuários e clientes a experimentar o que os seus celulares têm e não sabem!
Segue abaixo um vídeo com o Vivo Asteroids em execução! Mais informações no site do projeto.



Dicas e Artigos sobre preparação para entrevistas de T.I

Para os interessados em dicas e informações sobre como se preparar para entrevistas na área de tecnologia de informação e informática, André Furtado postou um post no blog dele bem legal indicando alguns artigos em inglês para leitura.
Recomendo a todos!

Tutoriais sobre a Tecnologia Bluetooth


Aos interessados sobre como funciona a tecnologia Bluetooth (IEEE 802.15.1), há um artigo bem legal dividido em 2 partes no site da Devmedia. O autor do artigo propõe-se a explicar o funcionamento da tecnologia Bluetooth e no fim desenvolver um aplicativo embarcado em um dispositivo móvel que se comunique com um servidor desktop via bluetooh.
Mais detalhes, os links do tutorial 1 e tutorial 2 aqui.
Fico feliz que meus tutoriais estejam ajudando a divulgar a plataforma Symbian e a linguagem de programação C++. Isso me faz continuar escrevendo e gerar novos tutoriais que possam ser úteis a comunidade de desenvolvedores de dispositivos móveis no Brasil.
Por sinal, recebi um comentário muito legal de um dos moderadores da comunidade do orkut sobre a plataforma Symbian com mais de 1500 usuários cadastrados. Acho que toda comunidade, artigo, blog, tutorial é bem vindo e tem o propósito comum que é divulgar e ajudar aos interessados a usar todo o potencial que as plataformas Symbian tem a oferecer. Especialmente, com a chegada da rede 3G que irá impulsionar a venda de Smartphones (minha previsão pessoal) . E quem sabe sinônimo de smartphone é sem dúvida os aparelhos com Sistema Symbian e outros também como BlackBerries, Linux e Windows Mobile.
Eu já participo da comunidade de Symbian (Antes mesmo do comentário ser enviado) e quero convidar a todos interessados a participarem. Tem muito material legal e um fórum para ajudar a todos que querem tirar suas dúvidas.

Agradeço mais uma vez os comentários ( agradecimentos especiais a Cláudio, que enviou o comentário). E vamos trabalhar juntos para divulgar o poder da mobilidade que pode contribuir bastante nas atividades comuns do dia-a-dia.

Comunidade de Symbian no orkut, aqui.

Acelerômetros em Ação !

Mais uma vez mostrando o poder do acelerômetro no N95 através do aplicativo ShakeSMS. A idéia é simples você recebe uma mensagem, o celular notifica o usuário o recebimento. O que o usuário faz? Clica em diversos menus até.... Não, não! Simplesmente você balança seu aparelho, e o aparelho automaticamente abre a mensagem de texto. Após lido, para fechar... O que fazer? Basta balança-lo novamente!

Vejam o demo no vídeo abaixo:


Uma pesquisa feita pela empresa M: Metrics sobre o uso de celulares para downloads de música e como players de aúdio revela que baixar música para celulares não se provou uma atividade popular. 20% dos usuários de celulares em todo o mund ouvem música em seus aparelhos, mas 83% deles transferem músicas para seus PCS ou players digitais, em lugar de baixá-las diretamente de um serviço de download.

Isso levou executivos do setor de música a imaginar se o futuro da música para os aparelhos móveis não será mais semelhante ao modelo de serviços via Web que vem ganhando terreno na Internet - sob o qual fãs recebem música de múltiplas fontes, incluindo uns dos outros - do que ao modelo de compra e download que vem sendo seguido até o momento.

Qual a conclusão ? Conteúdo musical compartilhado em massa pelo usuário. Aparelhos celulares servirão como repositórios imensos de música e os seus usuários farão o compartilhamento dessas músicas através de um serviço que permita a facilidade e busca de todo esse conteúdo. Não tenho dúvidas, que o futuro será celulares com seus fones de ouvido bluetooth preenchidos até o topo de mp3s e um serviço que permite identificar via bluetooth, wi-fi e 3G músicas dos seus amigos e do seu estilo músical e compartilhá-las.

Fonte: InfoExame
Interessante parceria da TIM com o Google que lançam a versão móvel do Youtube adaptado para celulares. O serviço que já está disponível para clientes da TIM de pré e pós-pagos, enconta-se no portal TIM WAP através do ícone do Youtube - não é necessário fazer download.
Claro que a partir do momento que o usuário clica em um vídeo, que é exibido por streaming, o cliente paga R$ 1,50 por megabyte trafegado (é cobrada à parte, mesmo que o cliente tenha um pacote de dados). o serviço já foi testado e homologado em 40 aparelhos do portfólio da TIM.


Que bom que as operadoras abrem os caminhos para os novos serviços de dados através de multimídia como áudio e vídeo. Sem dúvidas o 3G será a porta de entrada dos mp3s e vídeos dentro dos celulares!

Fonte: Info Online
Software é instalado no Nokia N82 / Divulgação
Post bem interessante publicado pela INFO Online falando a respeito de uma nova aplicação para celular q ue lê textos para quem tem deficiência visual e dislexia.
O software é compatível com o celular N82, da Nokia, com sistema operacional Symbian. Equipado com uma câmera digital de 5 megapixels, o aparelho deve ser usado para fotografar textos, que serão “lidos” por um p rograma de reconhecimento de caracteres.
Segundo a empresa que o desenvolveu , knfb Reading Technology, o software também reconhece, com facilidade, rótulos de produtos e notas de dinheiro (dólares).

Mais informações pelo site www.knfbreader.com.

O fórum de desenvolvedores da Sony Ericsson lançaram dois artigo bem interessantes. O primeiro artigo discute a gravação de sons em diferentes formatos utilizando a Mobile Media API (JSR 135) disponível nos aparelhos celulares (JP-8) da Sony Ericsson. Os formatos podem ser de AMR (.amr) e PCM (.wav). Os sons ppodem ser também gravados diretamente a um streaming (bom saber disso!) ou a um arquivo. O tutorial no link abaixo discute com exemplos o uso dessa API.

JSR 135, recording PCM (.wav) sound in JP-8 (em Inglês!)

O segundo artigo descreve o uso da API de JavaME (JSR-238) para internacionalização de formatação de dados como números, strings, horários existentes nos celulares Sony Ericsson (JP-8). Essa API permite formatar seus dados de acodo com o local que você (país) se encontra com algumas codificações. No tutorial disponível no link abaixo, demonstra um exemplo de como usar essa API.

JSR 238, localize your data with Internationalization API

Prestem atenção na seguinte notícia:

"A UE (União Européia) anunciou um plano de implementar um sistema eletrônico de registro nas fronteiras e no transporte aéreo por meio da biometria.

A medida, que ainda está sendo avaliada, utilizará o sistema eletrônico de registro de entrada e saída nos países do bloco a fim de obter maior controle sobre imigrantes ilegais.

Segundo o comissário de Justiça da UE, Franco Frattini, o registro seria similar ao sistema de escaneamento eletrônico de retina e impressões digitais implantado pelos Estados Unidos.

A medida, segundo ele, é parte de uma série de iniciativas a fim de usar tecnologia moderna para aumentar o controle sobre cidadãos de outros países que entram legalmente no bloco e se tornam imigrantes ilegais após ultrapassar o prazo permitido de permanência. "

Retirada da Folha Online, leva-me a concluir 2 fatos:

1) Novos sistemas de segurança estão sendo implantados nos países desenvolvidos com o objetivo de reforçar a segurança na entrada de imigrantes;

2) No Brasil, ainda está no início a implementação desses sistemas... tanto que os primeiros passaportes com chip e informações biométricas estão aparecendo agora. Mas cadê os leitores e as máquinas de segurança para identificar essas informações nos aeroportos brasileiros? Será que o Brasil não irá implementar esse sistema nos seus aeroportos a fim de aumentar a segurança? No fim issso significa ... mercado novo, idéias novas e alguém especialista em desenvolvimento de sistemas de segurança que estará pronto para ser sugado no mercado, fora a $$$ que vai ser exponencial!

Está aí meu recado!



Telas GPS extremamente avançadas

Estava navegando em alguns blogs quando encontrei essas 2 telas extremamente legais que eu pude ver em um GPS até agora.
O Navigon 8110, que conta com uma tela cheia de recursos e com um visual muito bom.

navigon-8110.jpg

O segundo é o Panasonic CN-MP50D GPS system, que tem um visual ainda mais avançado, com uma tela repleta de informações e ainda uma visualização espetacular.

panasonic-cn-mp50d.jpg


Imagine isso na tela de um celular ein?! Ia ser bombástico!

Veja mais em Ubergizmo.

Fonte: rodrigostoledo.com
Interessante post retirado do site geek falando sobre uma pesquisa sobre celulares transformados em mouse. De acordo com o artigo, os pesquisadores das universidades inglesas estão trabalhando em um novo uso para telefones celulares com câmera integrada, a fim de transformá-los também em mouses.A idéia por trás seria usar a câmera que localizaria as coordenadas do monitor e o software que ajudaria a controlar o cursor na tela. Todavia, ainda que possua um alto potencial, a tecnologia precisa de inúmeras melhorias até que possa ser disponibilizada comercialmente.

"A captura de imagem e taxa de processamento no celular ainda é um tanto lenta e você não pode mover o telefone tão rapidamente quanto gostaria. Isto é o que tentaremos resolver em um próximo protótipo", declarou Nick Pears, pesquisador da York envolvido no projeto, ao site VNUNet.

Segundo o site neozelandês Geekzone, vários celulares equipados com Bluetooth já oferecem funções de apontador e controlador de dispositivos remotos, como por exemplo os da linha Sony-Ericsson, em que alguns modelos podem exercer controle remoto sobre PowerPoint e Windows Media Player.


Fonte: Geek
Um post interessante publicado pelo Bruno Ghisi falando sobre diversos projetos (open-source e comercial) para desenvolvimento de interfaces gráficas em JavaMe para celulares. Seguem abaixo os links dos projetos encontrados com informações adicionais e API para download. Acho que agora não teremos problemas para desenvolver interfaces em baixo nível.

De http://j2me.ngphone.com/opensource/ui.htm (há outros projetos também nesse site):

Outros (pagos):

Artigo fala sobre o Google Android e as suas expectativas.

Muito bom esse artigo em inglês que eu encontrei na internet. Ele fala sobre o lançamento da nova plataforma da Google para dispositivos móveis : Android. O autor do artigo fala sobre o futuro do mesmo e lembra que para que o Android dê certo não é só uma questão de marketing. Exige que a s grandes "Fabricantes" também usem a plataforma Android nos seus novos aparelhos e que novas funcionalidades (que possam acessar o core dos aparelhos) estejam disponíveis aos desenvolvedores. Por enquanto, ainda tem muito caminho para se pecorrer e a Google vai precisar mostrar suas forças se quiser um sistema suficientemente estável e completo que vá ao encontro das plataformas Linux x Symbian x Windows Mobile.
Leiam o artigo completo aqui. (Em Inglês!).

Link to the story of the Android's New Clothes
Primeiros celulares na Índia já estão vindo com uma nova tecnologia que permite que você transfira seu cartão de crédito para o seu aparelho celular. A idéia é eliminar todos os seu cartões da carteira e usar apenas seu celular para efetuar os pagamentos substituindo o cartão. De acordo com a empresa Atom Technologies, responsável pela implementação, o sistema armazena um código de barras 2-D que representa o cartão de crédito. Pórem além de o código ser ilégivel para um ser humano, o que evitaria o uso do cartão caso ocorra o furto ou perda do aparelho, o usuário teria que fornecer o PIN para efetuar uma transação. Interessante, não ?
Ah, só um detalhe! O sistema que roda nos aparelhos celulares é baseado em JavaME. Então apenas aparelhos com Java embutido teriam o poder de ter esse aplicativo rodando.
Mais informações, via o site em inglês:


Swiping cell phones for payment in Mumbai


Fonte: HinkMond

Tutorial já no forno!

Para os interessados em Symbian e Symbian C++... Estou já escrevendo um tutorial explicando passo a passo a implementação e desenvolvimento de um aplicativo utilizando interface gráfica em symbian C++. Também estou preparando algo legal para Python for S60! Fiquem antenados no meu blog!

[]'s
Mais uma vez pedindo desculpas pela ausência no meu blog. Mas muitas atividades estão ocorrendo no fim desse mês de férias. Mas não posso deixar de escrever algumas idéias e novidades no meu blog.
Primeiramente, começamos com as notícias interessantes! Estava eu navegando em alguns blogs quando encontrei essa foto bastante inusitada! (Ver abaixo.) Um Iphone com um aplicativo capaz de tocar guitarra através de toques com os dedos na tela do aparelho! Imagino o som como deve ser.... Já pensou se for possível gravar as músicas para trabalhar numa guitarra depois?
novidade é a possibilidade de tocar sguitarra na tela do aparelho! Tudo bem que o som deve ser bem tosco, mas que é uma funcionalidade bem bacana é!! Já pensou se for possível gravar algum riff para trabalhar mais tarde na guitarra de verdade? Muito legal!! Veja mais neste link.

iphoneguitar.jpg

A segunda notícia vai para os fãs do Nokia N95 e da linguagem de programação Python. Como não é novidade, já postei alguns vídeos sobre o poder do acelerômetro do Nokia N95. Nesse novo exemplo, através de um adaptador bluetooth, um programa instalado no PC e o Python para S60 instalado no celular você pode controlar games no computador utilizando o N95 como mouse ou joystick. Simplesmente genial! Vejam o vídeo abaixo e mais informações nesse link.




E para finalizar essa série de notícias, também coloco aqui um link para um artigo muito interessante mostrando todos os aparelhos nokia lançados no ano 2007. Bom para quem quer saber sobre a evolução e lançamentos dos principais aparelhos da Nokia em 2007.


Acho que é isso,
Até a próxima!

Futuro da Interação com os celulares

Achei interessante esse comentário feito pela Samsung a respeito das interfaces gráficas dos celulares no futuro.

"Adaptação da Interface para permitir a personalização para uma nova experiência. Aqui, ele mostra um exemplo da nova interface uGo da Samsung para os aparelhos (desenvolvido junto a Adobe), uma interface adaptativa que automaticamente responde aos costumes do usuário. A tela principal exibe um plano de fundo da tela no celular que muda de acordo com o local que o usuário se encontra e horário do dia que está no momento, adicionado com gráficos e imagens animadas que alertam o usuário sobre as propriedades do aparelho (carga da bateria, chamadas não atendidas, etc.). Por exemplo, a carga da bateria é exibida através de um balão de ar que está lá em cima sobre uma foto de um céu quando a bateria está cheia, mas que vai caindo em direção ao chão quando a carga da bateria começa a decrescer."


Concordo, que no futuro a interface do usuário será bastante customizada com diversas informações úteis e animações que facilitem a vida do usuário sem a necessidade de navegar através de menus até chegar no que ele deseja. O futuro é ter nos celulares o que hoje temos nos nossos desktops: Icones, Atalhos, Pastas, widgets, planos de fundo, protetores de tela, etc.
Vamos aguardar!

Baseado na notícia retirado do site Mutant's Musings.
A Nokia recentemente vem trabalhando em uma nova patente que pretende revolucionar a maneira de interação com os seus aparelhos celulares. Denominada de Nokia S60 Touch, essa tecnologia permite que através de sensores instaldos no aparelho o usuário possa interagir com o aparelho sem a necessidade de tocar na tela, ou seja, apena com os movimentos físicos da mão e o aparelho rastreia o movimento e responde de acordo com o movimento. Melhor que o próprio Iphone com sua tecnologia TouchScreen, ele permite um tipo de interação em uma nova dimensão! Claro que o usuário vai ficar confuso com a quantidade de movimentos que ele vai precisar memorizar, mas só o fato de interagir com o aparelho sem a necessidade de tocá-lo torna-se algo mais intrigante. A figur abaixo ilustra alguns movimentos que o usuário pode fazer e o celular responder de acordo com o movimento interpretado. Movimentos como selecionar, zoom, deletar,copiar, mover e outros estão entre os possíveis comandos reconhecidos pela essa nova plataforma. Realmente algo que a Nokia está desenvolvendo muito mais à frente do que existe atualmente!

Nokia's new mobile phone interface for an emotional phone


Mais informações sobre essa tecnologia, ver esse link.

Interessados em informações sobre Plataforma Symbian, JavaME e tecnologia Mobile. Recomendo o site Symbian Resources. Contém um grande acervo de artigos e tutoriais sobre plataformas relacionadas ao Symbian.

Google Maps no Iphone

Eis a eficiência do google maps funcionando em um IPhone. Detalhes interessantes são a facilidade de encontrar rapidamente as cafeterias da rede Starbucks com alguns cliques e a possibilidade de interagir com o aplicativo podendo ligar para as mesmas através dos números e endereços das franquias localizadas pelo Starbucks. Google Maps é realmente facinante! O vídeo encontra-se abaixo:


Morte do J9 (Palms) e Nascimento do novo Yahoo Go!

Triste notícia para os fãs do sistema operacional Palm OS. Parece que a máquina virtual Java para o sistema Palm Os a JVM J9 não será mais suportada pela Palm, inclusive até a disponibilização dela para o download será extinta. Mais informações via blog The Official Palm Blog.

A notícia boa para os fãs do Yahoo, é que ela está lançando um aplicativo o Yahoo! Go! 3.0 . Ela permite acessar diversos aplicativos e funcionalidades como e-mails, mapas, fotos, etc. Inclusive a equipe está trabalhando em um aplicativo que seja capaz rodar em qualquer aparelho independente do sistema operacional. A plataforma será aberta a desenvolvedores para a criação de novos Widgets e tem diversas parcerias como o Ebay, Myspace e Mtv.
Mais informações, aqui.

Desenvolvendo aplicações para Symbian OS S60

Achei um artigo bem legal no wiki do forum nokia, falando sobre as linguagens de programação e plataformas que se pode desenvolver para o sistema operacional Symbian. Já falei inclusive em um post anterior sobre essas linguagens e ferramentas.
Recomendo a todos darem uma olhada, no próprio site ele fala sobre os prós e contras das linguagens de programação disponíveis no Symbian.


Image:Possibilidades.JPG
Acabei de adicionar mais um tópico na segunda parte do tutorial Symbian C++ : O Ciclo de vida de execução de uma aplicação no sistema Operacional Symbian. O tutorial já se encontra atualizado e está diponível aqui.
Em breve, adicionarei a parte do design de views dos aplicativos Symbian e o exemplo do primeiro aplicativo customizado.

Tutorial : Symbian C++ : (UI e Estrutura da Aplicação) : Parte 02

1. Introdução

Na primeira parte desse tutorial foram introduzidos alguns conceitos sobre o sistema operacional Symbian e sua linguagem de programação correspondente chamada de Symbian C++. Nessa segunda parte, irei abordar um pouco mais sobre a estrutura de uma aplicação e como montar uma aplicação que explora os recursos gráficos do Sistema Symbian.
Esse artigo está dividido em seções. Na primeira seção, será descrita a estrutura de arquivos de forma mais aprofundada. A segunda seção aborda o tópico da arquitetura de uma aplicação no Symbian. Já a terceira parte é um exemplo para demonstrar os conceitos de uma arquitetura tradicional e seus elementos. No fim, concluímos com algumas breves considerações e a exibição de um aplicativo gráfico funcional para um celular série 60.

2. Arquitetura de uma aplicação

Para o desenvolvimento de aplicações com interface gráfica no Symbian, funcionalidades quem em outras plataforamas de desenvolvimento podem ser agrupadas em um único arquivo ou classe são separadas desde do início da sua concepção. Alguns exemplos dessas funcionalidases são o ponto de entrada da aplicação, a lógica da aplicação, o gerenciamento de eventos e as interfaces gráficas. Isso facilita a tarefa de separar a lógica de um programa da sua parte visual. No entanto, infelizmente, isso torna o entendimento de uma aplicação gráfica em Symbian mais difícil.

As aplicações com interface gráfica geralmente apresentam diversas funcionalidades no Symbian como: Exibir graficamente informações para o usuário e permitir a interatividade; responder a eventos iniciados pelo usuário e pelo sistema; ter a capacidade de salvar e recuperar os dados da aplicação; identificar-se unicamente para o sistema operacional; exibir informações sobre a aplicação para o sistema operacional; etc. Existe um conjunto básico de classes que formam a aplicação e algumas classes do sistema devem herdar tais classes a fim de obter as funcionalidades básicas para o funcionamento da aplicação. As classes que compõem a arquitetura da aplicação que provêem estas funcionalides são divididas nessas categorias: Application, Document, AppUi e View.

A classe Application tem uma função fixa e bem definida, que é de servir somente como ponto de entrada da aplicação e disponibilizar informações sobre a aplicação para o sistema operacional como o ícone e o nome da aplicação que deve aparecer no gerenciador de aplicativos, e o UID (Unique Identifier Number - número que identifica as aplicações Symbian) da aplicação. Esta classe tem um papel estático - ela não se envolve com os dados da aplicação ou com sua lógica.

A classe Document provê um contexto para a persistência dos dados da aplicação. Esta classe contém métodos para instanciar a classe de AppUI.

A classe AppUI é um repositório para várias notificações vindas do sistema operacional, como eventos de teclado ou de sistema. Esta classe irá gerenciar a forma como a aplicação irá tratar esse eventos, despachando para o View que deveria receber a notificação desse evento( por exemplo: a tela do formulário é a tela que deveria ser avisada (View) de que o usuário finalizou o preenchimento desse formulário (AppUI é quem avisa).

A View é uma representação dos dados da aplicação na tela. Ela não é uma categoria de classe de forma restrita. Existem diversas formas de se fazer o View na série 60, e serão demonstradas no decorrer desse tutorial.


Image:Classediagrama.JPG

Este diagrama demonstra de forma simples as classes que formam uma aplicação.

  • Application - Retorna o ponteiro da classe documento e o UID3 da aplicação.
  • Document - Realização a criação da Interface do Usuário (AppUi).
  • AppUI - Manipula eventos do teclado e é responsável pela criação do View.
  • View - Responsável por exibir controles para o usuário.

3. O framework

O framework do sistema operacional é a forma de como uma aplicação interage com o próprio sistema. Quando se deseja, por exemplo, finalizar uma aplicação, o sistema operacional se comunica com a aplicação por meio desse framework. Ele é formado por um conjunto de classes básicas que forma a base para todas as aplicações. Essas classes formam a estrutura necessária e encapsulam a comunicação entre a aplicação e o sistema operacional. O diagrama abaixo, também disponível nesse link, mostra as 4 camadas de classes do framework simplifcado para facilitar o entendimento.

Image:Derivacoesclasse.JPG

Figura 1: Arquitetura do Framework

A primeira camada é dividida em dois componentes fundamentais: o AppArc (Application Architecture) e o CONE (Control Enviroment). As classes no AppArc provêem a estrutura básica da aplicação e os mecanismos para retornar ao sistema as informações sobre essa aplicação e sobre os dados persistentes. Esse é um componente do Symbian e suas classes tem o nome iniciado com o prefixo "Apa", como CApaApplication.
As classes no componente CONE provêem mecanismos básicos para gerenciar a entrada de dados pelo usuário e criar a interface gráfica. Esse também é um componente do Symbian, e suas classes tem o nome iniciado por "Coe", como em CCCoeControl.

A segunda camada de classes pertence ao componente Uikon, também chamado de Eikon. Este componente contém implementações de interfaces gráficas que são consideradas independentes de plataforma dos diversos recursos existentes no Symbian. As classes desse componente têm o nome iniciado por "Eik", como em CEikApplication.

A terceira camada de classes é uma implementação das interfaces gráficas do Uikon para Séries 60. Ela é chamada de Avkon. A escolha de qual implementação (Avkon ou Uikon) suas classes deverão herdar é uma questão de projeto importante e deverá escolhida baseado em algumas considerações descritas posteriormente nesse tutorial.

A quarta camada é a camada específica da aplicação, e demonstra como você poder derivar as classes básicas de modo a construir a sua própria aplicação.

A maior parte das classes da primeira camada são abstratas, definindo apenas as assinaturas das funções que serão posteriormente utilizadas pelo framework. A segunda camada adiciona implementações comuns ao Symbian e já a terceira adiciona implementações específicas parao Série 60. Por fim a quarta adiciona as implementações específicas da sua aplicação.

As classes que compõem a última camada - Application, Document, AppUI e AppView serão detalhadas nessa próxima seção.


4. Classe Application

A classe da aplicação deve derivar de CEikApplication ou outra classe que derive desta, por exemplo CAknApplication) . Existem duas funções que devem ser implementadas por esta classe. A primeira função, CreateDocumentL() é utilizada para criar um documento, e por isso, deve retornar um objeto do tipo CApaDocument. A segunda função a ser implementada é a AppDllUID() e deverá identificar a aplicação, retornando seu UID. 'Na figura abaixo tem uma implementação comum dessa classe. Bom frisar a definição de uma constante estática KUidMyFirstProjectApp que deve conter estritamente o mesmo valor encontrado no arquivo mmp da aplicação (o arquivo de propriedades do projeto). Esse valor é retornado pela funçao AppDllUID(), o qual identifica a aplicação para o sistema operacional. Já a função CreateDocumentL() é utilziada para criar um documento padrão.
A grande parte das aplicações Symbian que utilizam esse framework já implementam de forma padrão as funções abaixo. Essa imposição faz parte do framework, ou seja essas funções devem estar definidas na sua aplicação e devem realizar estas ações. Esse é o comportamento esperado pelo sistema operacional de qualquer aplicação Symbian.

Figura 2: MyFirsProjectApplication.cpp



5. Classe Document

A classe Document deve derivar de CeikDocument (ou de uma classe que deriva desta, como, CAknDocument) . Em geral, esta classe instancia a lógica da aplicação e cria um objeto do tipo AppUI por uma chamada ao método CreateAppUil(). O AppUi é necessário para manipular os eventos do sistema. Como pode-se ver nessa classe, ela tem uma estrutura muito bem definidia, sendo pouco flexível assim como a classe Application. Eles devem obedecer a um comportamento específico, não sendo permitidos desvios deste comportamento.
A classe Document é a classe que essencialmente representa a persistência no programa, sendo responsável por abrigar os métodos para criar, abrir e modificar os arquivos de dados.Na figura abaixo pode-se ver um trecho de código dessa classe. Este código apenas cria um objeto da classe AppUI e retorna um ponteiro para ele.

Figura 3: Trecho de código do MyFirstProjectDocument.cpp

6. Classe AppUI

A classe AppUI deve derivar de CEikAppUi (ou de alguma classe que derive desta, como CAknAppUI), que por sua vez deriva de CCoeAppUI, que pertence ao controle do ambiente (CONE). É neste ponto que a ação de GUI efetivamente se inicia, tendo essa classe duas tarefas principais: Capturar os comandos para aplicação e distribuir eventos de teclas para os vários views da aplicação.
A maior parte das funções dessa classe não são abstratas ("Virtuais na convenção C++), ou seja, apenas tem suas implementações vazias. Isso faz com que o desenvolvedor só implemente as funções que ele vai realmente utilizar, livrando o mesmo de precisar implementar todas as funções existentes nessa classe.

Algumas funções importantes implementadas nessa classe são descritas rapidamente abaixo:

  • HandleKeyEvent() : chamada quando um evento de tecla pressionada ocorre;
  • HandleForegroundEventL() : chamada quando o aplicativo perde o foco ou obtém o foco novamente (rodando em background);
  • HandleCommandL(): chamada quando um comando é selecionado;
  • HandleSystemEventL(): chamada quando um evento de sistema é gerado;
Outra função importante dessa classe é a responsabilidade por criar e gerenciar os applications views.


Figura 4: Trecho de Código do MyFirstProjectAppUI.cpp


7. Classe AppView

A application View deriva do CONE CCoeControl ( ou qualquer uma que derive desta). De acordo com a forma de como a arquitetura da sua aplicação esteja sendo projetada, uma classe diferente poderá fazer o papel do AppView, mas o AppView sempre está ligado à classe que realmente desenha as informações na tela.


Figura 5: Trecho de código da classe MyFirstProjectAppView.cpp


8. Ciclo de vida de uma aplicação

Nessa seção iremos demonstrar os principais passos que o sistema operacional executa desde momento em que você seleciona o aplicativo a ser executado até o momento que a aplicação está efetivamente executando na tela ( o primeiro momento que ela se desenha na tela).

O ciclo de vida para o início de execução de uma aplicação Symbian se dá pelos seguintes passos:

  • Passo 1: Toda a aplicação com GUI para Série 60 deve implementar a função global E32Dll(). Essa será a primeira função que será chamada pelo sistema operacional quando ocorre a tentativa de iniciar a aplicação. É considerado o ponto de entrada do DLL e deve estar presente na sua aplicação.
  • Passo 2: O próximo passo do framework é chamar a função NewApplication(), que efetivamente cria o objeto da aplicação, retornando um ponteiro para o sistema operacional. Esta deve ser exportada pela aplicação.
  • Passo 3: Uma vez criado o objeto da aplicação, o framework chama a função ApDllUid(), encontrada na classe Application da sua aplicação (Ex: CMyFirstProjectApplication.cpp), que retorna o UID3 da aplicação. O valor retornado deve ser o mesmo encontrado no arquivo .mmp (especificações do projeto) da aplicação, e é usado pelo sistema operacional verificar se já existe alguma instância desse aplicativo sendo executada.
  • Passo 4: O próximo passo é a chamada ao método do CreateDocumentL() existente na classe Application (CMyFirstProjectApplication.cpp, por exemplo). Esse método retorna para o framework um ponteiro para um objeto do tipo CApaDocument, que aponta para o objeto da classe Document (CMyFirstProjectDocument.cpp que estende CAknDocument). Note que um ponteiro para a classe Application é passado para classe Document como parâmetro de forma que esta possa ser capaz de chamar o método AppDllUuid() para descobrir o UID3 da aplicação e gerenciar os arquivos dessa aplicação.
  • Passo 5: Agora o framework usa este ponteiro para criar o objeto AppUI (no exemplo, CMyFirstProjectAppUI) chamando o método CreateAppUiL().
Dessa forma, o framework tem ponteiros para os objetos principais da aplicação - Application, Document e AppUI, que foram obtidos a partir de uma estrutura específica na qual a aplicação foi construída. Esses ponteiros possibilitam ao framework chamar funções dessas classes para descobrir a UID3 e identificar a aplicação, no caso da Application; abrir ou modificar um documento, no cado da Document; repassar um evento do sistema, no caso da AppUI.

Esses ponteiros podem ser usados pelo framework para controlar a aplicação, repassando eventos específicos do sistema para o aplicativo.

Image:Sequenciainicializacao.JPG

Cada um dos métodos apresentados aqui precisam ser criados para o funcionamento adequado (minimo) de um aplicativo S60.

1) - O framework faz a chamada a função NewApplication() para criar o objeto da aplicação.
2) - CMyAppApp::CreateDocumentL() diretamente chama MyAppDocument::NewL().
3) - Construção da primeira e segunda classe é feita aqui.
4) - CMyAppDocument::CreateAppUiL() chama diretamente o construtor padrão c++ de CMyAppAppUi.
5) - O construtor padrão aloca memória para o objeto e inicializa seus membros com 0.
6) - MyAppAppUi::ConstructL() cria o container.
7) - Objeto do container é criado aqui.
8) - CMyAppContainer::SetMopParent() define o pai do container como o AppUI. Este procedimento é necessário se o container precisar utilizar scrollbars.
9) - CMyAppContainer::ConstructL() é chamado para realizar a construção em duas fases do container. Note que o TRect& é passado como referência para o container neste estágio. O container não será exibido até que CCoeControl::ActivateL() seja chamado.

9. Design da arquitetura

Iremos descrever agora o design da arquitetura do programa de um celular Série 60. Atualmente, existem 3 formas de implementar tal arquitetura: Arquitetura tradicional, Arquitetura baseada em componentes e Arquitetura Avkon com troca de views.
A principal diferença entre elas é a forma como manipulam os eventos e como é feita a troca de views dentro do programa, além de mudar a implementação desse View.

Na arquitetura tradicional, o elemento View herda diretamente de CCoeControl, que funciona como uma tela em branco que pode ser desenhada conforme a necessidade. Essa classe é comumente chamada de Container. Isso permite uma grande flexibilidade, mas exige várias linhas de código para desenvolver coisas mais elaboradas, o que se torna às vezes inviável em certas aplicações. Em termos de gerenciamento de eventos, o AppUI é o responsável por gerenciar os eventos inciados pelo usuário, ativando o Container de acordo com a lógica da aplicação.

Na arquitetura baseada em componentes, o AppUI também é a classe que possui os controles. A diferença é que esses controles herdam de uma série de classes específicas (que por sua vez herdam de CCoeControl) que implementam diversos componentes como listas, formulários e outros elementos gráficos pré-programados pelo sistema operacional. A grande vantagem nessa arquitetura é que podemos ter diversas funcionalidades já prontas sem a necessidade de codifica-las com uma aparência padrão do sistema operacional. A desvantagem é que essa abordagem não tem a mesma flexibilidade que a arquitetura tradicional oferece.

Na arquitetura Avkon a troca de views é específica do Avkon, ou seja, específica para a plataforma Série 60, e foi criada para ser utilizada com aplicações de múltiplas telas e múltiplas trocas de tela. Ela tem a mesma estrutura da arquitetura tradicional, com a idéia de container, mas existe outra classe entre o container e o AppUi que faz o papel do Appview e herda de CAknViewAppui. Essa classe é responsável por ativa/desativas os containers de acordo com os comandos vindos do AppUI e de forma que fique ativo apenas uma View no momento.
O CAknViewAppUi é também responsável por criar e destrur as views, e normalmente o faz de forma que os views não estejam ativos sejam destruídos, para economizar memória.

10. Exemplo usando a arquitetura tradicional

Em Breve!

10. Referências

http://wiki.forum.nokia.com/index.php/Criando_um_Hello_Word (Forum Nokia Wiki em Português)

http://www.forum.nokia.com/document/Cpp_Developers_Library/ (C++ Developer Library 1.1)

http://mobideia.blogspot.com (Blog Mobidéia por Marcel Caraciolo)

Revista WebMobile, número 5. Artigo Desenvolvimento C++ para Symbian: Interface Gráfica. Autores: Eduardo Peixoto e Renato Faria.
Lendo sobre notícias em geral na internet, encontrei essa notícia bastante interessante:

" O Hospital das Clínicas de São Paulo lançou um sistema que promete revolucionar o controle da diabetes. A nova ferramenta, chamada GlicOnline, ajuda o paciente nas refeições informando o tipo e quantidade de insulina que deve ser aplicada para compensar o nível de açúcar no sangue. O sistema funciona com qualquer celular com chip e linguagem Java, independente de operadora. (...) "

De acordo com o HC, o sistema tem cerca de 600 tipos de alimentos cadastrados, onde o usuário antes de se alimentar, mede sua glicemia, acessa o programa pelo celular e coloca o valor medido. O usuário então, também, deve digitar o alimento e a quantidade a ser ingerida. Minutos depois, recebe o dado sobre a dosagem de insulina que será necessária

De acordo com comunicado do HC, o sistema oferece em torno de 600 tipos de alimentos cadastrados, e usa medidas caseiras como colher de sopa. Antes de se alimentar, o usuário mede sua glicemia, acessa o programa pelo celular e coloca o valor encontrado. O usuário deve digitar, também, o alimento e a quantidade a ser ingerida. Minutos depois, recebe o dado sobre a dosagem de insulina que será necessária.
Assim, a nova tecnologia elimina a necessidade de o paciente fazer a contagem de carboidratos ou anotações a cada refeição, além de garantir um controle mais estável nas taxas de glicemia. Isso ajuda a evitar que a doença se agrave, com as possíveis conseqüência de problemas renais, lesões oculares e nos pés, entre outras. Gostaria de colocar algumas observações sobre essa notícia: 1) A tecnologia móvel também está se inserindo no mundo médico. Mais e mais sistemas estarão a disposição do paciente tudo via celular: lembretes para tomar os remédios, bulas, prescrições médicas, análise de temperatura, pressão do corpo, etc. 2) Nesse aplicativo específico, o HC fala em o usuário digitar as informações sobre alimento e quantidade a ser ingerida. Penso que no futuro não tão distante, o paciente apenas apontará a câmera do seu celular sobre o alimento, onde será feito o reconhecimento do alimento por imagens e por fim o sistema identifica e processa a dosagem de insulina que será necessária.


Pois é, não temos como negar que o futuro é a mobilidade à disposição do ser humano.

Fonte: Terra Informática

Artigo: Symbian C++ (Estrutura de um aplicativo) :: Parte 01

1. Introdução

Dando continuidade ao estudo da plataforma Symbian C++, irei descrever algumas peculiaridades da plataforma Symbian para celulares Série 60 (Mais informações, ver o primeiro post explicando os conceitos iniciais sobre a plataforma Symbian). Inicialmente, é importante frisar que a sintaxe para incluir bibliotecas, fazer comentários, definir classes e funções é a mesma da linguagem C++ para desktops, embora existam algumas diferenças e particularidades em comparação ao Symbian C++.

2. Symbian C++

A primeira diferença é que o Symbian C++ define seus próprios tipos primitivos (além de usar os tipos primitivos já existentes no C++) e recomenda aos seus desenvolvedores a utilizá-los. A razão para isso é que esses tipos customizados tem uma garantia de seu comportamento independente da implementação e são consistentes (por exemplo, um TInt tem sempre 32 bits). Esses tipos primitivos podem ser vistos na tabela abaixo:

Tipos Primitivos

Descrição

TInt8/TUint8

Inteiros de 8 bits com e sem sinal

TInt16/TUint16

Inteiros de 16 bits com e sem sinal

TInt32/TUint32

Inteiros de 32 bits com e sem sinal.

Tint/TUint

Inteiros com e sem sinal. Na prática, significa o mesmo que TInt32 e TUint32.

TReal32/TReal64/TReal

Números de ponto flutuante de precisão simples e dupla de acordo com a norma IEE 754. Equivalentes ao float e Double. TReal equivale a TReal64.

TAny

Equivalente ao void, e usado normalmente como TAny* (Um ponteiro para qualquer coisa)

Tbool

Boolean


Além disso, o Symbian OS define algumas formas diferentes de compilação de código-fonte. Os mais usados são listados abaixo:

* EXE (.exe) : Um programa com um único ponto de entrada E32Main(). A interface do usuário é limitada a uma janela de console (semelhante ao DOS). É importante frisar que esse tipo de aplicação não aparece no menu de celular, sendo necessária outra aplicação para iniciá-la.

*Dinamic Link Library (.dll) : Biblioteca de códigos com vários pontos de entrada. DLLS são carregadas por outros programas.

*Application (.app): Programas com uma interface gráfica com o usuário. Esa aplicação instala um ícone no menu do celular e pode ser iniciada diretamente.

Um projeto de desenvolvimento em Symbian é composto por vários arquivos, além dos arquivos com o código fonte. Os principais são bld.inf e .mmp. Eles são usados para guiar a compilação gerando arquivos específicos para o funcionamento do aplicativo. Existem outros arquivos envolvidos com interface gráfica, os quais serão explicados em um próximo tutorial.



3. Estrutura do Aplicativo

O arquivo bld.inf é um descritor de componentes. Ele indica para o ambiente de desenvolvimento como criar o script de compilação ( por exemplo , quais as especifações de projeto devem ser usadas parar criar os arquivos na construção da aplicação desejada). Este arquivo é um arquivo de texto comum que pode ser construído com qualquer editor de texto não formatado. Para ver um exemplo de um arquivo bld.inf, clique aqui.

O arquivo de especificações de projeto (.mmp) define as propriedades dos componentes do projeto de uma forma independente (Ex: helloworld.mmp) . Junto com o bld.inf, ele é usado pelo ambiente de desenvolvimento para criar o script de compilação da aplicação. Para ver o conteúdo de um arquivo .mmp, clique aqui .

O UID também é um item importante a ser explicado nesse tutorial e é amplamente utilizado nos aplicativos Symbian C++. O Unique Identifier Number (UID) é um identificador global de 32 bits e funciona da mesma forma que a extensão de um arquivo Windows, que é usada para definir o tipo do arquivo. Ou seja, todo arquivo criado por uma aplicação tem o UID da aplicação associada ao arquivo, permitindo que o sistema operacional relacione o arquivo à aplicação que o gerou. O UID possui três componentes: UID1, UID2 e UID3. O UID1 é definido pelo tipo de aplicação do campo TARGETTYPE do arquivo .mmp do projeto. O UID2 define um subgrupo para tipos de arquivos que compartilham o mesmo UID1. O UID3 serve para distinguir cada aplicação, e este é usado pelo sistema para associar arquivos a aplicativos. O Desenvolvedor deve pedir para a própria Symbian o seu UID3, de modo que 2 aplicativos diferentes não compartilhem o mesmo UID3. Na fase de testes, entretanto, podem ser usados algums dentre estes UID3 que a Symbian alocou para esse propósito: 0x1000000 - 0x0fffffff.


4. Construindo um aplicativo

É importante relembrar que os aplicativos Symbian são nativas para os dispositivos aos quais se destinam. Portanto, a construção final do executável deve ser compatível com o assembly do processador do aparelho, pois diferente de uma aplicação Java, o emulador não consegue rodar o arquivo construído para o aparelho celular uma vez que a arquitetura do computador (X86) é diferente da arquitetura dos aparelhos Symbian. Logo, se a plataforma alvo desejada for o emulador do PC, então a compilação deve ser feita para o tipo WINS (Windows Single Process). Se a plataforma alvo desejada for o dispositivo real, a compilação deve ser feita para o tipo ARMI. Durante o desenvolvimento usam-se os dois tipos - um para testar a aplicação no PC e outro para testar no dispositivo real.
Além da plataforma alvo, existem mais dois tipos de construção possíveis: a compilação do tipo "Debug" (undeb) e a compilação do tipo "Release" (urel). A compilação para debug habilita uma série de funcionalidades (escritas em forma de macros específicas) como assertivas e checagem de balanço de heap. Essas funcionalidades são desabilitadas no tipo "release" , visto que já no lançamento do aplicativo o mesmo deve estar totalmente testado e não precisa mais delas.

O ponto de partida de um aplicação é através da chamada da função E32Main(), responsável por iniciar a aplicação e aloca algumas variáveis e classes. Por padrão, a declaração do E32Main é formadaa por GLDEF_C TInt E32Main() { ... } . Onde GLDEF_C indica que ela é uma função global, o TInt é o tipo de retorno da funçã0 (nesse exemplo retornando um inteiro) e a assinatura da função formada pelo nome E32Main.

Uma importante convenção na codificação de aplicativos Symbian é o uso da letra L no fim do nome de algumas funções (Exemplo: MainL() ou ConsoleMainL()). Esse formato permite identificar as funções que podem falhar, e que elas não gerenciam essa falha internamente (leave). Portanto, essa convenção de colocar um L no final é muito importante.

Alguns outros arquivos importantes que fazem parte da aplicação é o arquivo .pkg, que é um arquivo de diretivas para criar o pacote de instalação .sis. Esse arquivo .sis é levado ao aparelho onde ele é instalado para execução nos dipositivos reais.


5. Gerenciamento de Erros

Uma ferramenta que auxilia os programadores a liberar os recursos alocados é a checagem de balanço na heap. Algumas macros específicas como _UHEAP_MARK e UHEAP_MARKEND podem utilizadas em qualquer parte do seu programa, inclusive criando aninhamentos.
Cada objeto criado com uma função new() ( ou uma de suas variantes) deve ser destruído com um comando delete. A macro U_HEAP_MARKEND verifica se a heap está balanceada. Se a heap não estiver o mesmo número de células alocadas que ela tinha quando _UHEAP_MARK foi chamado, a aplicação entra em pânico. Uma aplicação entra em pânico quando um erro ocorre durante o tempo de execução do aplicativo, fazendo com que interrompa a execução tão logo que este erro seja detectado e mostrando na tela uma informação que pode ser útil para encontrar esse erro(debug).
Além da forma usual de entrar em pânico, o desenvolvedor pode forçar o seu programa a entrar, utilizando a função User:: Panic(). Essa função recebe dois parâmetros- uma string com no máximo 16 caracteres que será mostrada como mensagem na tela e um código de pânico. Na compilação debug para o emulador, a função de pânico da kernel unclui uma macro DEBUGGER() que pode ser usada como auxílio para procurar o erro. Entretantom, na versão final para o hardware real a mensagem é simplesmente "Program Closed" (Programa Terminado), citando o nome do processo, a categoria e o número do erro identificado.
A prática muito utilizada para lidar com pânicos é o uso de macros de assert. Elas permitem verificar quando expressão é executada se a condição não é verdadeira (_ASSERT_DEBUG e _ASSERT_ALWAYS).



6. Conclusão


Nessa primeira parte do artigo, foram explicados algumas estruturas e convenções no desenvolvimento de aplicativos para plataforma Symbian usando a linguagem Symbian C++. Na próxima parte desse artigo, irei explicar outros componentes e ir mais a fundo na estrutura dos arquivos que definem uma aplicação Symbian.





7. Referências

C++ Developers Library 1.1 (http://www.forum.nokia.com/document/Cpp_Developers_Library)



Achei um artigo muito interessante na internet falando à respeito de técnicas para solucionar a questão de fragmentação de dispositivos no desenvolvimento de aplicativos mobile.
Aqui lanço uma introdução do que se trata esse problema:

"Fragmentação de dispositivos é um problema que ocorre quando tem-se que desenvolver vários versões de um aplicativo para executar em diversos dispositivos. Isso exige um grande esforço em todos os aspectos do ciclo de desenvolvimento. Este artigo analisa os vários aspectos da fragmentação de dispositivos, como as causas, e um guia para identificar e solucionar esses problemas quando ocorrem. Esse artigo é visado para desenvolvedores e acadêmicos que querem etender aprofundamente o problema de fragmentação de dispositivos."

(...)

O artigo está em inglês e encontra-se nesse link.

Apenas deixando notificado a todos visitantes desse blog, que o Google Android Developer's Challenge abriu as inscrições para o desafio no seu site. Prêmios até $10.000.000! Recomendo darem uma olhada a mais sobre esse desafio. (Apenas esclarecendo Android é plataforma de desenvolvimento para dispositivos móveis lançada pelo time do Google!)
Uma notícia bem agradável aos desenvolvedores mobile da plataforma JavaME: Uma nova versão da API do MECHART. foi lançada para os desenvolvedores utilizarem em seus aplicativos! Para aqueles que não sabem do que se trata a MECHART, ela permite a construção de gráficos de maneira rápida e simples, sem a necessidade de programar diretamente na classe Canvas. Logo a criação de interfaces para construção de gráficos fica agora mais fácil e preenche uma lacuna nessa área na plataforma JavaME.

De acordo, com Ricardo (Desenvolvedor da API), a nova versão do MECHART vem com as principais mudanças como:

* Possibilidade de criação do gráfico com códigos RGB;
* Gráfico de múltiplas linhas (Figura 3);
* Possibilidade de criação de gráfico com Canvas (Figura 1);
* Possibilidade de criação de um objeto Image de um gráfico (Figura 1);
* Gráfico combinado: colunas + linhas (Figura 1 e 2).

Figura 1 Figura 2
Figura 3

Mais informações, dêem uma olhada no blog Mobilidade é tudo do próprio Ricardo!

Desenvolvimento para Plataforma Android a partir de um desenvolvedor

Achei um post bem interessante falando da experiência de uso do SDK para desenvolvimento da plataforma Android feita pelo Google. Não tive ainda tempo para fazer alguns testes, embora eu tenha instalado o sdk e pluggin, mas em breve informarei mais detalhes sobre ela. Enquanto isso, coloco aqui o link desse artigo sobre a plataforma Android na perspectiva de um desenvolvedor.

Ipod Touch + Microfone + VOIP = Ipod Touch Phone ??!

Olá a todos,
Um ótimo 2008 e espero mais 1 ano de blog!


Hoje, eu fui informado de que alguns hackers conseguiram transformar o IpodTouch em um celular VOIP! Fiquei bastante intrigado com essa notícia e fui buscar mais informações, o que consegui obter foi que o Ipod touch não tem microfone embutido, ou seja, era necessário desenvolver um pequeno dispositivo que adicionasse esse módulo de microfone. Por fim, também desenvolveram um aplicativo baseado no protocolo SIP (que é open-source como por exemplo o Asterik), e daí pronto surgiu o Ipod Touch VOIP.

dmd_1.jpg

Segue algumas referências interessantes a esse projeto:
Touch-4-VoIP (Módulo Microfone). D
SvSIP (Aplicativo embarcado no Ipod baseado no pjsip. )

Abaixo um vídeo de demonstração (Ainda não confirmei se é do mesmo projeto esse vídeo!)

<>

Redes Colaborativas baseadas em Contexto

O post abaixo referente ao Citix fez-me lembrar de um artigo o qual li no site Websinder falando sobre redes colaborativas sobre contexto.

Para quem não entende do que se trata,aqui vai uma citação do próprio autor do artigo exemplificando em um caso real uma rede colaborativa baseada em contexto:

"Um exemplo que gosto de utilizar em palestras: meu celular sabe que estou entrando no Shopping Ibirapuera (Piso Moema) e detecta que aquela garota, presente em minha lista de paqueras no Orkut, está, coincidentemente, no mesmo shopping. É hora do almoço e você também está na lista de paqueras dela? Ambos recebem um SMS: “Fulano, Fulana está te paquerando e a 100m de você. Não é uma ótima oportunidade para conhecer o novo Big Whooper do Burguer King? Venham juntos e ganhem um ringtone exclusivo”. Isto sem que nenhum dos dois tenha, ao chegar no shopping, pensado em iniciar um relacionamento em uma rede de fast-foods."


Acho que o Citix cairia bem nesse conceito. É uma rede social, colaborativa e contextual pois permite o consumo, compartilhamento e publicações de informações pelos usuários relacionadas ao contexto (seja geográfico, temporal ou mesmo situacional) de quem está acessando ou publicando. Para finalizar bastaria que fosse também Mobile (sendo acessível de qualquer lugar, a qualquer momento com múltiplos dispositivos).





Citix: Sua cidade em apenas alguns cliques!

Lendo em um dos blogs mais famosos do cenário pernambucano de computação: blog.meira.com,
comentando sobre o lançamento de um serviço do C.E.S.A.R e outros parceiros chamado CITIX.NET (City Information exchange network).

O projeto que está em formato web (já funcionando na versão beta apenas para Recife) permite que usuários possam trocar informações sobre a cidade em que reside. É considerado uma rede social de localização e compartilhamento de informações sobre eventos, lugares e serviços públicos. Basta o usuário ser logado no sistema e pronto! Ele pode reportar informações e eventos tudo diretamente no mapa.

Segue uma idéia do Citix aqui:

" Bem vindo. Citix é seu. Cadastre-se. Citix está em modo beta. Guardaremos seu cadastro e, à medida em que tivermos capacidade, mandaremos um e-mail para avisar que você já pode começar a usar Citix para -por exemplo- marcar o local de uma comemoração com os amigos. E descobrir o que anda rolando no lugar nos últimos tempos. E tomar suas providências pra chegar e sair de lá de bem com a vida."



Dei uma olhada no serviço e posso dizer que ele é bem interessante, principalmente o seu objetivo que é permitir que usuários facilmente insiram informações e conteúdo referente a eventos e situações dentro da sua cidade. Além de usar a API do Google Maps, oferece recursos como comentários e até uma nuvem de tags para buscar eventos de acordo com sua relevância.
Acho que o serviço tem muito ainda que crescer, no sentido de mais usuários usarem, até porque essa ferramenta necessita de alimentação de dados e quanto mais usuários adicionando conteúdo mais o site vai se tornando uma referência para obtenção de informações de onde ele reside.
Ah, uma idéia interessante seria portar esse sistema em celulares, já que usuários poderiam também localizar e adicionar conteúdo a qualquer momento e de forma rápida.
ps: O google maps tem uma API para integrar a celulares!)

Bluetooth Hack

Não acreditei quando vi que era possível Hackear um celular Bluetooth! Com um aplicativo que você baixa na internet é possível hackear celulares com Bluetooth, isso inclui acessar listas telefônicas, ver caixa de mensagens e até desligar o aparelho remotamente! Fico pensando como esse aplicativo pode pirar a cabeça dos donos sem saber o porquê do aparelho abrir aplicativos sozinho... hehehe! Agora vale salientar que esse aplicativo exige na primeira vez que o celular hackeado libere o total acesso do usuário que está hackeando. Isso ele faz de forma sutil perguntando se você deseja liberar o acesso a internet (Não sabe ele que está liberando a porta de ataque via Bluetooth!), portanto não pense que você vai acessar qualquer celular sem o usuário atacado não permita!

Aqui vai o site onde você pode baixar o aplicativo.

Aqui vai um vídeo demonstração mostrando o aplicativo em funcionamento:

Aos interessados em desenvolvimento em widgets para o orkut, o Google lançou um tutorial bem interessante de como desenvolver alguns aplicativos para o orkut através da sua API OpenSocial.
Para saberem mais, cliquem aqui.
Recentemente a Nokia fez um estudo para saber como a comunicação móvel é usada para o entretenimento. Os resultados são bastante interessantes e podem ter até implicações sobre quais tipos de aplicativos e serviços devem ser focados ao serem criados. O relatóro é baseado numa pesquisa em 17 países entre os meses Julho e Setembro de 2007, onde inclusive o Brasil fez parte da pesquisa.

countries.gif

"9000 consumidores que são usuários ativos de tecnologia e que possuem um celular (não restrito a aparelhos Nokia) com idades entre 16 e 35 anos foram entrevistados. As perguntas foram relacionadas a comportamentos particulares dos usuários em questão ao uso de serviços de entretenimento em função de criar, compartilhar e consumir tais serviços disponíveis. A partir desse questionário, pode-se montar um mapa goblal de como o etretenimento irá se comportarn os próximos 5 anos."

mobileuse.gif

O gráfico acima mostra o que os usuários fazem mais com os celulares em questão de etretenimento. Fica claro que o uso de celulares para lerem seus e-mails , buscar informações e tirar fotos ainda são serviços não tão explorados e que precisam ter mais um pouco de atenção dos desenvolvedores criando aplicativos que permitam o compartilhamento e criação de conteúdo pelos usuários com facilidade, rapidez e baixo custo.


Fonte: Mobile Phone development
Lendo meus feeds diários do meu leitor de RSS, descobri que t em um grupo desenvolvendo um interpretador de Perl para os aparelhos Symbian C++. Ou seja, mais uma nova linguagem de programação via script permitindo construir aplicativos com rapidez e facilidade. Isso significa usuários extendendo e adaptando seus aplicativos de acordo com suas necessidades.

Para saber mais sobre o projeto CPerlBase, clique aqui.

Fonte: Mobile Phone Development

Acelerômetros : N95

Mais uma demonstração do poder do N95 e seu sistema de acelerômetros que permite a partir de movimentos do celular controlar aplicativos. Nesse vídeo, foi criado um aplicativo que permite você controlar menus, jogos, visualização de fotos tudo somente movendo e rotacionando o aparelho. Mas no fim do vídeo, quando achei que ia finalizar com mais um aplicativo dentro do celular, me surpreendi ao ver um usuário jogando um jogo na TV usando o N95 como controle!
Sensacional!
Deixo aqui o link do vídeo e o próprio vídeo:

Meu próximo tutorial será desenvolvimento de aplicativos JavaME para Plataformas Symbian Series 60. Aguardem!
top