sábado, 3 de abril de 2010

Cardápio Android, Escolha o seu - Parte I

HTC Dream / T-Mobile G1 / Era G1

  • Tela: HVGA 320×480 / 3,2″ / 65k cores
  • Conectividade: Wi-Fi (802.11b/g), Bluetooth 2.0+EDR, ExtUSB, A-GPS
  • Cámara: 3.2 megapixeis com autofocus
  • Processador: Qualcomm MSM7201A 528 MHz ARM11
  • Memória: 256 MB interna / 16 GB externa via microSD
  • Bateria: 1150 mAh íon lítio
  • Dimensões: 117,7×55,7×17,1mm
  • Peso: 158 g
  • Disponibilidade: Outubro 2008
  • LinkHTC Dream (HTC)

HTC Magic / T-Mobile My Touch 3G

  • Tela: HVGA 320×480 / 3,2″ / 65k cores
  • Conectividade: Wi-Fi (802.11b/g), Bluetooth 2.0+EDR, ExtUSB, A-GPS
  • Câmera: 3.2 megapixeis com autofocus
  • Processador: Qualcomm MSM7201A / MSM7200A 528 MHz ARM11
  • Memória: 256 MB interna / 16 GB externa via microSD
  • Bateria: 1340 mAh íon lítio
  • Dimensões: 113×55,7×13,6mm
  • Peso: 116 g
  • Disponibilidade: Abril 2009
  • W LabsHTC Magic [W Labs]
  • Link: HTC Magic (HTC)

Samsung i7500 / Galaxy

  • Tela: HVGA 320×480 / 3,2″ / 65k cores / AMOLED
  • Conectividade: Wi-Fi (802.11b/g), Bluetooth 2.1, A-GPS, USB 2.0
  • Câmera: 5.0 megapixeis com flash
  • Processador: Qualcomm MSM7200A 528 MHz ARM11
  • Memória: 256 MB interna / 16 GB externa via microSD
  • Bateria: 1500 mAh íon lítio
  • Dimensões: 115×56×11,9mm
  • Peso: 114 g
  • Disponibilidade: Junho 2009
  • Link: Samsung i7500 Galaxy (Samsung Mobile)




HTC Hero / T-Mobile G2 Touch

  • Tela: HVGA 320×480 / 3,2″ / 65k cores
  • Conectividade: Wi-Fi (802.11b/g), Bluetooth 2.0+EDR, ExtUSB, A-GPS
  • Câmera: 5.0 megapixeis com autofocus
  • Processador: Qualcomm MSM7201A 528 MHz ARM11
  • Memória: 256 MB interna / 16 GB externa via microSD
  • Bateria: 1350 mAh íon lítio
  • Dimensões: 112×56,2×14,3mm
  • Peso: 135 g
  • Disponibilidade: Julho 2009
  • Link: HTC Hero (HTC)




    HTC Tatoo

    • Tela: 320×480 / 3,2″ / 16M cores / AMOLED
    • Conectividade: Wi-Fi (802.11b/g), Bluetooth 2.0 EDR, A-GPS, USB 2.0
    • Câmera: 3.2 megapixeis
    • Processador: Qualcomm MSM7225 528 MHz ARM11
    • Memória: 32 GB externa via microSD
    • Bateria: 1100 mAh
    • Dimensões: 106×55,2×14 mm
    • Peso: 113 g
    • Disponibilidade: Outubro 2009
    • Link: HTC Tatoo (HTC)
Continue Lendo >>

MotoDev - Evento Android em SAMPA

Meu camarada! se você é um Android-maníaco gostaria de avisá-lo Segunda-feira dia 05 de Maio teremos o evento MOTODEV SUMMIT em São Paulo, mais precisamente no Hotel Transamérica (Pouco menos que 500 metros de onde trabalho e não poderei ir, mas ok, acho que aguento) trata-se de um evento com o intuito de oferecer acesso a tudo de que você precisa para desenvolver em na plataforma Android, como ferramentas, orientações, conhecimento estratégico de marketing de forma que os desenvolvedores criem novas soluções.


Ahhh...só uma coisa, você deve estar se perguntando o motivo de um evento Android com a Motorola certo??? a resposta é muito simples, ultimamente a Motorola vem investindo pesado nesse SO p/ todos seus Smartphones, e em minha opinião foi uma atitude mais do que sensata afinal de contas convenhamos, só quem teve um motorola sabe o quanto o SO deles é MUUUITO RUIM, ou melhor, se fosse ruim seria suportável, ele é impossível!!! portanto PARABÉNS Motorola por essa decisão inteligente em adotar SO Open Source 


Maiores detalhes sobre esse evento você encontra no site oficial:
http://developer.motorola.com/eventstraining/summit/brazil10/


Fui...


Créditos de Imagem: tudocelular
Continue Lendo >>

domingo, 28 de março de 2010

Um pouco de café e J2ME - Parte II

Olá pessoal!!! continuando nossa saga J2ME hoje trataremos das aplicações MIDP que são chamadas de MIDlets.
O MIDP é a definição de uma arquitetura e APIs para prover um ambiente de desenvolvimento aberto para MIDs (mobile information devices). O MIDP foi feito para rodar em cima do CLDC(No post da primeira parte você irá encontrar detalhes). Para tanto, um MID deve possuir as seguintes características mínimas de hardware (além daquelas que são requeridas pelo CLDC):
-         Display:
-      Tamanho da tela: 96x54;
-       Profundidade: 1 bit;
-       Formato do pixel (proporção de aspecto): 1:1;
-         Input:
-       “One handed keyboard” ou
-       “Two handed keyboard” ou
-       Touch Screen;
-         Memória:
-       128Kbytes para os componentes MIDP;
-       8Kbytes para dados das aplicações;
-       32Kbytes para o JAVA runtime;
-         Rede:
-       Duplex, sem fio, possivelmente intermitente e com largura de banda limitada.

Os MIDs possuem uma grande variedade de softwares de sistema. Por essa razão, o MIDP estabeleceu alguns requisitos mínimos de sistema:
-         Um kernel para controlar o hardware, que possua uma entidade escalonável para rodar a Máquina Virtual Java;
-         Um mecanismo para ler e escrever na memória para suportar as APIs;
-         Acesso de leitura e escrita à rede sem fio;
-         Um mecanismo que provenha um tempo-base utilizado no timestamping nas escritas na “persistent storage”;
-         Capacidade de escrever num display bit-mapped;
-         Um mecanismo para capturar entrada de um input device;

Como os MIDs possuem uma grande quantidade de potencialidades, o MIDPEG (grupo que elaborou o MIDP) limitou o conjunto de APIs necessárias para apenas aquelas necessárias para alcançar uma grande portabilidade. São as seguintes:
-         Aplicação;
-         Interface do Usuário;
-         Persistent Storage;
-         Rede;
-         Temporizadores (timers);





-      Arquitetura

A figura abaixo mostra como o MIDP se encaixa em um aparelho MID.


No nível mais abaixo está o hardware, e logo acima dele o seu sistema. Após, vem o CLDC, que é onde está a Máquina Virtual K (KVM). A KVM irá permitir que APIs Java de alto nível sejam construídas.
As APIs MIDP rodam em cima do CLDC, como foi explicado anteriormente e pode-se visualizar na figura. As classes OEM são classes não definidas pelo MIDP e podem ser utilizadas para funcionalidades específicas para determinado aparelho, o que significa que elas podem ou não ser portáveis para outros MIDs.
Quanto aos aplicativos, um MIDlet é aquele que usa APIs definidas pelo MIDP e CLDC, e são portáveis entre vários aparelhos. Uma aplicação OEM são aquelas que não fazem parte da especificação. Já as nativas são as que estão implementadas diretamente no sistema e não são escritas em Java.




-      Temporizadores

Aplicações que necessitem agendar tarefas para um tempo futuro pode utilizar as classes Timer e TimerTask, que incluem funções para uma execução ou várias execuções em determinados intervalos. Elas estão em java.util.Timer e java.util.TimerTask.




-      Rede

O MIDP herda a conectividade do CLDC e suporta um subconjunto do HTTP, que pode ser implementado com protocolos IP (TCP/IP) e não-IP (WAP e i-mode).
Como há uma grande variedade de redes sem fio, fica por responsabilidade do aparelho e da própria rede sem fio de providenciar o serviço de aplicação. Pode ser necessário um gateway para ligar a rede sem fio à internet. A aplicação cliente não deve precisar saber se há alguma rede não-IP sendo usada ou qualquer outra característica de outras redes. No entanto, essa possibilidade existe, o que faria o cliente e o servidor tirar vantagem deste conhecimento otimizando suas transmissões.
A interface HttpConnection possui funcionalidades que permitem a realização de funções específicas do HTTP. Qualquer aparelho que implemente MIDP deve suportar o HTTP 1.1, requisições HEAD, GET, POST e forms.




-      Persistent Storage

O MIDP disponibiliza um mecanismo para que as MIDlets possam guardar dados e lê-los mais adiante. É a chamada Record Management System (RMS).
-         Record Stores:
É uma coleção de registros que permanece o mesmo durante múltiplas chamadas do MIDlet. A plataforma é responsável por manter a integridade desses registros, mesmo após reboots ou trocas de baterias.
-         Records:
São vetores de bytes. Utilizados para armazenagem de diferentes tipos de dados. Eles são unicamente identificados pelo seu recordId, um valor inteiro.




-      Aplicações

O MIDP define um modelo de aplicação que permite que os recursos limitados dos MIDs sejam compartilhados por várias aplicações, as MIDlets. Este compartilhamento é viável mesmo com os limitados recursos e framework de segurança do MID pois eles são obrigados a compartilhar classes e estão sujeitos a um conjunto de políticas e controles que permitem isso.
Os elementos de uma MIDlet suite, dos quais se espera que implementem as funções necessárias pelos usuários para instalar, selecionar, rodar e remover midlets, são (seu conjunto forma o software de gerenciamento de aplicação):
-                     Ambiente de Execução: é compartilhado por todas as MIDlets que estão na mesma MIDlet suite, e qualquer MIDlet pode interagir com outra que esteja no mesmo pacote.
-                     Empacotamento do MIDlet suite: uma ou mais MIDlets podem ser empacotadas num único arquivo JAR, que contém as classes compartilhadas e os arquivos de recursos utilizados pelas MIDlets, além de um manifesto descrevendo seu conteúdo. Existem vários atributos pré-definidos que permitem identificação de uma MIDlet, como nome, versão, tamanho de dados, descrição, etc.
-                     Descritor de Aplicação: é utilizado para gerenciar a MIDlet e é usada pela própria MIDlet para atributos de configuração específica. O descritor permite que seja verificado que a MIDlet é adequada ao aparelho antes de se carregar todo o arquivo JAR da MIDlet suite. Ele também permite que parâmetros sejam passados para as MIDlets sem modificar os arquivos JAR.
-                     Ciclo de Vida da Aplicação:  uma MIDlet não deve possuir um método public void static main (). O software de gerenciamento de aplicação deve suprir a classe inicial necessária pelo CLDC para iniciar a MIDlet. Quando uma MIDlet é instalada, ela é mantida no aparelho e fica pronta para uso. Quando é rodada, uma instância é criada através de seu construtor público sem argumentos, e seus métodos são chamados para mudar passar pelos estados da MIDlet. Quando ela é terminada, é destruída, e os recursos utilizados por ela podem ser recuperados, incluindo os objetos criados e suas classes.


O software de gerenciamento de aplicação disponibilida um ambiente no qual a MIDlet é instalada, iniciada, parada e desinstalada. Também é responsável por manusear os erros que podem ocorrer durante alguma destas etapas.
O compartilhamento de dados e outras informações entre MIDlets é contralado pelas APIs individuais e suas implementações. Assim, por exemplo, os métodos da API de um sistema de gerenciamento de registros devem ser especificados para manusear com dados que podem ser compartilhados com outras MIDlets.


Em breve a Parte III


Fui...







Créditos de Imagem: wjrsp

Bibliografia I - Programação JAVA para WIRELESS
Bibliografia II - Beginning J2ME: from novice to professional

Continue Lendo >>

domingo, 21 de março de 2010

Como foi o BlackBerry Developer Day

Olá pessoal!!! Antes de mais nada gostaria de deixar BEM CLARO que esse post não é de minha autoria e sim uma INTEGRA autorizada do blog MOBILIDADE É TUDO pois o moderador (Ricardo da Silva Ogliari) compareceu ao evento e pode conferir e realizar anotações de todas as novidades citadas no evento OK??



Boa tarde..

No dia 11 de Março aconteceu o BlackBerryDeveloper Day em São Paulo. Infelizmente não consegui fazer esta resenha antes. Mas, agora vai.

Assisti todas as palestras, que foram:
- As Experiências de um Parceiro Local - Aplicativo bem-sucedido no BlackBerry (história de êxito)
- Introdução à Plataforma de Desenvolvimento BlackBerry
- Fique por dentro: Entenda como funciona o Desenvolvimento Web BlackBerry e o Desenvolvimento dos BlackBerry Widgets
- Por que Java? Compreenda as vantagens e os recursos da Plataforma BlackBerry de Desenvolvimnto Java
- Descrição geral do BlackBerry Alliance Program
- Aproveitamento dos Serviços da Plataforma BlackBerry Platform - Publicidade, pagamento, push, localização e a App World
- A experiência BlackBerry - A criação de aplicativos atraentes e integrados
- Encerramento das atividades e sessão de perguntas e respostas

Não consegui marcar exatamente oque foi dito em cada palestra, assim, vou descrevendo oque pude perceber no evento e oque ouvi de importante:

A primeira palestra foi “As Experiências de um Parceiro Local - Aplicativo bem-sucedido no BlackBerry (história de êxito)”. Este parceiro local é a Navita, onde trabalho. A palestra abordou principal o Navita Translator, que está tendo uma repercurssão mundial muito boa, inclusive, sendo eleito uma super app.

A BlackBerry tem 75 milhões de aparelhos ao redor do mundo.
No último trimestre fiscal foram 10 milhões de aparelhos, mostrando um belo crescimento.
40% dos executivos da América Latina utilizam dispositivos BlackBerry.

A RIM só tem um sistema operacional, o BlackBerry SO, não pensa em utilizar outro e nem abrir o BB OS. Como a Nokia fez com o Symbian.

Sabiam que existe uma certificação para programadores Java BlackBerry e Java Web?

Na versão 5.0 do sistema operacional, vai ter suporte a Flash Lite e SQL Lite. Em contrapartida, notei um certo desânimo ao falar sobre Java FX. Ou seja, sem previsão de suporte a Java FX pela RIM.

Falaram também um pouco sobre os widgets. Segundo a RIM, os widgets devem fazer tudo que um aplicativo pode fazer, ou seja, os widgets da RIM serão poderosos.

Mais especificamente sobre programação em Java para BlackBerry:
- Na versão 5.0 do OS teremos suporte a Biometric API e a JSR 234.
- Além de novos componentes, teremos também um construtor de UI no estilo drag and drop.O nome da ferramenta é GUI Builder.

Para quem se quexa (com razão) de que os simuladores da RIM não são hot deploy, isso deve mudar nas próximas semanas com novos simuladores.

A RIM criou também melhorias nos métodos de localização. Fazendo com que os métodos de posicinamento que utilizam antenas tenham exatidão parecida com a do GPS.

Outro ponto que achei interessante, é o interesse da RIM em uma API e/ou framework que alavanque o mobile advertising e o mobile payment.

————————–

A impressão que fiquei foi de uma bela plataforma que a RIM desenvolveu e está desenvolvendo. Pena que o valor para deixar um aplicativo na loja virtual da RIM custe 200 dólares por 10 aplicativos. Bem salgado né..

E vocês, que análise fazem destas informação?

Att.
Ping



Créditos de Imagem: thebestdigital
Créditos pelo Texto: Mobilidadetudo
Continue Lendo >>

sábado, 20 de março de 2010

Um pouco de café e J2ME - Parte I

J2ME - Java Plataform Micro Edition - Conhecido comumente por J2ME ou JME (Como quiser!) - É uma coleção de APIs Java definidas através da JCP (Java Community Proccess) voltada p/ aplicativos que rodam em pequenos dispositivos e que possuem como características principais pouco recurso de memória,processamento e video (Celulares, Agendas Eletrônicas, PDAs, ou seja, todo tipo de dispositivo eletrônico que permita um sistema embarcado).


Aos poucos irei fazendo uma mescla de parte técnica com teórica p/ um melhor entendimento e não ficar tão chato, ou melhor, menos chato.............mas primeiramente pergunte-se, qual a idéia por trás do J2ME ??? Independente do tipo de dispositivo(Hardware) que possuímos, os produtos(softwares) devem interagir com diversos recursos que esses dispositivos dispõe de forma unica e simplificada ok ?? pois bem, sendo assim esse pensamento nos leva a idéia de máquina virtual, pois cada dispositivo executa internamente uma máquina virtual Java desenvolvida por seu fabricante e os aplicativos desenvolvidos por nós que são os aplicativos terceiros interagem apenas com a máquina virtual e não diretamente com o dispositivo, mas antes que você pergunte já vou dizer, a intenção disso é que os programadores Java não precisem conhecer nenhuma API especifica de cada dispositivo. Quer entender o por que ???


Situação:  Imagine você ou uma empresa desenvolvendo alguma aplicação e quando houver a necessidade de fazer manutenção ter que alterar o código fonte p/ cada fabricante diferente e podemos deixar a situação ainda pior, imagine que cada fabricante solte um novo modelo de aparelho no mercado e você tenha que adaptar seu código fonte p/ cada um deles ?? percebeu o problema ?? Cada dia que passa o hardware evolui mais e mais e por mais que se tente manter a padronização sempre acaba exigindo modificação na programação em baixo nível, por isso é extremamente eficiente que haja uma abstração de máquina virtual  p/ os dispositivos.


Um pouco da plataforma...


O J2ME é dividido em duas categorias de dispositivos, são elas: 


- Dispositivos consumidores de alto padrão: Essa categoria se encaixa no conceito de CDC (Connected Device Configuration), esse conceito inclui equipamentos do tipo TV set-top boxes, sistemas de entretenimento e navegação automobilística, entre outros...não entendesse ainda né?? claro! esse tipo de definição não deixa nada claro, pense em algum dispositivo eletrônico com uma boa capacidade de processamento, memória, maior banda de rede(Dispositivos com funcionalidades bem próximas as encontradas nos ambientes de execução JAVA p/ PC) em alguns casos é citado como mínimo p/ ser considerado um CDC as seguintes características, CPUs de 32-bits e um mínimo de 2MB de memória disponível para armazenamento da máquina virtual e bibliotecas de classes.


Um pouco mais de CDC em números...


Um dispositivo desse tipo tem um mínimo de memória ROM na casa de 512 KB e 256 KB de memória RAM e algum tipo de conexão de rede, isso tudo significa que CDC DEVE necessariamente suportar uma JVM completa como definida na especificação da plataforma JAVA 2, as configurações da J2ME são descritos de forma bem genérica baseado na capacidade de memória sendo especificadas a quantidade mínima de ROM RAM 


- Dispositivos consumidores de baixo padrão: Essa categoria se encaixa no conceito de CLDC (Connected Limited Device Configuration) que inclui celulares, agendas eletrônicas, terminais de ponto de venda, entre outros dispositivos que fazendo uma analogia, são dispositivos mais limitados em termos de processamento, memória etc... mínimo p/ ser considerado CLDC 6-bits ou 32-bits e um mínimo de 128KB à 512KB de memória disponível para a implementação da platafoma Java e aplicações compatíveis.


Um pouco mais de CLDC em números...


Quanto ao CLDC digamos que é o que mais nos interessa atualmente pois engloba os Smartphones e outros tipos de PDAs, são especificados dispositivos desse tipos aqueles que possuem por volta de 128 KB e 512KB de memória disponível p/ a plataforma JAVA e aplicações compativeis. A JVM  p/ esse tipo de dispositivo é bem reduzida, conhecida como KVM, a letra K é devido a unidade de Kilobyte e não Megabyte como na JVM p/ PC e CDC.


Pois então como funciona a KVM já que é tão limitada ??


Como é uma máquina virtual reduzida a KVM não consegue fazer tudo que uma JVM faz no J2SE, ela inclui apenas um subconjunto de bytecode padronizados, ou em poucas palavras, a verificação das classes é dividida entre o dispositivo CLDC e algum mecanismo externo.
                                                           
Os dois conceitos nos dias atuais...


Nos dias atuais o conceito que sem dúvidas mais está presente no nosso dia-dia são os CLDCs, fato esse que pode ser confirmado principalmente pelos telefones celulares  presentes nas nossas vidas, não temos somente um aparelho capaz de fazer ligações, atualmente eles INCLUSIVE fazem ligações, ou seja, temos tantas funções agregadas que nos permitem chama-los de Smartphone, além disso com a evolução das redes(3G, logo mais 4G e outras como LTE) e dos microchips a tendência é que os aparelhos deixem cada vez mais de ser limitados e acabem passando de CLDC p/ CDC.


Bom o post de hoje foi uma introdução aos conceitos básicos do J2ME(ainda tem mais, antes de entrarmos no código fonte em si), os posts serão feitos por partes e não muito extensos de forma com que o conteúdo possa ser absorvido mais facilmente, senão fica muito cansativo p/ o leitor um post muito extenso, estou aberto a comentários e sugestões


Abaixo algumas das bibliografias que pretendo seguir, bem legal e muito interessante em termos de teoria e exemplos iniciais e lembre-se de COLABORAÇÃO, dêem sua opinião,sugiram, critiquem, enfim...


ahhh!!! e quanto ao café, o meu já acabou enquanto escrevia o post! hehe :-)


Fui...


Créditos de Imagem: wjrsp


Bibliografia I - Programação JAVA para WIRELESS
Bibliografia II - Beginning J2ME: from novice to professional





Continue Lendo >>

domingo, 14 de março de 2010

Como é?? Será que teremos um novo Google??

Isso mesmo meus amigos, irei lhes contar algo que achei durante minha peregrinação pela web, talvez alguns já saibam, talvez fiquem tão impressionados como eu ou simplesmente soltem aquele "Hum, interessante!", mas queria dizer que fiquei muito impressionado quando li que a RED BULL irá lançar seu próprio Smartphone, isso mesmo!!! Red Bull aquele energético com gosto de guaraná decidiu se aventurar no mundo High Tech em parceria com a Huawei p/ bater de frente com IphoneNexus OneRIM etc etc...e por que fiquei tão impressionado e estou comparando com o Google?? bom primeiramente se tu é ligado no mundo dos esportes principalmente os radicais sabe que não existe nenhum evento ou atleta que a Red Bull não patrocine e outros como Futebol, Red Bull Air Race e caso se aventure em acordar cedo aos domingos p/ assistir as corridas de Fórmula 1 sabe que a mesma é dona de 2 equipes (SRT - Toro Rosso e RBR - Red Bull Racing) e não só patrocina, como compra e cria divisões especializadas e inicia assim como o Google em MUITAS outras áreas um POUCO fora de sua atuação INICIAL (será que vão brigar para ver quem é a Skynet ???)

Vejo essa empresa com um marketing muito agressivo e no momento já tem sua marca mais que consolidado no mundo dos esportes e parte p/ outros nichos, diria que seria até sensata a idéia de algo voltado para o mercado de tecnologia afinal vai abocanhar um publico jovem e que mais consome suas bebidas, mas chega de blá blá blá e vamos ao Gadget que é o que interessa.

Especificações Tecnicas:
Processador - Qualcomm 528 Mhz
Tela - Touchscreen de 3,5 polegadas com resolução de 320×480 pixels
Memória - 256 Mbytes de ROM e 128 Mbytes de RAM e slot de expansão MicroSD
Câmera - 3.2 megapixels 
GPS Integrado
Pacótinho Básico com Bluetooth e Wi-Fi
Sistema Operacional - Android

Ainda não há muito mais detalhes como preço e data de lançamento, mas é mais uma opção mobile no mercado e TAKE NOTES --> O Smart virá com ANDROID totalmente personalizado com Widgets da RED BULL

fui...


Fonte: pcdebolso
Créditos de Imagem: xatakamovil

Continue Lendo >>