Sociable

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!)

<>
top