Android em Ação - 3°. Edição

ANDROID EM AÇÃO

Cadastre-se em www.elsevier.com.br para conhecer nosso catálogo completo, ter acesso a serviços exclusivos no site e receber informações sobre nossos lançamentos e promoções.

Tradução Eduardo Kraszczuk e Edson Furmankiewicz

Do original: Android in Action, Third Edition de W. Frank Ableson, Robi Sen e Chris King Tradução autorizada do idioma inglês da edição publicada pela editora Manning Publications Co. © 2012, Elsevier Editora Ltda. Todos os direitos reservados e protegidos pela Lei no 9.610, de 19/02/1998. Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros. Revisão: Edson Rosa Editoração Eletrônica: Docware Traduções Técnicas Elsevier Editora Ltda. Conhecimento sem Fronteiras Rua Sete de Setembro, 111 - 16o andar 20050-006 - Centro - Rio de Janeiro - RJ - Brasil Rua Quintana, 753 - 8o andar 04569-011 - Brooklin - São Paulo - SP - Brasil Serviço de Atendimento ao Cliente 0800-0265340 [email protected] ISBN 978-85-352-4841-8 (recurso eletrônico) ISBN da edição original: 978-1-617290-50-3

Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendimento ao Cliente, para que possamos esclarecer ou encaminhar a questão. Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens, originados do uso desta publicação. CIP-Brasil. Catalogação-na-fonte Sindicato Nacional dos Editores de Livros, RJ A135a Ableson, W. Frank     Android em ação [recuro eletrônico] / W. Frank Ableson, Charlie Collins, Robi Sen ; tradução Eduardo Kraszczuk. - Rio de Janeiro : Elsevier, 2012.     recurso digital     Tradução de: Android in action, 2nd ed.     Formato: PDF

    Requisitos do sistema: Adobe Acrobat Reader     Modo de acesso: World Wide Web     “Edição revisada de Unlocking Android”     Apêndice     Inclui índice     ISBN 978-85-352-4841-8 (recurso eletrônico)      1. Andróides. 2. Android (Programa de computador). 3. Computação móvel. 4. Software de aplicação - Desenvolvimento. 5. Livros eletrônicos. I. Collins, Charles (Charlie E.). II. Sen, Robi. III. Título. 11-5995.                             CDD: 004.16                                            CDU: 004

Agradecimentos Escrever a terceira edição de Android em ação se parece um pouco com aquele antigo ditado sobre casamentos: “Algo velho, algo novo...” Os prazos para a terceira edição não foram nada fáceis, uma vez que pela última contagem ainda há somente 24 horas em um dia. E para algo novo – parece que o ritmo de inovação do Android continua a corresponder à sua taxa de adoção por usuários móveis ao redor do mundo. Assim como as duas edições anteriores, Android em ação, terceira edição representa uma colaboração entre diversos contribuintes. Eu tive o privilégio de trabalhar novamente com Robi Sen e Chris King, que trabalharam comigo na primeira edição. C. Enrique Ortiz uniu-se a nós para contribuir com conteúdo sobre os tablets. Mais uma vez, a talentosa equipe da Manning se empenhou para produzir esta edição. Em particular, gostaríamos de reconhecer e agradecer a todos na Manning. Primeiro, obrigado a Troy Mott, nosso editor de aquisição e desenvolvimento, que se envolveu em todos os aspectos das três edições até agora deste projeto – parabéns, Troy, por seus três gols! Bob Herbstman fez todas as pequenas e grandes coisas para a realização do projeto; Mary Piergies orientou a equipe habilidosamente pelo lancinante processo de produção; e Marjan Bace, nossa editora, que mostrou atenção aos detalhes ao mesmo tempo desafiadora, benéfica e apreciada. Uma vez que terminamos de escrever, a próxima parte do trabalho começou. Nossos agradecimentos especiais vão para Benjamin Berg, que fez a aprovação editorial de pré-produção; Tiffany Taylor, que aprovou a segunda revisão de texto e nos ajudou a organizar as partes finais do projeto; e finalmente Dottie Marsico, que compôs o layout real das páginas. Às vezes é difícil visualizar o produto final quando olhamos edições e mais edições em MS Word, mas a mágica de Dottie criou o produto que você tem em mãos. Em seguida, gostaríamos de agradecer a Candice Gillhoolley por seus esforços para divulgar o livro. Agradecemos a cada um de vocês por sua contribuição especial a este projeto. E agradecimentos especiais aos revisores que leram nosso manuscrito revisado em diferentes momentos do seu desenvolvimento: Steve Prior, Matthew Johnson, Julian Harty, David Strong, Loïc Simon, Al Scherer, Gabor Paller e Pieter Kuijpers; e a Jérôme Bâton por sua cuidadosa revisão técnica do manuscrito final durante a produção.

vi

ANDROID EM AÇÃO

ELSEVIER

Por último, gostaríamos de agradecer ao atencioso encorajamento dos assinantes da MEAP, que forneceram feedback ao longo do caminho. O livro está melhor graças a suas contribuições.

Frank Ableson Agradeço a meus coautores: Robi Sen, um verdadeiro profissional que se envolveu neste projeto desde o início; Chris King, que provou sua solidez em termos de capacidade técnica e confiabilidade; e o recém-chegado C. Enrique Ortiz (CEO), que injetou energia e entusiasmo na Terceira Edição. É claro que, durante cada etapa deste projeto, Troy Mott apontou o caminho: gerenciando o processo, às vezes nos persuadindo, e sempre entregue ao trabalho. Bob Herbstman contribuiu valiosamente para o produto final e deve estar cansado de limpar meus escritos e elementos gráficos amadores após todos esses anos. Agradecimentos especiais a Bob por recriar muitas ilustrações. Agradeço também à equipe de produção da Manning Publications, que mais uma vez realizou um excelente trabalho. Agradeço também a Candace Gillhoolley pelo apoio constante com livros e promoções para o suporte à palestras e conferências – sempre me socorrendo em pedidos de última hora. Por fim, e mais importante, agradeço a Nikki e companhia na família Ableson pelo apoio incondicional. Graças a Deus, outra versão está completa!

Chris King Sou profundamente grato a Troy Mott, Frank, Robi e Enrique, com os quais tive grande prazer de colaborar enquanto nos dirigíamos para a encarnação mais recente deste livro. Eu também aprecio todo o trabalho feito pelos revisores e editores da Manning, assim como dos dedicados leitores das edições anteriores que contribuíram com sugestões nos fóruns Author Online. Agradecimentos especiais a Eric Tamo e Zac White por seu apoio e ânimo incansáveis. Por fim, meu amor por minha família: Charles, Karen, Patrick, Kathryn e Andrew.

Robi Sen Agradeço a Troy Mott e à equipe — e a todos na Manning Publications — por seu trabalho duro em transformar este livro em algo que vale a pena ser lido. Eu gostaria de agradecer aos meus coautores, Frank e Chris, com quem foi ótimo trabalhar e que foram muito compreensivos quando era eu quem estava atrasado. Gostaria também de agradecer a C. Enrique Ortiz por suas contribuições. Finalmente, eu gostaria de dedicar meus esforços neste livro a meu irmão Neel, que faleceu enquanto estávamos terminando o livro.

C. Enrirque Ortiz A meus pais, família, amigos e colegas, que influenciaram meu trabalho e o tornaram empolgante.

Prefácio A ideia de escrever um livro sobre o desenvolvimento do Android pode ser um pouco fútil às vezes, considerando o ritmo em que o Android continua a se expandir, se transformar e mudar. O que começou como o projeto de um livro poucos anos atrás tornou-se agora uma série de atualizações do trabalho original, com praticamente o dobro do número de páginas do projeto original – e isso após decisões difíceis sobre o que deixar de fora do livro para assegurar que ele fosse publicado. A atualização de Android em ação representa nosso esforço mais recente para proporcionar a cobertura de assuntos importantes do desenvolvimento Android, a saber, a expansão para o espaço do tablet com o Android 3.x, bem como os avanços dos elementos gráficos e de mídia móveis, como o RenderScript. Embora existam muitas ofertas de tablets de marcas conhecidas ou desconhecidas surgindo a todo momento, a equipe de desenvolvimento Android avançou ao adicionar capacidades específicas de tablet ao SDK sob a bandeira do 3.0. Com esse objetivo, o 3.0 foi rapidamente atualizado, desse modo, geralmente nos referimos aos recursos específicos de tablet como 3.x; e logo em breve tenho certeza que o Android 4.x será lançado com um superconjunto de recursos. Assim como muitas coisas na vida, a única constante é a mudança, mas nós já estamos de certo modo acostumados com o ambiente acelerado do desenvolvimento Android. Nesse sentido, asseguramos que todos os aplicativos deste livro funcionam com o Android 3.x. Os capítulos mais recentes que cobrem o assunto específico dos tablets (20–22) exigem o SDK 3.x, enquanto os outros capítulos são compatíveis com as versões do SDK 2.x. Se planeja escrever aplicativos para Android, você precisa simplesmente se preparar para criar várias versões dele. Essa é, ao mesmo tempo, uma virtude e um desafio do ecossistema do Android. A terceira edição foi escrita por Frank Ableson, Robi Sen, Chris King e o recém-chegado C. Enrique Ortiz, conhecido como CEO. Para citar uma frase do setor de viagens aéreas, “Nós sabemos que você tem uma escolha quando se trata de livros de desenvolvimento Android, então, obrigado por aprender e colaborar conosco”. FRANK ABLESON

Página deixada intencionalmente em branco

Sobre este livro Android em ação, terceira edição é uma revisão e atualização da, você adivinhou, Segunda edição, publicada em janeiro de 2011. Este terceira edição acrescenta novo conteúdo relacionado ao avanço do Android no espaço dos tablets, bem como às melhorias em vários subsistemas dentro da plataforma Android. Assim como os anteriores, este livro cobre temas básicos importantes, como “O que é Android” e a instalação e uso do ambiente de desenvolvimento. Nós então avançamos para exemplos práticos de tópicos de programação básica que qualquer desenvolvedor ficará feliz de ter à mão na sua prateleira de referências. O restante dos capítulos apresentam exemplos de aplicativos bastante detalhados cobrindo tópicos avançados, incluindo um aplicativo completo de serviço de campo, localização e material sobre aplicativos web para Android, sensores Bluetooth, AppWidgets e adaptadores de integração. Nós incluímos ainda dois capítulos sobre a escrita de aplicativos em C — um para o lado nativo do Android e um usando o método geralmente mais aceito de empregar o Android Native Development Kit. O conteúdo mais recente cobrindo os tablets é encontrado nos capítulos 20 a 22. Os capítulos 20–22, especificamente, exigem o Android SDK 3.0 e superior, enquanto o restante do livro é compatível com as versões 2.x do Android. Embora você possa ler este livro do começo ao fim, você também pode considerá-lo como vários livros em um. Se você é novo no Android, concentre-se primeiro no capítulo 1, no apêndice A e então no capítulo 2. Com estes fundamentos, você pode continuar nos capítulos 3–12. Os capítulos a partir do 13 são de natureza mais profunda e podem ser lidos independentemente dos demais. Os capítulos 20–22 concentram-se em tópicos importantes relacionados ao Android 3.0 e aos tablets.

Quem deve ler este livro? Escrevemos este livro tanto para programadores profissionais quanto para hobbystas. Muitos dos conceitos podem ser absorvidos sem conhecimento específico da linguagem Java, embora você possa obter melhor resultado se tiver habilidade em programação Java – a programação de aplicativos Android exige isso. Se tiver conhecimentos em programação C, C++ ou C#, você será capaz de seguir os exemplos.

x

ANDROID EM AÇÃO

ELSEVIER

Experiência prévia em Eclipse é útil, mas não necessária. Diversos recursos sobre Java e Eclipse estão disponíveis para expandir o conteúdo deste livro.

Roteiro Este livro está dividido em quatro partes. A Parte 1 contém material introdutório sobre a plataforma e ambiente de desenvolvimento. A Parte 2 examina de perto as habilidades fundamentais necessárias na construção de aplicativos Android. A Parte 3 apresenta um aplicativo de maior alcance e um aplicativo Android em C Nativo. A parte 4 explora recursos adicionados à plataforma Android, fornecendo exemplos de uso da competente plataforma Android para a criação de inovadores aplicativos móveis.

Parte 1: Os fundamentos A Parte 1 apresenta a plataforma Android, incluindo sua arquitetura e configuração do ambiente de desenvolvimento. O Capítulo 1 lida com o background e posição da plataforma Android, incluindo comparações com outras plataformas populares como BlackBerry, iPhone e Windows Mobile. Após apresentar a plataforma, o primeiro capítulo apresenta a arquitetura de alto nível dos aplicativos Android e o ambiente do sistema operacional. O Capítulo 2 guia você por um exercício de desenvolvimento passo a passo, ensinando-o a usar o ambiente de desenvolvimento Android, incluindo as ferramentas e conceitos chave para construção de um aplicativo . Se você nunca usou Eclipse ou nunca escreveu um aplicativo Android, este capítulo irá prepará-lo para a próxima parte do livro.

Parte 2: O ambiente de programação A Parte 2 inclui um exame extenso dos tópicos fundamentais de programação em ambiente Android. O Capítulo 3 cobre os componentes fundamentais da interface de usuário (IU) do Android, incluindo View e Layout. Vamos também examinar a Activity em maiores detalhes. Estes são os blocos básicos das telas e aplicativos da plataforma Android. Ao longo do caminho, vamos também tocar em outros conceitos básicos, como o acesso de recursos externos, a resposta a eventos e o ciclo de vida de um aplicativo Android. O Capítulo 4 expande os conceitos que você aprendeu no Capítulo 3. Nós nos aprofundamos no Intent Android para demonstrar a interação entre telas, atividades e aplicativos inteiros. Também introduzimos e usamos o framework Service, que permite os processos de segundo plano em andamento. O Capítulo 5 incorpora métodos e estratégias para armazenamento e recuperação de dados localmente. O capítulo examina o uso do sistema de arquivos, bancos de dados, o cartão SD e entidades de armazenamento específicas do Android, como as classes SharedPreferences e ContentProvider. Este capítulo começa combinando os conceitos fundamentais com detalhes mais realistas, como o tratamento do estado do aplicativo, o uso de um banco de dados para armazenamento permanente e o trabalho com SQLite.





xi

O Capítulo 6 trata de armazenamento e recuperação de dados na rede. Aqui incluímos uma cartilha sobre redes antes de nos aprofundarmos no uso de conceitos brutos sobre redes, como soquetes no Android. A partir dali, vamos avançar para o uso do HTTP e explorar serviços web (como REST e SOAP). O Capítulo 7 cobre a telefonia na plataforma Android. Vamos tocar em temas básicos, como originar e receber chamadas, além de tópicos mais complexos, como identificar torres de celulares e enviar ou receber mensagens SMS. O Capítulo 8 examina como trabalhar com notificações e alarmes. Nesse capítulo, vamos examinar como notificar os usuários de diversos eventos, como o recebimento de uma mensagem SMS, além como gerenciar e ajustar alarmes. O Capítulo 9 trata do básico da API gráfica do Android e conceitos mais avançados, como trabalhar com a biblioteca OpenGL ES para criar sofisticados elementosgráficos 2D e 3D. Vamos também falar de animação e dos novos sistemas gráficos RenderScript do Android. O Capítulo 10 examina o suporte do Android à multimídia; vamos cobrir tanto a reprodução multimídia quanto o uso da câmera e microfone para gravar seus próprios arquivos multimídia. O Capítulo 11 introduz serviços baseados em localidade, onde examinamos um exemplo em que combinamos muitos dos conceitos das partes anteriores do livro em um aplicativo de mapas. Você vai aprender a usar as APIs de mapas do Android, incluindo diferentes provedores de localização e propriedades disponíveis, como construir e manipular telas relativas a mapas e como trabalhar com conceitos relativos à localização dentro do emulador.

Parte 3: Combinando tudo A Parte 3 contém dois capítulos que somam ao conhecimento que você obteve antes no texto, com foco em tornar um aplicativo maior uma realidade. O Capítulo 12 demonstra um aplicativo de serviço de campo ponto a ponto. O aplicativo inclui comunicação entre servidores, armazenamento persistente, menus de navegação de múltiplas atividades e captura de assinatura. O Capítulo 13 explora o mundo dos aplicativos em linguagem C nativa. O SDK Android é limitado à linguagem Java, embora aplicativos nativos possam ser escritos para Android. Este capítulo vai guiá-lo por exemplos de construção de aplicativos em linguagem C para Android, incluindo o uso de bibliotecas embutidas e comunicações por soquete TCP quando um aplicativo Java se conecta ao seu aplicativo C. Este capítulo é útil para desenvolvedores buscando soluções além dos celulares bloqueados subsidiados pelas operadoras.

Parte 4: O amadurecimento da plataforma A Parte 4 contém nove novos capítulos, cada um dos quais representa um tópico de desenvolvimento mais avançado. O Capítulo 14 demonstra o uso de comunicação Bluetooth e o processamento de dados dos sensores. O aplicativo de exemplo que acompanha este capítulo, o SenseBot, permite ao usuário guiar um robô LEGO Mindstorms com seu telefone Android.

xii

ANDROID EM AÇÃO

ELSEVIER

O Capítulo 15 explora o banco de dados de contatos do Android e demonstra a integração com uma fonte de dados externa. Em particular, este aplicativo traz o Android para a cena das redes sociais, integrando-o ao popular serviço de rede profissional LinkedIn. O Capítulo 16 explora o mundo do desenvolvimento web. O navegador do Android é baseado no mecanismo de código-fonte livre WebKit, e traz ao navegador móvel capacidades de desktop. Este capítulo equipa você a criar aplicativos web atraentes e capazes para o Android. O Capítulo 17 apresenta a tela inicial do seu aplicativo Android mostrando a você como construir um aplicativo que apresenta sua interface como um AppWidget. Além dos AppWidgets, este capítulo demonstra o BroadcastReceiver, Service e Alarms. O Capítulo 18 mostra como localizar um aplicativo existente no mundo real. O aplicativo Field Service do Capítulo 12 é modificado para suportar múltiplos idiomas. A versão do Capítulo 18 do aplicativo Field Service suporta inglês e espanhol. O Capítulos 19 alcança a base do código fonte aberto do Android, usando um algoritmo popular de processamento de imagens para detecção de arestas. O algoritmo Sobel Edge Detection é escrito em C e compilado em uma biblioteca nativa. O aplicativo de exemplo tira uma foto com a câmera do Android e então usa esse algoritmo em C para encontrar as bordas da foto. O Capítulo cobre o Fragments Android, um novo componente do aplicativo que foi introduzido com o Android 3.0. O Fragments propicia controle mais granular do aplicativo do que trabalhar somente com as Activitys isoladas. O Capítulo 21 explora a barra de ações. Também introduzida com o Android 3.0, a barra de ações fornece uma aparência e comportamento consistentes para o título, ícones, ações e opções do menu do aplicativo. O Capítulo 22 apresenta a nova API de arrastar e soltar, também introduzida com o Android 3.0. A API de arrastar e soltar permite operações interativas baseadas no toque: por exemplo, para mover ou copiar dados entre views selecionando visualmente os dados de uma view e arrastando-os para a outra view na tela. Outro exemplo é para disparar ações do dispositivo: por exemplo, compartilhar imagens arrastando uma imagem da view de uma galeria de imagens para uma view compartilhada.

Apêndices Os apêndices contêm informações adicionais que não se encaixaram no fluxo do texto principal. O Apêndice A é um guia passo a passo para instalação do ambiente de desenvolvimento. Este apêndice, em conjunto com o capítulo 2, fornece toda a informação que você precisa para construir uma aplicação Android. O apêndice B demonstra como preparar e submeter um aplicativo para o Android Market — um tópico importante para todos que querem comercializar seu aplicativo .

Convenções de código e downloads Todo código fonte no livro está em fonte de largura fixa como esta, o que a destaca do texto em volta. Em muitas listagens, o código está anotado para apontar





xiii

os conceitos-chave; e marcadores numerados (como este: q) são usados às vezes para fornecer informações adicionais sobre o código. Tentamos formatar o código de modo que ele se encaixasse no espaço de página disponível no livro, adicionando algumas quebras de linha e usando os recuos com cuidado. Algumas vezes, porém, linhas muito longas incluem marcadores de continuação de linha (➥). O código-fonte de todos os exercícios está disponível em www.elsevier.com.br/ ableson. Um arquivo Readme.txt é fornecido na pasta raiz e também na pasta de cada capítulo. Esse arquivo fornece detalhes sobre como instalar e executar o código. Exemplos de código aparecem ao longo de todo o livro. Listagens de código mais curtas aparecem em blocos de texto identificados por uma fonte monoespaçada, enquanto as listagens mais longas além da fonte também são claramente identificadas por cabeçalhos de listagem.

Requisitos de software O desenvolvimento de aplicativos para Android pode ser feito no ambiente Windows XP/Vista/7, ambiente Mac OS X (somente Intel) ou ambiente Linux. O Apêndice A inclui uma descrição detalhada do ajuste do ambiente Eclipse além do plug-in Android Developer Tools para Eclipse.

Uma nota sobre as imagens Muitas das imagens originais da primeira edição, Unlocking Android, foram reutilizadas na segunda e terceira edições do livro. Embora o título tenha mudado para Android em Ação durante a redação da segunda edição, mantivemos o título original do livro nas imagens e aplicativos de exemplo.

O autor online A compra de Android em ação, terceira edição inclui acesso gratuito ao fórum web particular mantido pela Manning Publications, onde você pode fazer comentários sobre o livro, fazer perguntas técnicas e receber ajuda dos autores e outros usuários do fórum. Para acessar e se inscrever no fórum, acesse www.manning.com/AndroidinActionThirdEdition ou www.manning.com/ableson3. Essa página fornece informações sobre como acessar o fórum após se registrar, que tipo de ajuda está disponível e as regras de conduta do fórum. O compromisso da Manning com nossos leitores é fornecer um ponto de encontro onde o diálogo significativo entre leitores e entre leitores e os autores possa acontecer. Não é um compromisso sobre qualquer grau específico de participação por parte dos autores, cuja contribuição ao fórum é voluntária (e não paga). Sugerimos que você faça aos autores algumas perguntas desafiadoras, ou o interesse deles pode diminuir! O fórum Author Online e os arquivos de discussões passadas estarão disponíveis no site web da editora enquanto o livro estiver em catálogo.

Página deixada intencionalmente em branco

Sobre a ilustração da capa A ilustração da capa de Android em ação, terceira edição foi tirada de um livro francês sobre costumes de vestimenta, Encyclopédie des Voyages, de J. G. St. Saveur, publicado em 1796. Viajar por prazer era um fenômeno relativamente novo na época e guias ilustrados como esse eram populares, apresentando ao turista e ao viajante de sofá os habitantes de outras regiões do mundo, além dos costumes regionais e uniformes da França. A diversidade dos desenhos na Encyclopédie des Voyages fala vividamente da singularidade e individualidade dos países e regiões do mundo apenas 200 anos atrás. Este era um tempo onde os códigos de vestimenta de duas regiões separadas por poucas milhas identificavam as pessoas como sendo unicamente de uma ou outra região, e quando membros de uma classe social ou tribo podiam ser facilmente distinguidos pelo que estavam vestindo. Era também um tempo em que as pessoas eram fascinadas por terras estrangeiras e lugares distantes, embora não viajassem para estes lugares exóticos elas mesmas. Os códigos de vestimenta mudaram desde então e a diversidade entre regiões e tribos, tão rica na época, desapareceu. Hoje, é difícil distinguir o habitante de um continente do de outro. Quem sabe, olhando com otimismo, nós trocamos um mundo de diversidade cultural e visual por outro de vida pessoal mais variada. Ou uma vida mais variada e interessante técnica e intelectualmente. Nós na Manning celebramos a criatividade, a iniciativa e a diversão do negócio dos computadores com capas baseadas em costumes nativos e tribais de dois séculos atrás trazidos à vida pelas figuras deste guia de viagem.

Página deixada intencionalmente em branco

Sumário resumido Parte 1

O que é Android? Uma visão geral.....................1 1 n  Apresentando o Android   3 2 n  O ambiente de desenvolvimento do Android   34

Parte 2

Usando o Android SDK........................................63 3 n  Interfaces de usuário   65 4 n  Intents e Services   103 5 n  Armazenando e recuperando dados   132 6 n  Redes e serviços web   162 7 n Telefonia  189 8 n  Notificações e alarmes   208 9 n  Elementos gráficos e animação   228 10 n Multimídia  262 11 n  Trabalhando com a detecção da localização geográfica  285

xviii

Parte 3

ANDROID EM AÇÃO

ELSEVIER

Aplicativos Android..........................................309 12 n  Colocando o Android para trabalhar em um aplicativo de serviço de campo   311 13 n  Compilando aplicativos Android em C   357

Parte 4

O amadurecimento da plataforma.................385 14 n  Bluetooth e sensores   387 15 n Integração  406 16 n  Desenvolvimento web com Android   441 17 n AppWidgets  474 18 n Localização  510 19 n  Android Native Development Kit   525 20 n  Fragmentos de activity   545 21 n  A barra de ações do Android 3.0   560 22 n  Arrastar e soltar   579

Sumário Parte 1

O que é Android? Uma visão geral.....................1

1

Apresentando o Android   3 1.1 A plataforma Android   4 1.2 Entendendo o mercado do Android    5 Operadoras de telefonia móvel  n  Android versus feature phones  n  Android versus smartphones  n  Android versus Android  n  Licenciando o Android

1.3 As camadas do Android   10 Construindo sobre o kernel Linux  n  Executando na Dalvik VM

1.4 O Intent do desenvolvimento Android   13 Criando UIs intuitivas  n  Intents e como eles funcionam

1.5 Os quatro tipos de componentes Android   17 Activity  n Service n BroadcastReceiver n ContentProvider

1.6 1.7 1.8 1.9

Entendendo o arquivo AndroidManifest.xml   25 Mapeando aplicativos para processos   26 Criando um aplicativo Android   27 Android 3.0 para tablets e smartphones   31 Por que desenvolver tablets Android?  n  Quais as novidades da plataforma Android 3.0 Honeycomb?

xx

ANDROID EM AÇÃO

ELSEVIER

1.10 Resumo  32

2

O ambiente de desenvolvimento do Android   34 2.1 Apresentando o Android SDK   35 Pacotes Android essenciais  n  Pacotes opcionais

2.2 Explorando o ambiente de desenvolvimento   37 A perspectiva Java  n  A perspectiva DDMS.  n  Ferramentas de linha de comando

2.3 Construindo um aplicativo Android no Eclipse   46 O Android Project Wizard  n  Código do aplicativo Android  n  Empacotando o aplicativo

2.4 Usando o emulador Android   54 Configurando o ambiente emulado  n  Testando seu aplicativo no emulador

2.5 Depurando seu aplicativo   61 2.6 Resumo  62

Parte 2

Usando o Android SDK........................................63

3

Interfaces de usuário   65 3.1 Criando a Activity   67 Criando uma classe Activity  n  XML versus layouts programáticos  n  Explorando o ciclo de vida da Activity

3.2 Trabalhando com views   76 Explorando views comuns  n  Usando um ListView  n  Múltiplas tarefas com Handler e Message  n  Criando views personalizadas  n Entendendo o layout  n  Gerenciando o foco  n  Entendendo os eventos

3.3 Usando recursos  90 Tipos de recursos suportados  n  Referenciando recursos em Java  n  Definindo views e layouts por meio de recursos XML  n  Externalizando valores  n  Fornecendo animações

3.4 Explorando o arquivo AndroidManifest   99 3.5 Resumo  102

4

Intents e Services   103 4.1 Servindo o RestaurantFinder com Intent   104 Definindo Intents  n  Invocação implícita e explícita  n Adicionando links externos ao RestaurantFinder  n  Encontrando seu caminho com Intents  n  Tirando proveito das activities fornecidas pelo Android



SUMÁRIO

xxi

4.2 Verificando o tempo com um URI personalizado   111 Oferecendo um URI personalizado  n  Inspecionando um URI personalizado

4.3 Verificando o tempo com broadcast receivers   115 Transmitindo um Intent  n  Criando um receptor

4.4 Criando um serviço de metereologia em segundo plano  117 4.5 Comunicando-se com o WeatherAlertService a partir de outros aplicativos  121 Android Interface Definition Language  n  Binder e Parcelable  n  Expondo uma interface remota  n  Vinculando-se a um serviço  n  Iniciar versus vincular  n  Ciclo de vida de um serviço

4.6 Resumo  130

5

Armazenando e recuperando dados   132 5.1 Usando preferências  133 Trabalhando com SharedPreferences  n  Permissões de acesso a preferências

5.2 Usando o sistema de arquivos   139 Criando arquivos  n  Acessando arquivos  n  Arquivos como recursos brutos  n  Recursos de arquivo XML  n  Armazenamento externo em um cartão SD

5.3 Persistindo dados em um banco de dados   147 Construindo e acessando um banco de dados  n  Usando a ferramenta sqlite3

5.4 Trabalhando com as classes ContentProvider   153 Usando um ContentProvider existente  n  Criando um ContentProvider

5.5 Resumo  161

6

Redes e serviços web   162 6.1 Visão geral de comunicação em rede   164 Princípios básicos de redes  n  Clientes e servidores

6.2 Verificando o estado da rede   167 6.3 Comunicação com um soquete de servidor   168

xxii

ANDROID EM AÇÃO

ELSEVIER

6.4 Trabalhando com HTTP   171 HTTP e java.net simples  n  HTTP robusto com HttpClient  n Criando um helper HTTP e HTTPS

6.5 Serviços web  181 POX: juntando tudo com HTTP e XML  n REST n  SOAP ou não SOAP, eis a questão

6.6 Resumo  188

7

Telefonia  189 7.1 Explorando o background da telefonia e seus termos  190 Entendendo o GSM  n  Entendendo o CDMA

7.2 Telefone ou não?   192 7.3 Acessando informações de telefonia   193 Recuperando propriedades de telefonia  n  Obtendo informações de status do telefone

7.4 Interagindo com o telefone   197 Usando Intents para fazer chamadas  n  Usando utilitários relacionados a números de telefone  n  Interceptando chamadas de saída

7.5 Trabalhando com mensagens: SMS   201 Enviando mensagens SMS  n  Recebendo mensagens SMS

7.6 Resumo  206

8

Notificações e alarmes   208 8.1 Apresentando o Toast   209 8.2 Posicionando sua mensagem Toast   211 8.3 Fazendo uma view Toast personalizada   212 8.4 Apresentando notificações  214 A classe Notification  n  Notificando o usuário com o simples pressionar de um botão

8.5 Criando uma view Notification personalizada   218 8.6 Apresentando alarmes  220 Criando um exemplo simples de alarme  n  Usando notificações com alarmes

8.4 Resumo  227

9

Elementos gráficos e animação   228 9.1 Desenhando elementos gráficos no Android   229 Desenhando com XML  n  Explorando formas XML drawable



SUMÁRIO

xxiii

9.2 Criando animações com a API Graphics do Android  234 Animação quadro a quadro do Android  n  Criando uma animação programaticamente

9.3 Apresentando a OpenGL for Embedded Systems   240 Criar um contexto OpenGL  n  Desenhando um retângulo com a OpenGL ES  n  Formas e superfícies tridimensionais com OpenGL ES

9.4 Apresentando o RenderScript do Android   253 Vantagens e desvantagens do RenderScript  n  Construindo um aplicativo RenderScript

9.5 Resumo  261

10

Multimídia  262 10.1 Introdução à multimídia e ao Stagefright   263 Visão geral do Stagefright

10.2 Reproduzindo áudio  265 10.3 Reproduzindo vídeo  266 10.4 Capturando mídia  268 Entendendo a câmera  n  Capturando áudio  n  Gravando vídeo

10.5 Resumo  284

11

Trabalhando com a detecção da localização geográfica  285 11.1 Simulando sua localização dentro do emulador   287 Enviando suas coordenadas com a ferramenta DDMS  n  O GPS Exchange Format  n  A Keyhole Markup Language do Google Earth

11.2 Usando LocationManager e LocationProvider   292 Acessando dados de localização com LocationManager  n Usando um LocationProvider  n  Recebendo atualizações de localização com LocationListener

11.3 Trabalhando com mapas   299 Estendendo MapActivity   n  Usando uma MapView  n  Inserindo dados em um mapa com um Overlay

11.4 Convertendo lugares e endereços com o Geocoder   306 11.5 Resumo  308

xxiv

ANDROID EM AÇÃO

Parte 3

ELSEVIER

Aplicativos Android..........................................309

12

Colocando o Android para trabalhar em um aplicativo de serviço de campo   311 12.1 Projetando um aplicativo Android do mundo real   312 Requisitos básicos do aplicativo  n  Gerenciando os dados  n Arquitetura e integração do aplicativo

12.2 Mapeando o fluxo do aplicativo   316 Mapeando o aplicativo de serviço de campo  n  Lista de arquivosfonte  n  AndroidManifest.xml do aplicativo de serviço de campo

12.3 Código-fonte do aplicativo   321 SplashActivity  n  Preferências usadas pela FieldService Activity  n  Implementando a FieldService Activity   n Configurações n  Gerenciando dados do trabalho

12.4 Código-fonte para o gerenciamento dos trabalhos   335 RefreshJobs  n  Gerenciando os trabalhos: a Activity ManageJobs  n  Lidando com um trabalho com a Activity ShowJob   n  A captura de uma assinatura com a Activity CloseJob

12.5 Código do servidor   353 Interface do usuário expedidor  n  Banco de dados  n  Código de expedição em PHP  n  Código de integração móvel em PHP

12.6 Resumo  356

13

Compilando aplicativos Android em C   357 13.1 Compilando aplicativos Android sem o SDK   358 As ferramentas de compilação e vinculador do C  n  Compilando um aplicativo Hello World  n  Instalando e executando o aplicativo  n Script de compilação de um aplicativo C

13.2 Resolvendo o problema com vinculação dinâmica   364 Bibliotecas de sistema Android  n  Compilando um aplicativo dinamicamente vinculado  n  exit() versus return()  n  Código de partida

13.3 Que horas são? O DayTime Server   371 Aplicativo DayTime Server  n daytime.c n  O banco de dados SQLite  n  Compilando e executando o DayTime Server

13.4 DayTime Client  379 Activity  n  Soquete de cliente  n  Testando o DayTime Client

13.5 Resumo  381



SUMÁRIO

Parte 4

xxv

O amadurecimento da plataforma.................385

14

Bluetooth e sensores   387 14.1 Explorando as capacidades do Android Bluetooth   388 Substituindo cabos  n  Papéis primários e secundários e soquetes  n  Confiando em um dispositivo  n  Conectando-se a um dispositivo remoto  n  Capturando eventos de Bluetooth  n Permissões Bluetooth

14.2 Interagindo com o SensorManager   395 Tipos de sensores  n  Lendo valores de sensor  n  Ativação e desativação de sensores

14.3 Criando o aplicativo SenseBot   399 Interface do usuário  n  Interpretando os valores do sensor  n  Guiando o robô  n  Comunicação com o robô

14.4 Resumo  405

15

Integração  406 15.1 Entendendo o modelo de contato do Android   407 Escolhendo registros abertos  n  Lidando com múltiplas contas  n Uma visualização unificadora a partir de diversos armazenamentos remotos  n  Compartilhando o playground

15.2 Introdução ao LinkedIn   412 15.3 Gerenciando contatos  414 Tirando proveito do aplicativo Contacts integrado  n Solicitando operações a partir de seu aplicativo  n  Lendo e modificando os contatos diretamente no banco de dados  n  Adicionando contatos

15.4 Mantendo tudo junto   422 O sonho da sincronização  n  Definindo contas  n  Contando segredos: o serviço AccountManager

15.5 Criando uma conta no LinkedIn   426 Não amigável para celulares  n  Autenticando o LinkedIn

15.6 Sincronizando com o backend usando SyncAdapter  433 O ciclo de vida da sincronização  n  Sincronizando dados do LinkedIn

15.7 Conclusão: o LinkedIn em ação   436 Finalizando o projeto LinkedIn  n  Dica para solução de problemas  n  Seguindo em frente

15.8 Resumo  439

xxvi

ANDROID EM AÇÃO

16

ELSEVIER

Desenvolvimento web Android   441 16.1 O que é desenvolvimento web Android?   442 Apresentando o WebKit  n  Examinando as opções de arquitetura

16.2 Otimizando aplicativos web para o Android   444 Projetando para uso móvel  n  Adicionando o tag viewport  n  Carregando conteúdo seletivamente  n  Interrogando o agente do usuário  n  A pesquisa de mídia  n  Considerando um aplicativo voltado para dispositivos móveis

16.3 Armazenando dados diretamente no navegador   451 Configurando as coisas  n  Examinando o código  n  Interface de usuário  n  Abrindo o banco de dados  n  Desempacotando a função transaction  n  Inserindo e excluindo linhas  n  Testando o aplicativo com as ferramentas WebKit

16.4 Construindo um aplicativo híbrido   460 Examinando o controle do navegador  n  Preparando o controle  n  Implementando o handler JavaScript  n Acessando o código de JavaScript  n  Cavando o JavaScript  n  Questões de segurança  n  Implementando um WebViewClient  n  Aprimorando o navegador  n  Detectando eventos de navegação  n Implementando WebChromeClient

16.5 Resumo  473

17

AppWidgets  474 17.1 Apresentando o AppWidget   475 O que é um AppWidget?  n  Estratégias de implementação do AppWidget

17.2 Apresentando o SiteMonitor   478 Os benefícios do SiteMonitor  n  A experiência do usuário

17.3 Arquitetura do aplicativo SiteMonitor   482 Visão panorâmica do aplicativo  n  Arquivo por arquivo

17.4 Gerenciamento de dados de AppWidget   485 17.5 Implementando o AppWidgetProvider   488 Inventário do método AppWidgetProvider  n Implementando SiteMonitorWidgetImpl  n  Lidando com widgets zumbis

17.6 Exibindo um AppWidget com RemoteViews   493 Trabalhando com RemoteViews  n  UpdateOneWidget explicado

17.7 Configurando uma instância de AppWidget   496 Metadados de AppWidget  n  Trabalhando com dados de Intent  n  Confirmando a criação de um widget



SUMÁRIO

xxvii

17.8 Atualizando o AppWidget   500 Comparando services a alarms  n  Disparando a atualização  n  Atualizando os widgets, finalmente!

17.9 Unindo tudo com AndroidManifest.xml   507 17.10 Resumo  508

18

Localização  510 18.1 A necessidade da localização   511 18.2 Explorando locais  512 18.3 Estratégias para localizar um aplicativo   513 Identificando locais e dados alvo  n  Identificando e gerenciando strings  n  Drawables e layouts  n  Datas, horas, números e moedas  n  Trabalhando com a equipe de tradução

18.4 Alavancando as capacidades de recursos Android   518 Mais que o local  n  Designando strings nos recursos

18.5 Localização dinâmica em Java   520 18.6 Formatando strings localizadas   522 18.7 Obstáculos para a localização   523 18.8 Resumo  524

19

Android Native Development Kit   525 19.1 Apresentando o NDK   526 Usos do NDK  n  Examinando o NDK

19.2 Construindo um aplicativo com o NDK   528 Demonstrando o aplicativo completo  n  Examinando a estrutura do projeto

19.3 Construindo a biblioteca JNI   530 Entendendo o JNI  n  Implementando a biblioteca  n  Compilando a biblioteca JNI

19.4 Construindo a interface de usuário   537 Layout da interface de usuário  n  Tirando uma foto  n  Encontrando as bordas

19.5 Integrando o NDK ao Eclipse    542 19.6 Resumo  544

20

Fragmentos de activity   545 20.1 Ciclo de vida de fragmento   546 20.2 Criando de fragmentos e layouts de fragmento   547 Crie a subclasse do fragmento  n  Definindo um layout de fragmento  n  Incluindo o fragmento dentro da activity

xxviii

ANDROID EM AÇÃO

ELSEVIER

20.3 Fragmentos de segundo plano   553 20.4 O gerenciador de fragmentos   555 20.5 Transações de fragmento   556 20.6 Pilha de fragmentos   556 20.7 O Android Compatibility Package   557 20.8 Resumo  559

21

A barra de ações do Android 3.0   560 21.1 Introdução à barra de ações   560 21.2 Visão geral das classes ActionBar   562 21.3 Opções de exibição da barra de ações   563 Nome e ícone do aplicativo  n  Modos de navegação

21.4 Itens de ação   571 O ícone do aplicativo como um item de ação  n  Action views

21.5 Removendo, mostrando e ocultando a barra de ações  575 21.6 Estilizando a barra de ações   576 21.7 Resumo  578

22

Arrastar e soltar   579 22.1 As classes de arrastar e soltar   580 22.2 Operações de arrastar e soltar   582 22.3 O construtor de sombras   583 22.4 Eventos de arrastar   585 22.5 Iniciando operações de arrastar   586 22.6 Ouvindo eventos de arrastar e soltar   587 22.7 Respondendo a operações de início de arrastar   588 22.8 Tratando operações de soltar   589 22.9 Resumo  590

Apêndice A Instalando o Android SDK   591 Apêndice B Publicando aplicativos  601 Índice  613

Parte1 O que é Android? Uma visão geral

O

Android tornou-se uma plataforma de tecnologia capaz de mover o mercado — não só por causa da funcionalidade disponível na plataforma, mas por causa de como a plataforma entrou no mercado. A Parte 1 deste livro fornece uma visão geral para você como desenvolvedor da plataforma de código-fonte aberto Android. Começamos examinando a plataforma Android e o impacto que ela teve em cada um dos maiores protagonistas no mercado de aplicativos para aparelhos celulares (Capítulo 1). Vamos trazê-lo a bordo do desenvolvimento de aplicativos para Android com um passeio prático pelo ambiente de desenvolvimento do Android (Capítulo 2).

Página deixada intencionalmente em branco

1

Apresentando o Android

Visão geral do capítulo:

 Explorando o Android, a plataforma de celular e tablet de código-fonte aberto  Os Intents do Android, como as coisas funcionam  Aplicativo de exemplo

Você já ouviu falar do Android. Você já leu sobre o Android. Agora, é hora de começar a desvendar o Android. Android é uma plataforma de software que está revolucionando o mercado global de aplicativos para celulares. É a primeira plataforma de aplicativos para telefones celulares de código-fonte aberto que se fez notar pelos maiores mercados de telefonia celular do globo. Quando você examina o Android, existem diversas dimensões técnicas e mercadológicas a considerar. A primeira seção introduz a plataforma e fornece o contexto para ajudá-lo a entender melhor o Android e onde ele se encaixa na cena global dos aplicativos para celulares. Além do mais, o Android eclipsou o mercado de telefonia celular e, com o lançamento do Android 3.X, começou a fazer também incursões no mercado de tablets. Este livro concentra-se no uso dos SDKs do 2.0 ao 3.X O Android é primariamente um esforço do Google, em colaboração com a Open Handset Alliance. Open Handset Alliance é uma aliança de dezenas de organizações comprometidas em trazer para o mercado um telefone celular “melhor” e mais “aberto”. Considerado uma curiosidade por alguns no começo, o Android cresceu em poucos anos para se tornar um ator capaz de mudar o mercado, ganhando tanto respeito como escárnio dos seus colegas da indústria. Este capítulo apresenta o Android — o que ele é, e, igualmente importante, o que ele não é. Após ler este capítulo, você irá entender como o Android é cons­truído, como ele se compara com outras opções do mercado e quais são suas tecnologias fundamentais. Além disso, você terá uma prévia da arquitetura de um aplicativo

4

Capítulo 1  Apresentando o Android

ELSEVIER

Android. Mais especificamente, este capítulo examina a plataforma Android e sua relação com o popular sistema operacional Linux, a linguagem de programação Java e o ambiente de tempo de execução conhecido como Dalvik virtual machine (VM). Conhecimentos em programação Java são úteis ao longo do livro, mas este capítulo é mais sobre preparar o palco do que sobre detalhes de codificação. Um elemento de código apresentado neste capítulo é a classe Intent. Entender bem e sentir-se à vontade com a classe Intent é essencial para trabalhar com a plataforma Android. Além do Intent, este capítulo apresenta os quatro componentes principais do aplicativo: Activity, Service, ContentProvider e BroadcastReceiver. O capítulo é concluído com um aplicativo Android simples para fazê-lo começar rapidamente.

1.1

A plataforma Android O Android é um ambiente de software escrito para dispositivos móveis. Não é uma plataforma de hardware. O Android inclui um Sistema Operacional (OS) baseado em um kernel Linux, uma rica Interface de Usuário (IU), aplicativos de usuário, bibliotecas de código, frameworks de aplicativo, suporte a multimídia e muito mais. E sim, até funcionalidades de telefone estão incluídas! Enquanto os componentes do OS estão escritos em C ou C++, os aplicativos de usuários são escritos em Java para Android. Mesmo os aplicativos embutidos são escritos em Java. Com exceção de alguns exercícios exploratórios do Linux no Capítulo 13 e o Native Development Kit (NDK) no Capítulo 19, todos os exemplos de código neste livro estão escritos em Java, usando o Android Software Development Kit (SDK). Uma característica da plataforma Android é que não existe diferença entre os aplicativos integrados e os aplicativos que você cria com o SDK. Isso significa que você pode escrever poderosos aplicativos que acessam os recursos disponíveis no dispositivo. A Figura 1.1 mostra a relação entre o Android e o hardware em que ele é executado. A principal Ambiente de software característica do Android é que seu do Android código-fonte é aberto. Elementos faltantes podem ser fornecidos pela coAplicativos munidade global de desenvolvedores. personalizados e integrados O OS baseado em Linux do Android escritos em Java não possui um ambiente de shell soMáquina virtual fisticado, mas como a plataforma é Dalvik virtual aberta, você pode escrever e instalar Kernel Linux shells em um dispositivo. Do mesmo modo, codecs multimídia podem ser fornecidos por desenvolvedores independentes e não é necessário depender do Google ou de mais ninguém para fornecer novas funcionalidades. Figura 1.1  O Android é somente software. Tirando proveito do seu kernel Linux para a interface Esse é o poder de uma plataforma com o hardware, o Android roda em muitos dispode código-fonte aberto no mercado sitivos de vários fabricantes. Os desenvolvedores móvel. escrevem aplicativos em Java.



Entendendo o mercado do Android

5

PLATAFORMA VERSUS DISPOSITIVO  Neste livro, sempre que o código precisar

ser testado em um dispositivo, geralmente será utilizado um software emulador. Há uma exceção no Capítulo 14, onde testamos Bluetooth e sensores. Consulte o Capítulo 2 para obter informações sobre como configurar e usar o emulador do Android. O termo plataforma se refere ao próprio Android — o software — incluindo todos os binários, bibliotecas de código e ferramentas. Este livro se concentra na plataforma Android. Os emuladores de Android disponíveis no SDK são simples componentes da plataforma Android. Com tudo isso como fundo, criar uma plataforma móvel de sucesso é claramente uma tarefa não trivial, envolvendo diversos jogadores. O Android é um empreendimento ambicioso, mesmo para o Google, uma companhia de recursos e determinação que parecem sem limites — e eles estão realizando o trabalho. Em um período de três anos, o Android passou por vários grandes releases de software, o release de diversos aparelhos das maiores operadoras do mercado global e, mais recentemente, a introdução de tablets com tecnologia Android. Agora que você foi apresentado ao que é o Android, vamos examinar o porquê e onde do Android para dar um pouco de contexto e dar a perspectiva da introdução do Android no mercado. Depois disso, vamos explorar a própria plataforma!

1.2

Entendendo o mercado do Android O Android promete ter alguma coisa para todos. Ele visa suportar uma variedade de dispositivos de hardware, não somente dispositivos de ponta associados tipicamente com caros smartphones. É claro, os usuários do Android vão desfrutar de desempenho melhor em um dispositivo mais poderoso, uma vez que ele possui uma série de características computacionais melhores. Mas como o Android consegue se adaptar a uma variedade de mercados e aumentar sua fatia de mercado e de mind share? Com que rapidez o mercado de smartphones se torna o padrão? Algumas pessoas ainda se apegam a dispositivos que são só telefones, embora os smartphones estejam crescendo rapidamente em todas as faixas demográficas. Vamos examinar o Android da perspectiva de alguns atores já existentes no mercado. Quando se fala do mercado de celulares, o lugar para começar é no topo, com as portadoras, ou, como às vezes são chamadas, operadoras de telefonia móvel.

1.2.1 Operadoras de telefonia móvel As operadoras de telefonia celular (companhias de telefonia como a AT&T e a Verizon) estão no negócio, acima de tudo, de vender assinaturas dos seus serviços. Os acionistas querem retorno do seu investimento, e é difícil imaginar uma indústria com maior investimento do que uma rede que se estende por territórios geográficos tão extensos. Para a operadora de telefonia móvel, os celulares são simultaneamente um canal de serviços, uma droga para atrair assinantes e um incômodo para suportar e manter. Algumas operadoras estão abraçando o Android como uma plataforma para levar os novos serviços de dados além do excesso de capacidade que as operado-

6

Capítulo 1  Apresentando o Android

ELSEVIER

ras possuem nas suas redes. Os serviços de dados são serviços premium, com alta margem de lucro para a operadora. Se o Android puder ajudar a aumentar os lucros da operadora, muito melhor! Outras operadoras se sentem ameaçadas pelo Google e o potencial de “wireless gratuito”, suportado por anúncios e uma revolução no mercado. Outro desafio para as operadoras é que elas querem ter a palavra final sobre que serviços são permitidos nas suas redes. Historicamente, os fabricantes de aparelhos reclamam que seus dispositivos são deficientes e não executam todos os recursos projetados neles porque as operadoras não têm a capacidade ou vontade de suportar esses recursos. Um sinal encorajador é que existem operadoras envolvidas na Open Handset Alliance. Vamos fazer agora uma comparação entre o Android e os telefones celulares existentes hoje no mercado.

1.2.2 Android versus feature phones A maioria dos celulares no mercado continua a ser telefones do tipo flip e feature phones — telefones que não são smartphones.1 Esses telefones são aqueles que os consumidores recebem quando entram na loja e perguntam o que podem receber de graça. Esses consumidores são aqueles que dizem “eu só quero um telefone”. Seu interesse principal é um telefone para comunicação por voz, uma agenda de contatos e, cada vez mais, texto. Talvez eles queiram até uma câmera. Muitos desses telefones possuem características adicionais como navegação na web, mas devido à experiência de usuário relativamente pobre, essas características não são muito usadas. A única exceção são as mensagens de texto, que são a aplicação dominante, independente da classificação do dispositivo. Outra categoria cada vez mais procurada são os serviços de localização, que geralmente usam o Global Positioning System (GPS) . O desafio do Android é se adaptar a esse mercado. Alguns dos recursos não essenciais do Android podem ser deixados de fora para se encaixar em hardwares mais básicos. Uma das grandes lacunas nas funcionalidades desses telefones básicos é a experiência web do usuário. Parte do problema é o tamanho da tela, mas igualmente desafiador é a própria tecnologia do navegador, que muitas vezes luta para se igualar à rica experiênFigura 1.2  A tecnologia nativa do navecia dos computadores desktop. O Android gador do Android é baseada no mecanispossui o mecanismo de navegador WebKit, mo de navegador WebKit. 1

Aproximadamente 25% dos telefones vendidos nos EUA no segundo trimestre de 2011 foram smartphones: http://www.gartner.com/it/page.jsp?id=1764714.



Entendendo o mercado do Android

7

líder de mercado, que traz para a arena de celulares uma navegação compatível com os desktops. A Figura 1.2 mostra o WebKit em ação no Android. Se uma experiência rica na web puder ser efetivamente adaptada para o hardware da classe dos feature phones, isso seria um grande avanço para penetração nessa faixa do mercado. O Capítulo 16 examina mais de perto o uso de conhecimentos de desenvolvimento web na criação de aplicativos Android. WEBKIT  O mecanismo de navegador WebKit (www.webkit.org) é um projeto

de código-fonte aberto que alimenta o navegador encontrado nos Macs (Safari) e é o mecanismo por trás do Safari Mobile, o navegador do iPhone. Não é exagero dizer que a experiência do navegador é um dos poucos recursos que tornou o iPhone popular desde o seu lançamento, de tal modo que sua inclusão no Android é uma forte adição à arquitetura do Android.

Os softwares na faixa inferior do mercado geralmente se dividem em dois campos:  Ambiente BREW da Qualcomm — BREW significa Binary Runtime Enviroment for

Wirelles (ambiente de tempo de execução binário para rede sem fio). Para um exemplo de alto volume da tecnologia BREW, considere os dispositivos “Get It Now” da Verizon, que rodam nessa plataforma. O desafio para os desenvolvedores de software que querer ter acesso a esse mercado é que as barreiras para colocar um aplicativo nessa plataforma são muitas, porque tudo é gerenciado pela operadora de celular, com testes caros e estruturas de divisão de lucros. A vantagem dessa plataforma é que a operadora coleta o dinheiro e o repassa para o desenvolvedor após a venda, e frequentemente essas vendas ocorrem mensalmente. Todo o resto é um desafio para o desenvolvedor de software. O ambiente de aplicativos abertos do Android é mais acessível que o BREW.  Java ME, ou Plataforma Java, Edição Micro — Uma plataforma popular nessa classe

de dispositivos. A barreira para entrada é muito menor para os desenvolvedores de software. Os desenvolvedores para Java ME encontraram um ambiente “parecido mas diferente” no Android. O Android não é uma plataforma estritamente compatível com Java-ME, mas o ambiente de programação Java encontrado no Android é um extra para os desenvolvedores para Java ME. Existem alguns projetos em andamento para criar um ambiente-ponte, com a intenção de permitir que os aplicativos Java ME sejam compilados e executados em Android. Jogos, um navegador melhor e qualquer coisa relacionada a mensagens de texto e aplicativos sociais fornecem um território fértil para o Android nessa faixa do mercado. Embora a maioria dos celulares vendidos no mundo não seja considerada smartphones, a popularidade do Android (e outras plataformas similares) aumentou a demanda por dispositivos com funções avançadas. Isso é o que vamos discutir a seguir.

1.2.3 Android versus smartphones Vamos começar enumerando as maiores empresas de smartphones: Symbian (grande excluído da América do Norte), BlackBerry da Research in Motion, iPhone da Apple, Windows (Mobile, SmartPhone, e agora Phone 7), e, é claro, a cada vez mais popular plataforma Android.

8

Capítulo 1  Apresentando o Android

ELSEVIER

Uma das maiores preocupações do mercado de smartphones é se uma plataforma pode sincronizar dados e acessar sistemas de informação corporativos para usuários empresariais. Ferramentas de gerenciamento de dispositivos são também um fator importante no mercado empresarial. A experiência de navegador é melhor do que nos celulares básicos, principalmente por causa das telas maiores e métodos de entrada mais intuitivos, tais como telas sensíveis ao toque, touch pad, teclados deslizantes e controles giratórios. A oportunidade do Android nesse mercado é fornecer um dispositivo e software que as pessoas queiram. Para todos os aplicativos disponíveis no iPhone, trabalhar com a Apple pode ser um desafio. Se o dispositivo não atender suas necessidades, há pouco espaço para manobra, por causa dos poucos modelos disponíveis e a histórica exclusividade de operadora. Agora que email, calendário e contatos podem ser sincronizados com o Microsoft Exchange, o ambiente corporativo está mais acessível, mas o Android vai continuar lutando para escalar as muralhas empresariais. Mais tarde, lançamentos do Android adicionaram suporte melhorado à plataforma Microsoft Exchange, embora soluções de terceiros ainda tenham desempenho melhor que as nativas. O BlackBerry é dominante por causa das suas capacidades intuitivas de email, e as plataformas da Microsoft são convincentes por causa na integração à experiência de desktop e a familiaridade com os usuários Windows. O iPhone possui uma integração surpreendentemente boa com o Microsoft Exchange — Para o Android competir nessa arena, ele deve manter a paridade com o iPhone no suporte empresarial. Você viu agora como o Android se posiciona em comparação com os celulares básicos e com os smartphones. Agora, vamos ver se o Android, a plataforma de código-fonte aberto móvel, pode ter sucesso como projeto de código-fonte aberto.

1.2.4 Android versus Android O Android provavelmente será sempre um projeto de código-fonte aberto, mas para ter sucesso no mercado móvel, ele deve vender milhões de unidades e continuar novo. Embora o Google tenha brevemente entrado na guerra dos dispositivos com seus celulares Nexus One e Nexus S, ele não é uma empresa de hardware. Historicamente, os dispositivos com tecnologia Android são lançados no mercado por outras empresas, como a HTC, Samsung e Motorola, para citar os maiores atores. A partir da metade de 2011, o Google começou a ostentar sua força com a aquisição da divisão de negócios de telefonia celular da Motorola. Especula-se que o principal interesse do Google está no portfólio de patentes da Motorola, pois o panorama da propriedade intelectual está consideravelmente aquecido. Uma segunda razão pode ser adquirir a plataforma Motorola Xoom enquanto o Android continua a chegar aos telefones celulares, tablets e além disso. Quando um fabricante cria um dispositivo com tecnologia Android, ele começa com a Android Open Source Platform (AOSP) e a estende para atender sua necessidade de diferenciar suas ofertas. O Android não foi o primeiro telefone de código-fonte aberto, mas foi o primeiro de um jogador com o peso mercadológico do Google liderando o ataque. Essa posição de liderança de mercado já se traduziu em impressionantes vendas entre os diversos fabricantes e mercados em todo o mundo. Com a variedade de dispositivos



Entendendo o mercado do Android

9

no mercado, poderá o Android deter a fragmentação há muito esperada da confiança do consumidor e investidor? O código-fonte aberto é uma faca de dois gumes. Por um lado, o poder de muitas pessoas e companhias talentosas trabalhando ao redor do mundo e em tempo integral para entregar recursos desejáveis é uma força a ser respeitada, particularmente em comparação com a abordagem comercial tradicional do desenvolvimento de software. Esse tópico é trivial, porque os benefícios do desenvolvimento de código-fonte aberto são bem documentados. Por outro lado, quanto os fabricantes concorrentes irão expandir e potencialmente dividir o Android? Dependendo da sua perspectiva, a variedade de ofertas do Android é uma alternativa bem-vinda à plataforma mais monolítica do iPhone, onde os consumidores têm poucas opções disponíveis. Outro desafio para o Android é que o modelo de licenciamento do código de código-fonte aberto para uso comercial pode ser complexo. Algumas licenças de software são mais restritivas que outras e algumas destas restrições oferecem um desafio ao modelo de código-fonte aberto. Ao mesmo tempo, os licenciadores de Android precisam proteger seu investimento, então o licenciamento é um tópico importante para a comercialização do Android.

1.2.5 Licenciando o Android O Android é lançado com duas diferentes licenças de código-fonte aberto. O kernel Linux é lançado com a GNU General Public License (GPL), uma vez que ela é reque-

Vendendo aplicativos Uma plataforma móvel é valiosa somente se existirem aplicativos para serem usados e aproveitados nela. Para isso, o tópico de comprar e vender aplicativos para Android é importante e nos dá uma oportunidade de destacar uma diferença chave entre o Android e o iPhone. A AppStore da Apple contém softwares para o iPhone — muitos deles. Mas o controle algo draconiano da Apple sobre o mercado de softwares para iPhone requer que todos os aplicativos sejam vendidos neste ambiente. Embora o controle de direitos digitais (DRM) da Apple seja invejado pelo mercado, esta abordagem pode criar um ambiente desafiador para os desenvolvedores de software, que podem preferir disponibilizar seus aplicativos por meio de múltiplos canais de distribuição. Em contraste com a abordagem da Apple para a distribuição de aplicativos está a liberdade que os desenvolvedores Android desfrutam para vender seus aplicativos por meios tradicionais, como freeware e shareware, e comercialmente por meio de diversas lojas, incluindo o próprio web site! Para os vendedores de software que desejam uma experiência de compra no dispositivo, o Google lançou e continua a melhorar o Android Market. Para desenvolvedores de software que já possuem títulos em outras plataformas, tais como Windows Mobile, Palm e BlackBerry, mercados tradicionais de software como o Handango, (www.Handango.com) também dão suporte à venda de aplicativos Android. O Handango e seus similares são lojas importantes. Os consumidores novatos no Android vão provavelmente visitar sites como o Handango, porque este pode ser o lugar onde eles compraram um dos aplicativos favoritos do dispositivo anterior.

10

Capítulo 1  Apresentando o Android

ELSEVIER

rida para qualquer um que licencie o kernel OS de código-fonte aberto. A plataforma Android, excluindo o kernel, é licenciada sob a Apache Software License (ASL). Embora os dois modelos de licença sejam orientados a código-fonte aberto, a principal diferença é que a licença Apache é considerada mais amigável ao uso comercial. Alguns puristas do código-fonte aberto podem achar errado qualquer coisa diferente de abertura completa, distribuição de código fonte e não comercialização. A ASL procura equilibrar os objetivos de de código-fonte aberto e forças de mercado. Até então, havia ocorrido apenas um problema de licenciamento que afetara a comunidade Android, e ela teve mais a ver com uma área cinzenta nas imagens de sistema completo do que com o uso do Android por um fabricante em uma versão do produto. Atualmente, o Android está enfrentando desafios relativos a propriedade intelectual: tanto a Microsoft quanto a Apple estão abrindo processos contra a Motorola e a HTC devido aos aparelhos Android desses fabricantes. A parte geral do livro, orientada ao mercado, terminou aqui! O restante do livro é focalizado no desenvolvimento de aplicativos Android. Qualquer discussão técnica sobre um ambiente de software deve incluir uma revisão das camadas que compõem o ambiente, chamadas camadas por causa da sua construção em pilhas. A seguir, uma discriminação geral dos componentes da pilha Android.

1.3

As camadas do Android A pilha do Android inclui uma impressionante gama de recursos para aplicativos móveis. De fato, examinando somente a arquitetura, sem o contexto de o Android ser uma plataforma projetada para ambientes móveis, seria fácil confundir o Android com um ambiente computacional geral. Todos os maiores componentes de uma plataforma computacional estão presentes. Aqui temos uma rápida descrição dos componentes proeminentes da pilha Android:  Um kernel Linux que fornece uma camada fundamental de abstração de hardwa-

re, além de serviços base como gerenciamento de processos, memória e sistema de arquivos. O kernel é onde os drivers específicos de hardware são implementados — recursos como Wi-Fi e Bluetooth são encontrados aqui. A camada Android é projetada para ser flexível, com muitos componentes opcionais que dependem muito da disponibilidade do hardware específico de um dado dispositivo. Esses componentes incluem recursos como teclas sensíveis ao toque, câmeras, receptores GPS e acelerômetros.  Bibliotecas de código proeminentes, incluindo o seguinte:

– Tecnologia de navegador do WebKit, o mesmo mecanismo de código-fonte aberto por trás dos navegadores Safari do Mac e Safari Mobile do iPhone. O WebKit se tornou o padrão de fato para a maioria das plataformas móveis. – Suporte a bancos de dados via SQLite, um banco de dados SQL fácil de usar. – Suporte gráfico avançado, incluindo 2D, 3D, animações com a Scalable Games Language (SGL), e OpenGL ES. – Suporte a áudio e vídeo com o OpenCORE da PacketVideo e o framework de mídia Stagefright do Google.



As camadas do Android

11

– Capacidade Secure Sockets Layer (SSL) do projeto Apache.  Um conjunto de gerenciadores que fornece serviços para:

– Atividades e visualizações. – Janelas. – Serviços baseados em localização. – Telefonia. – Recursos.  O runtime do Android, que fornece:

– Pacotes básicos Java para um ambiente quase completo de programação Java. Observe que esse não é um ambiente Java ME. – A Dalvik VM, que emprega serviços do kernel Linux para fornecer um ambiente de hospedagem de aplicativos Android. Tanto aplicativos base e aplicativos de terceiros (como os que você vai construir com este livro) são executados com o Dalvik VM, além dos componentes que acabamos de listar. Você pode ver a relação entre essas camadas na Figura 1.3. DICA  Sem dúvida, o desenvolvimen-

to de Android requer habilidades em programação Java. Para tirar o máximo proveito deste livro, revise seus conhecimentos de programação Java. Existem muitas referências sobre Java na internet e não há falta de livros sobre Java no mercado. Uma excelente fonte de títulos sobre Java pode ser encontrada em www.manning.com/catalog/java.

Aplicativos de usuário: Contatos, telefone, navegador, etc. Gerenciadores de aplicativo: janelas, conteúdo, atividades, telefonia, localização, notificações, etc.

Tempo de execução Android: Java via Dalvik VM Bibliotecas: gráficos, mídia, bancos de dados, comunicações, engine do navegador, etc.

Kernel Linux, incluindo drivers de dispositivo navegador, etc. Hardware com recursos específicos como GPS, câmera, Bluetooth, etc.

Figura 1.3  A pilha do Android oferece um impressionante conjunto de tecnologias e recursos.

Agora que mostramos o diagrama de pilha obrigatória e apresentamos todas as camadas, vamos examinar em mais profundidade a tecnologia de tempo de execução que sustenta o Android.

1.3.1 Construindo sobre o kernel Linux O Android é construído sobre um kernel Linux e sobre uma máquina virtual (VM) otimizada e avançada para seus aplicativos Java. Ambas as tecnologias são cruciais ao Android. O componente kernel Linux da pilha do Android promete agilidade e portabilidade para tirar vantagem das diversas opções de hardware de futuros telefones Android. O Ambiente Java do Android é a chave: ele torna o Android acessível aos programadores por causa do número de desenvolvedores de software Java e o rico ambiente que a programação Java tem a oferecer.

12

Capítulo 1  Apresentando o Android

ELSEVIER

Por que usar Linux em um telefone? Usar uma plataforma completa com o kernel Linux fornece potência e recursos tremendos para o Android. Usar uma fundação de código-fonte aberto libera as capacidades de companhias e indivíduos talentosos para avançar a plataforma. Tal arranjo é particularmente importante no mundo dos dispositivos móveis, onde os produtos mudam rapidamente. A taxa de mudança no mercado móvel faz o mercado geral de computadores parecer lento e arrastado. E, é claro, o kernel Linux é uma plataforma base comprovada. A confiabilidade é mais importante que o desempenho quando se trata de um telefone móvel, por que a comunicação por voz é o uso primário de um telefone. Todos os usuários de telefones celulares, seja para uso pessoal ou empresarial, precisam de confiabilidade na voz, mas eles também querem recursos divertidos de dados e vão comprar um aparelho baseado nesses recursos. O Linux pode ajudar a atender essa exigência. Falando na rápida troca de telefones e acessórios que atinge o mercado, outras vantagens de usar o Linux como o alicerce da pilha da plataforma Android é que ele fornece uma camada de abstração de hardware. Os níveis superiores permanecem inalterados a despeito de mudanças do hardware. É claro, boas práticas na codificação requerem que os aplicativos de usuário falhem com graça no caso em que um recurso não esteja disponível, como uma câmera ausente em um modelo em particular. Conforme novos acessórios aparecem no mercado, drivers podem ser escritos no nível do Linux para fornecer suporte, do mesmo modo que em outras plataformas Linux. Essa arquitetura já demonstrou seu valor: Já existem dispositivos Android disponíveis em diferentes plataformas de hardware. HTC, Motorola e outras lançaram dispositivos baseados em Android construídos em suas respectivas plataformas de hardware. Aplicativos de usuário, além de outros aplicativos Android, são escritos em Java e são compilados em códigos de byte. Códigos de byte são interpretados no tempo de execução por um interpretador conhecido como máquina virtual (virtual machine – VM).

1.3.2 Executando na Dalvik VM A Dalvik VM é um exemplo da colisão da necessidade de eficiência, o desejo por um ambiente de programação rico e até algumas restrições de propriedade intelectual com a inovação como resultado. O ambiente Java do Android fornece uma plataforma de aplicativos rica e acessível devido à popularidade do próprio Java. Além disso, o desempenho dos aplicativos, particularmente em ambientes de pouca memória, como o de um telefone celular, é essencial para o mercado móvel. Mas essa não é a única questão. O Android não é uma plataforma Java ME. Sem comentários sobre se isso é bom ou ruim para o Android, há outras forças em ação aqui. Existe a questão do licenciamento do Java VM da Oracle. Em um nível mais alto, o ambiente de codificação do Android é o Java. Aplicativos são escritos em Java, compilados em códigos de byte Java e subsequentemente traduzidos para uma representação similar, mas diferente, chamada dex files. Esses arquivos são equivalentes lógicos dos códigos de byte Java, mas permitem ao Android executar seus aplicativos na sua própria VM, que é ao mesmo tempo (discutivelmente) livre das limitações de licenciamento da Oracle e uma plataforma aberta na qual o Google, e potencialmente a comunidade de códi-



O Intent do desenvolvimento Android

13

go-fonte aberto, pode melhorar conforme necessário. O Android está enfrentando processos da Oracle pelo uso do Java. NOTA  Do ponto de vista do desenvolvedor de aplicativos, o Android é um am-

biente Java, mas o tempo de execução não é estritamente uma VM Java. Isso cuida das incompatibilidades entre o Android e os ambientes e bibliotecas próprias do Java. Se você tiver uma biblioteca de código que quer reutilizar, sua aposta mais segura é assumir que seu código é quase compatível com a fonte, tentar compilá-lo em um projeto Android e então determinar o quão perto você está de ter um código utilizável. As coisas importantes a saber sobre a Dalvik VM são que os aplicativos Android são executados dentro dela e que ela depende do kernel Linux para serviços como gerenciamento de processos, memória e sistema de arquivos. Agora que já discutimos as tecnologias fundamentais do Android, é hora de nos concentrar no desenvolvimento de aplicativos Android. O restante deste capítulo discute a arquitetura geral de um aplicativo Android e introduz um aplicativo Android simples. Se não estiver confortável ou pronto para começar a codificar, você pode querer pular para o Capítulo 2, onde vamos apresentar o ambiente de desenvolvimento passo a passo.

1.4

O Intent do desenvolvimento Android Vamos pular para a arena do desenvolvimento Android, focalizar em um importante componente da plataforma Android e depois dar uma olhada mais ampla em como os aplicativos Android são construídos. Um tema importante e recorrente do desenvolvimento Android é o Intent. Um Intent no Android descreve o que você quer fazer. Um Intent pode ser algo como “Quero procurar um registro de contato” ou “Abra esse site web” ou “Mostre a tela de confirmação de compra”. Intents são importantes por que eles não só facilitam a navegação de modo inovador, como discutiremos a seguir, mas também representam o aspecto mais importante na codificação Android. Entenda o Intent e você entenderá o Android. NOTA  Instruções para configurar o ambiente de desenvolvimento Eclipse estão

no Apêndice  A. Esse ambiente é usado em todos os exemplos de Java neste livro. O Capítulo 2 entra em mais detalhes sobre como configurar e usar as ferramentas de desenvolvimento. Os exemplos de código neste capítulo são principalmente para fins de ilustração. Nós mencionamos e apresentamos classes sem necessariamente nomear pacotes Java específicos. Os capítulos subsequentes têm uma abordagem mais rigorosa para apresentar os pacotes e classes específicos do Android. Em seguida, vamos examinar informações fundamentais sobre por que os In­ tents são importantes e, então, vamos descrever como os Intents funcionam. Além da introdução aos Intents, o restante do capítulo descreve os principais elementos do desenvolvimento de um aplicativo Android, levando até e incluindo o primeiro aplicativo Android completo que você vai desenvolver.

14

Capítulo 1  Apresentando o Android

ELSEVIER

1.4.1 Criando UIs intuitivas O poder do framework de um aplicativo Android está no fato que ele traz uma mentalidade web para os aplicativos web. Isso não significa que a plataforma possua somente um navegador poderoso e esteja limitada a JavaScript e recursos do lado do servidor, mas ela vai até o núcleo de como a plataforma Android funciona e como os usuários interagem com o dispositivo móvel. O poder da internet é que tudo está a um clique de distância. Esses cliques são conhecidos como Uniform Resource Locators (URLs), ou Uniform Resource Identifiers (URIs) . Usando URIs efetivas permitam acesso rápido e fácil à informação que os usuários precisam e querem a cada dia. “Me mande o link” diz tudo. Além de ser um meio eficiente de acessar dados, qual a importância desse tópico sobre URLs, o que eles tem a ver com Intents? A resposta não é técnica, mas é crucial: O modo que um usuário móvel navega na plataforma é essencial ao sucesso comercial da mesma. Plataformas que replicam a experiência do desktop em um dispositivo móvel são aceitáveis somente por um pequeno número de usuários hardcore. Menus longos e múltiplos cliques são geralmente mal recebidos no mercado móvel. O aplicativo móvel, mais do que em qualquer outro mercado, exige facilidade e intuitividade no uso. Um consumidor pode comprar um dispositivo baseado nos recursos enumerados nos materiais publicitários, mas esse mesmo consumidor provavelmente não vai nem tocar no manual de instruções. A usabilidade da IU essa intimamente ligada a essa penetração no mercado. As UIs também são um reflexo do modelo de acesso de dados da plataforma, então se a navegação e modelos de dados forem claros e intuitivos, a IU vai segui-los. Agora, vamos apresentar os Intents e IntentFilters, os inovadores mecanismos de navegação e ativação do Android. 1.4.2 Intents e como eles funcionam Intents e IntentFilters trazem o paradigma “clique aqui” para o núcleo do uso (e desenvolvimento) de aplicativos móveis para a plataforma Android:  Um Intent é uma declaração de necessidade. Ele é composto de diversas informações que descrevem a ação ou serviço desejados. Vamos examinar a ação requisitada e os dados que geralmente acompanham a ação requisitada.  Um IntentFilter é uma declaração de capacidade e interesse em oferecer as-

sistência àqueles em necessidade. Ele pode ser genérico ou específico em relação a quais Intents ele oferece seu serviço. O atributo de ação de um Intent é normalmente um verbo, por exemplo, VIEW, PICK ou EDIT. Diversas ações nativas Intent são definidas como membros da classe Intent, mas os desenvolvedores de aplicativos podem também criar novas ações. Para visualizar uma informação, um aplicativo emprega a seguinte ação Intent: android.content.Intent.ACTION_VIEW

O componente de dados de um Intent é expresso na forma de um URI e pode ser virtualmente qualquer informação, como um registro de contato, um endereço de web site ou uma referência para um clipe de mídia. A Tabela  1.1 lista alguns exemplos de URI Android.



O Intent do desenvolvimento Android

15

Tabela 1.1  URIs usados comumente no Android Tipo de informação Busca de contato Busca de mapa Abrir uma página Web específica.

Dados do URI content://contacts/people Geo:0,0?q=23+Route+206+Stanhope+NJ http://www.google.com/

O IntentFilter define a relação entre o Intent e o aplicativo. IntentFilters podem ser específicos aos dados do Intent, à ação ou a ambos. Os IntentFilters também contém um campo chamado categoria (category). A categoria ajuda a classificar a ação. Por exemplo, a categoria chamada CATEGORY_LAUNCHER instrui ao Android que a Activity contendo esse IntentFilter deve ser visível no inicializador do aplicativo ou na sua tela inicial. Quando um Intent é expedido, o sistema avalia os Activitys, Services e BroadcastReceivers registrados disponíveis (mais sobre isso na seção 1.5) e expede o Intent para o contêiner mais apropriado. A Figura 1.4 mostra essa relação entre Intents, IntentFilters e BroadcastReceivers. Para alugar: Faça um passeio Para alugar: Localize qualquer pela Internet (IntentFilter) coisa no mapa (IntentFilter) Aplicativo Android nº 2 (BroadcastReceiver)

startActivity(Intent); ou startActivity(Intent,identifier);

Para alugar: Visualize, edite e procure qualquer contato (IntentFilter) Aplicativo Android nº 3 (BroadcastReceiver)

ou startService(Intent);

Ajude-me: Localizar uma pessoa (Intent)

Para alugar: Ação personalizada sobre dados personalizados (IntentFilter) Aplicativo Android nº 4 (BroadcastReceiver)

Ajude-me: Localizar um endereço no mapa (Intent)

Aplicativo Android nº 1

Figura 1.4  Intents são distribuídos entre aplicativos Android que se registram pelo In­ tentFilter, geralmente no arquivo AndroidManifest.xml. IntentFilters são frequentemente definidos no arquivo AndroidManifest.xml

de um aplicativo Android com a tag . O arquivo AndroidManifest. xml é essencialmente um arquivo que descreve o aplicativo, que vamos discutir mais tarde neste capítulo. Uma tarefa comum em um dispositivo móvel é buscar um registro de contato específico com o intuito de iniciar uma chamada, enviar uma mensagem de texto ou buscar um endereço de snail-mail quando você está em uma fila na loja da esquina. Ou um usuário pode querer ver uma informação específica, por exemplo, um regis-

Capítulo 1  Apresentando o Android

16

ELSEVIER

tro de contato para o usuário 1234. Nestes casos, a ação é ACTION_VIEW e os dados são um identificador do registro do contato específico. Para realizar esses tipos de tarefas, você cria um Intent com a ação configurada para ACTION_VIEW e um URI que representa a pessoa ou interesse específico. Eis alguns exemplos:  O URI que você deve usar para contatar o registro do usuário 1234: content://contacts/people/1234

 O URI para obtenção de uma lista de todos os contatos:. content://contacts/people

O seguinte trecho de código mostra como escolher (PICK) um registro de contato: Intent pickIntent = new Intent(Intent.ACTION_PICK,Uri.parse("content:// contacts/people")); startActivity(pickIntent);

Um Intent é avaliado e enviado para o handler mais apropriado. Para escolher um registro de contato, o contêiner provavelmente seria uma Activity nativa chamada com.google.android.phone.Dialer. Mas o melhor contêiner desse Intent pode ser um Activity contido no mesmo aplicativo Android personali-

zado (o que você criou), um aplicativo nativo (nesse caso) ou um aplicativo de terceiros no dispositivo. Os aplicativos podem tirar proveito das funcionalidades existentes em outros aplicativos criando e enviando um Intent que requisita um código existente para manipular o Intent, em vez de ter o código escrito do zero. Um dos grandes benefícios de empregar Intents desse modo é que as mesmas UIs são usadas frequentemente, criando familiaridade para o usuário. Isso é particularmente importante para plataformas móveis, onde o usuário frequentemente não é grande conhecedor de tecnologia e nem tem interesse em aprender diversos modos de realizar a mesma tarefa, como buscar um contato no telefone. Os Intents que discutimos até agora são conhecidos como Intents implícitos, que dependem do IntentFilter e do ambiente Android para despachar o Intent para o contêiner apropriado. Outro tipo de Intent é o Intent explícito, onde você pode especificar a classe exata que você quer que manipule o Intent. Especificar a classe exata é útil quando você sabe exatamente que Activity você quer que manipule o Intent e você não quer deixar nada ao acaso em termos de que código é executado. Para criar um Intent explícito, use o construtor Intent que usa uma classe como argumento: public void onClick(View v) { try { startActivityForResult(new Intent(v.getContext(),RefreshJobs. class),0); } catch (Exception e) { . . . } }



Os quatro tipos de componentes Android

17

Esses exemplos mostram como um desenvolvedor Android cria um Intent e pede que seja manipulado. Do mesmo modo, o aplicativo Android pode ser implementado com um IntentFilter, indicando que ele responde a Intents já definidos no sistema, portanto publicando uma nova funcionalidade à plataforma. Essa faceta sozinha deve alegrar os vendedores independentes de software (ISVs) que ganham a vida oferecendo melhores softwares gerenciadores de contatos e de listas de tarefas para outras plataformas móveis. A resolução de um Intent, ou despacho, acontece no tempo de execução, em vez de quando o aplicativo é compilado. Você pode adicionar recursos específicos de manipulação de Intents a um dispositivo, que podem se mostrar uma funcionalidade melhorada ou mais desejável que o software original de fábrica. Esse despacho no tempo de execução também é chamado late binding. Até agora, essa discussão sobre Intents se concentrou na variedade de Intents que fazem com que os elementos da IU sejam mostrados. Outros Intents são mais orientados a eventos do que a tarefas, como nosso exemplo dos registros de contatos mostrou. Por exemplo, você pode usar a classe Intent para notificar aplicativos que uma mensagem de texto foi recebida. Intents são um elemento central do Android; vamos revê-los em mais de uma ocasião. Agora que explicamos os Intents como catalisadores do fluxo de navegação e eventos no Android, vamos examinar mais amplamente e discutir o ciclo de vida de um aplicativo Android e os componentes chave que fazem o Android funcionar. O Intent vai ser mais bem examinado conforme exploramos mais o Android ao longo do livro.

O poder e complexidade dos Intents Não é difícil imaginar que uma experiência de usuário absolutamente única é possível com o Android por causa da variedade de Activitys com IntentFilters específicos instalados em cada dispositivo. Sua arquitetura é passível de atualização de diversos aspectos de uma instalação Android para fornecer funcionalidades e personalização sofisticadas. Embora isso possa ser uma característica desejável para o usuário, pode ser problemático para quem fornece suporte técnico, o qual terá que navegar por diversos componentes e aplicativos para solucionar um problema. Por causa do potencial de complexidade, essa abordagem de remendar sistemas ad hoc para atualizar funcionalidades específicas deve ser tratada com cuidado e com os olhos abertos para as armadilhas potenciais associadas com essa abordagem.

1.5

Os quatro tipos de componentes Android Vamos aumentar nosso conhecimento das classes Intent e IntentFilter e explorar os quatro componentes dos aplicativos Android, além da sua relação com o modelo de processo Android. Vamos incluir trechos de código para dar um gostinho do desenvolvimento de um aplicativo Android. Vamos deixar os exemplos e discussões mais aprofundados para capítulos posteriores. NOTA  Um aplicativo Android em particular pode não conter todos esses ele-

mentos, mas terá pelo menos um deles, e pode conter todos.

Capítulo 1  Apresentando o Android

18

ELSEVIER

Você diz Intent, eu digo Intent A classe Intent é usada em cenários que parecem similares, mas são muito diferentes. Algumas Intents são usadas para auxiliar a navegação de uma Activity para outra, como no exemplo anterior de buscar um registro de contato. Atividades são os alvos desses tipos de Intents, que são usados com os métodos startActivity ou startActivityForResult. Além disso, um Service pode ser iniciado passando um Intent para o método startService. BroadcastReceivers recebem Intents quando respondem a eventos de todo o sistema, como uma chamada telefônica ou a chegada de uma mensagem de texto.

1.5.1 Activity Um aplicativo pode ter uma IU, mas não precisa ter uma. Se ele tiver uma IU, ela precisa ter pelo menos uma Activity. O meio mais fácil de entender uma Activity Android é relacioná-la à tela visível, porque costuma haver uma relação um-para-um entre uma Activity e uma tela de IU. Essa relação é similar ao de um controlador em um paradigma MVC. Aplicativos Android costumam conter mais de uma Activity. Cada Activity mostra uma IU e responde a eventos iniciados pelo sistema e pelo usuário. A Activity emprega uma ou mais Views para apresentar os elementos de IU ao usuário. A classe Activity é ampliada por classes de usuário, como mostrado na listagem a seguir. Listagem 1.1  Uma Activity básica em um aplicativo Android package com.msi.manning.chapter1; import android.app.Activity; import android.os.Bundle; public class Activity1 extends Activity { @Override public void onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); setContentView(R.layout.main); } }

A classe Activity é parte do pacote Java android.app, encontrado no tempo de execução Android. O tempo de execução Android é implantado no arquivo android.jar. A classe Activity1 estende a classe Activity, que vamos examinar em detalhes no Capítulo 3. Uma das principais funções que uma Activity executa é exibir os elementos de IU, que são implementados como Views e são geralmente definidos em arquivos de layout XML. O Capítulo 3 entra em mais detalhes sobre Views e Resources. A mudança de uma Activity para outra é feita com o método startActivity() ou o método startActivityForResult() quando você quer um paradigma síncrono chamada/resultado. O argumento desses métodos é uma instância de um Intent.



19

Os quatro tipos de componentes Android

A Activity representa um componente visível de um aplicativo dentro do Android. Com a ajuda da classe View, que vamos cobrir no Capítulo 3, a Activity é o componente de aplicativos Android mais utilizado. O Android 3.0 apresentou um novo tipo de componente de aplicativos, os Fragment.Fragments, que estão relacionados a Activitys e têm o seu próprio ciclo de vida, fornecem um controle mais granular do aplicativo do que as Activitys. Os Fragments serão abrangidos no Capítulo 20. O próximo tópico de interesse é o Service, que é executado em segundo plano e geralmente não apresenta uma IU direta.

1.5.2 Service Se um aplicativo tiver um ciclo de vida longo, é geralmente melhor colocá-lo em um Service. Por exemplo, um utilitário de sincronização de dados em segundo plano deve ser implementado como um Service. Uma boa prática é executar Service em uma base periódica ou conforme necessário, ativado por um alarme de sistema, e então fazer o Service se encerrar quando sua tarefa estiver completa. Como a Activity, Service é uma classe no tempo de execução Android que você pode ampliar, como mostrado na listagem a seguir. Esse exemplo estende um Service e periodicamente publica uma mensagem informativa no log do Android. Listagem 1.2  Exemplo simples de um Service Android package com.msi.manning.chapter1; import android.app.Service; import android.content.Intent; import android.os.IBinder; import android.util.Log; public class Service1 extends Service implements Runnable { public static final String tag = "service1"; private int counter = 0; @Override protected void onCreate() { super.onCreate(); Thread aThread = new Thread (this); aThread.start(); } public void run() { while (true) { try { Log.i(tag,"service1 firing : # " + counter++); Thread.sleep(10000); } catch(Exception ee) { Log.e(tag,ee.getMessage()); } } } @Override public IBinder onBind(Intent intent) { return null; } }

q Estende a classe Service

w

Inicialização

a e Manipula requisição de vinculação

Capítulo 1  Apresentando o Android

20

ELSEVIER

Esse exemplo requer o pacote android.app.Service seja importado. Esse pacote contém a classe Service. Esse exemplo também demonstra o mecanismo de log do Android, android.util.Log, que é útil para propósitos de depuração. (Muitos exemplos neste livro incluem o uso do sistema de log. Vamos discutir o uso de logs em mais profundidade no Capítulo 2). A classe Service1  estende a classe Ser­ vice. Essa classe implementa a interface Runnable para executar sua tarefa principal em um thread separado. O método onCreate  da classe Service permite que o aplicativo execute tarefas do tipo inicialização. Vamos falar sobre o método onBind()  em maiores detalhes no Capítulo 4, onde vamos explorar o tópico de comunicação interprocessos em geral. Os Services são iniciados com o método startService(Intent) da classe abstrata Context. Note que, novamente, o Intent é usado para iniciar um resultado desejado na plataforma. Agora que o aplicativo possui uma IU em uma Activity e um meio de realizar uma tarefa de segundo plano via uma instância de um Service, é hora de explorar o BroadcastReceiver, outra forma de aplicativo Android dedicado a processar os Intents.

1.5.3 BroadcastReceiver Se um aplicativo quiser receber e responder a um evento global, como um telefone tocando ou uma mensagem de texto recebida, ele deve se registrar como Broadcast­ Receiver. Um aplicativo se registra para receber Intents usando um destes métodos:  O aplicativo pode implementar um elemento no arquivo AndroidManfest.xml, que descreve o nome da classe BroadcastReceiver e enumera seus IntentFilters. Lembre-se que o IntentFilter descreve o Intent que um

aplicativo quer processar. Se o receptor estiver registrado no arquivo AndroidManifest.xml, o aplicativo não precisa estar em execução para ser ativado. Quando o evento ocorre, o aplicativo é iniciado automaticamente na notificação do evento de ativação. Felizmente, o próprio OS Android gerencia esse processo.  Um aplicativo pode se registrar no tempo de execução pelo método RegisterReceiver da classe Context.

Como os Services, BroadcastReceivers não possuem uma IU. Ainda mais importante, o código sendo executado no método onReceive de um BroadcastRe­ ceiver não deve fazer suposições sobre a duração de operações longas. Se o Broad­ castReceiver precisar de mais do que uma quantia trivial de execução de código, é recomendado que o código inicie uma requisição para um Service completar a função requisitada, porque o componente de aplicativo Service é projetado para operações de longo prazo, enquanto o BroadcastReceiver é feito para responder a diversos gatilhos. NOTA  A conhecida classe Intent é usada para ativar BroadcastReceivers.

Os parâmetros serão diferentes, dependendo de se você está iniciando uma Activity, um Service ou um BroadcastReceiver, mas é a mesma classe Intent usada por toda a plataforma Android.



21

Os quatro tipos de componentes Android

Um BroadcastReceiver implementa o método abstrato onReceive para processar Intents que chegam. Os argumentos desse método são um Context e um Intent. O método retorna void, mas alguns métodos são úteis em retornar resultados, incluindo o setResult, que retorna ao requisitante um código de retorno inteiro, um valor de retorno String e um valor Bundle, que pode conter qualquer número de objetos. A listagem seguinte é um exemplo da ativação de um BroadcastReceiver após recebimento de uma mensagem de texto. Listagem 1.3  Exemplo de BroadcastReceiver package com.msi.manning.unlockingandroid; import android.content.Context; import android.content.Intent; import android.util.Log; import.android.content.BroadcastReceiver public class MySMSMailBox extends BroadcastReceiver { public static final String tag = "MySMSMailBox"; @Override public void onReceive(Context context, Intent intent) { Log.i(tag,"onReceive"); if (intent.getAction().equals ("android.provider.Telephony.SMS_RECEIVED")) { Log.i(tag,"Found our Event!"); } }

usada q Tag no log

a w Verifica ação do Intent

Precisamos discutir alguns itens dessa listagem. A classe MySMSMailBox estende a classe BroadcastReceiver. Essa abordagem de subclasse é o modo mais direto de empregar um BroadcastReceiver. (Note o nome da classe MySMSMailBox;ele será usado no arquivo AndroidManifest.xml, mostrado na œ). A variável tag  é usada em conjunto com o mecanismo de log para ajudar a nomear as mensagens enviadas para o console de log do emulador. Usar uma tag no log permite filtrar e organizar as mensagens de log no console. (Vamos discutir o mecanismo de log em mais detalhes no Capítulo 2). O método onReceive é onde todo o trabalho em um BroadcastReceiver acontece. Você deve implementar esse método. Um dado BroadcastReceiver pode registrar múltiplos IntentFilters. Instâncias de BroadcastReceiver podem ser criadas para um número arbitrário de Intents. É importante garantir que o aplicativo manipula o Intent apropriado verificando a ação do Intent recebido . Quando o aplicativo recebe o Intent desejado, ele deve prosseguir com a funcionalidade desejada. Uma tarefa comum em um aplicativo contêiner de SMS é analisar a mensagem e exibi-la para o usuário usando os recursos encontrados no NotificationManager. (Vamos discutir notificações no Capítulo 8). Na Listagem 1.3, basta você registrar a ação no log. Para que esse BroadcastReceiver dispare e receba esse Intent, o BroadcastReceiver é listado no arquivo AndroidManifest.xml, junto com uma tag intentfilter apropriada, como mostrado na listagem a seguir. Essa listagem contém os elementos necessários para o aplicativo responder a uma mensagem de texto recebida.

Capítulo 1  Apresentando o Android

22

ELSEVIER

Listagem 1.4  AndroidManifest.xml

q

Permissão requerida Tag do contêiner; note o prefixo ponto

w

Certas tarefas na plataforma Android requerem que o aplicativo possua um privilégio designado. Para dar a um aplicativo as permissões necessárias, usa-se a tag . (Vamos discutir essa tag em mais detalhes na seção 1.6). A tag contém o nome da classe que implementa o BroadcastReceiver. Nesse exemplo, o nome da classe é MySMSMailBox, do pacote com.msi.manning. unlockingandroid. Tenha certeza de notar o ponto que precede o nome . Esse ponto é necessário. Se seu aplicativo não se comportar como esperado, uma das primeiras coisas a verificar é seu arquivo Android.xml e procurar o ponto antes do nome da classe! O IntentFilter é definido na tag . A ação desejada nesse exemplo é android.provider.Telephony.SMS_RECEIVED. O Android SDK contém as ações disponíveis para os Intents padrão. Além disso, lembre-se que aplicativos de usuário podem definir seus próprios Intents, além de procurá-los.

Testando SMS O emulador possui um conjunto de ferramentas embutidas para manipular certos comportamentos de telefonia para simular diversas situações, como “dentro de área” e “fora de área” de cobertura e realizar chamadas telefônicas. Para enviar uma mensagem SMS para o emulador, use o protocolo telnet para a porta 5554 (o número da porta pode ser diferente no seu sistema), o que vai fazer a conexão ao seu emulador e exibir a seguinte linha de comando: sms send 0) { Toast.makeText(context,"Searching for " + toSearch,Toast.LENGTH_SHORT).show(); Encontra todas } as ocorrências do } termo } Chama métodos public void onPageFinished(WebView wv,String url) { super super.onPageFinished(wv,url); Log.i(tag,"onPageFinished"); Obtém globais if (!url.equals(WebTutorial.STARTING_PAGE)) { WTApplication app = (WTApplication) context; String toSearch = app.getSearchTerm(); Obtém busca if (toSearch != null && toSearch.trim().length() > 0) { int count = wv.findAll(app.getSearchTerm()); Toast.makeText(app, count + " occurrences of " + toSearch + Encontra todas as ".",Toast.LENGTH_SHORT).show(); ocorrências do termo } } } }

q

w

w

e

r

t

y

w

r

t

y

Estender a WebViewClient  q para nossos objetivos envolve um construtor personalizado mais dois métodos subclassificados. Para cada um dos três métodos, você chama os respectivos métodos super  w para garantir que a classe pai tenha uma oportunidade para realizar a manutenção necessária. Quando filtrar os carregamentos de página, não queremos que nosso comportamento aprimorado seja disparado se estivermos na página inicial index.html recebida com o aplicativo, então, realizamos uma comparação básica de strings  e para ignorar seletivamente as funcionalidades adicionais se voltarmos à página inicial dentro do nosso próprio conteúdo. Assumindo que estejamos em uma página web carregada posteriormente, precisamos acessar a instância android.app.Application  r para ter acesso ao search­ Term armazenado globalmente  t. No método onPageStarted(),lembramos o usuário do termo que estamos pesquisando através de uma notificação Toast. Em onPageFinished(), chamamos o método findAll() para pesquisar a página recém-baixada pelo termo de busca  y. Quando a pesquisa for encerrada, notificamos novamente o usuário através de uma notificação Toast. Essa extensão WebViewClient é instalada com uma chamada para: browser.setWebViewClient(new UAWebViewClient(this.getApplicationContext()));

472

Capítulo 16  Desenvolvimento web com Android

ELSEVIER

Esse aplicativo simples está implorando por melhorias, então fique a vontade para fazer o download do código de exemplo e estender WebViewClient você mesmo, e aproveite a sensação de adicionar funcionalidades ao aplicativo mais popular do mundo — o navegador! Se você gostar de melhorar e modificar comportamentos adicionais do navegador, você vai querer tentar atualizar o Chrome, subclassificando WebChromeClient.

16.4.10 Implementando WebChromeClient A classe WebChromeClient é responsável por gerenciar eventos do lado do cliente como alertas JavaScript, prompt, etc. Adicionalmente, o WebChromeClient é notificado quando uma janela está sendo fechada ou quando uma nova janela está tentando ser aberta. Semelhante à WebViewClient, essa classe é um tópico por si só. Para nossos objetivos aqui, demonstramos seu uso sobrescrevendo a função JavaScript alert(). Voltando ao arquivo index.html da Listagem 16.11, você pode ver o código para manipular o botão Chrome: Chrome. Não existe qualificador especial de namespace nessa função — é a mesma função de alerta JavaScript usada desde que a programação do lado cliente entrou nas nossas vidas com as mensagens pop-up. O único objetivo dessa função é informar o usuário de informações relevantes à sua navegação. A Listagem  16.15 demonstra a subclassificação de WebChromeClient e a implementação do método on­ JsAlert. Novamente, esse método é invocado quando a função de alerta JavaScript é encontrada em uma página web em execução. Listagem 16.15  UAChrome.java package com.msi.manning.webtutorial; import android.content.Context; import android.widget.Toast; import android.webkit.JsResult; import android.webkit.WebChromeClient; import android.webkit.WebView; import android.widget.Toast; Estendendo WebChromeClient public class UAChrome extends WebChromeClient { private Context context; public UAChrome(Context context) { Chama método super super(); this.context = context; } public boolean onJsAlert(WebView wv,String url, Sobrescreve onJsAlert String message,JsResult result) { Toast.makeText(wv.getContext(),message,Toast.LENGTH_SHORT).show(); result.confirm(); Notificação Toast Confirma resultado return true; } Retorna true }

q

w

e

t

y

r

Resumo

473

A classe UAChrome estende WebChromeClient q. No construtor, você chama o construtor da superclasse com uma chamada para super w. Para processar declarações de alertas, precisamos implementar o método onJsAlert  e. Esse método aceita quatro argumentos: a instância WebView hospedando o código JavaScript, a URL da página, a mensagem a ser exibida e um argumento JsResult. O objeto JsResult possui métodos para indicar ao requisitante se o usuário confirmou ou cancelou o prompt. Nesse exemplo de implementação, substituímos a caixa pop-up com uma notificação Toast  r e já que a notificação Toast desaparece por si só, precisamos informar o requisitante que a notificação foi “confirmada”. Isso é feito com uma chamada ao método confirm() do parâmetro JsResult chamado result  t. Finalmente, retornamos um true Booleano para indicar que esse método sobrescrito processou o evento.

16.5 Resumo Este capítulo cobriu bastante material relacionado ao desenvolvimento web para Android. Como muitos tópicos relacionados à programação, nós só arranhamos a superfície — e esperamos ter fornecido inspiração e orientação sobre onde ir mais fundo por conta própria. Começando com a ideia de criar aplicativos web puros os mais amigáveis possíveis no navegador standalone Android, nós exploramos a meta tag viewport com a técnica de carregar arquivos CSS específicos por plataforma. O gerenciamento de folhas de estilos é hoje em dia uma habilidade importante e recomendada para muitos tipos de desenvolvimento web. Indo além dos aspectos da aparência e comportamento do modelo de aplicativos no navegador, nós exploramos a técnica de acessar bancos de dados SQL diretamente do cliente JavaScript. Depois de uma demonstração básica dos métodos de acesso a dados, vimos uma plataforma de testes conveniente na versão desktop do WebKit. Então, prosseguimos para cobrir o que talvez seja hoje o aspecto mais importante da programação web no mundo móvel: a criação de aplicativos híbridos. Aplicativos híbridos podem melhorar um aplicativo Android SDK com formatação extremamente capaz de áreas selecionadas, como telas de ajuda e tutoriais. Ou, como demonstrado no código de exemplo deste capítulo, um aplicativo híbrido pode habilitar uma interface de usuário puramente HTML ou CSS, enquanto permite ao código Java realizar o trabalho pesado. Independente da sua abordagem, entender o básico do desenvolvimento de aplicativos híbridos é um benefício para o programador Android. No próximo capítulo, veremos um dos recursos da plataforma Android que mudam o jogo: o AppWidget.

17

AppWidgets

Visão geral do capítulo: ¡ Apresentando o AppWidget.

¡ Apresentando o aplicativo de exemplo: SiteMonitor ¡ Implementando o AppWidgetProvider. ¡ Configurando uma instância AppWidget ¡ Atualizando os AppWidgets

Continuando com o tema de explorar a plataforma Android, este capítulo examina o AppWidget, que traz funcionalidades para o phone-top, ou tela inicial, de um dispositivo Android. Neste capítulo, você vai construir um aplicativo chamado SiteMonitor que amarra muitas das habilidades fundamentais de desenvolvimento de aplicativos dos capítulos anteriores e adiciona uma presença interativa na tela inicial. Colocando conteúdo diretamente na tela inicial do Android, você dá ao usuário o poder de alavancar completamente a plataforma criando ferramentas poderosas disponíveis para uso rápido e conveniente. Pense nisso — quando mais profundamente um usuário precisar ir a um aplicativo para encontrar informações relevantes, menos chance o aplicativo tem de se tornar de uso diário. O objetivo é criar uma experiência móvel que agrega valor sem se tornar um buraco negro de tempo e atenção, ou pior, um incômodo. Um ingrediente chave para alcançar esse objetivo é o uso efetivo do AppWidget. Este capítulo vai equipá-lo com conhecimento dos usos e da arquitetura dos AppWidgets. Ele caminha passo a passo através da criação de um aplicativo de exemplo AppWidget não trivial, incluindo tarefas importantes como configuração, dados e atualizações de GUI, e encerra com uma discussão sobre os elementos necessários dentro do arquivo AndroidManifest.xml do aplicativo.



Apresentando o AppWidget

475

17.1 Apresentando o AppWidget Quando o usuário pega um dispositivo Android (ou qualquer outro smartphone), sua primeira impressão é geralmente definida pela sua experiência de interagir com a tela inicial do telefone. Na tela inicial, o usuário interage com aplicativos, inicia uma chamada telefônica, pesquisa o dispositivo, inicia o navegador, etc. Quando o usuário começa a procurar um aplicativo no mar de ícones da janela inicial, certa porcentagem de usuários já vai estar perdida vai concluir que o dispositivo não é amigável. Isso pode ser comparado a enterrar conteúdo web importante muito profundamente em um site web — você precisa ter cuidado em não ocultar o valor dos seus aplicativos. Uma solução a esse desafio no Android é empregar um AppWidget.

17.1.1 O que é um AppWidget? Um AppWidget é um código que roda na tela inicial de um dispositivo Android. O tamanho visual de uma instância AppWidget pode variar e é designado pelo programador no momento do projeto. A tela inicial é dividida em 16 espaços utilizáveis, cada um com aproximadamente 74 pixels quadrados. Um AppWidget pode gerar uma área retangular de 1x1 a 4x4 espaços, supondo que exista espaço na página da tela inicial atual. (Um telefone típico tem de cinco a nove páginas na tela inicial). Um AppWidget é geralmente implementado como uma interface somente de leitura fornecendo uma view para os dados de aplicativo. A IU é implementada de modo similar ao layout de uma Activity Android tradicional. Ao contrário da Activity, o AppWidget é muito mais restrito, já que a única ação permitida é o clique. Um AppWidget não pode apresentar uma lista rolável, um EditText ou qualquer outro mecanismo de entrada do usuário além de algo que possa reagir a um clique. Quando alguma coisa diferente de um clique é necessária para a interação do usuário, é prudente carregar uma Activity para o trabalho pesado — o AppWidget não é projetado para interações de usuário significativas. Nesse caso, o AppWidget age como linha de frente para a Activ­ ity subjacente. Ele aceita um clique e então entrega o controle para o escritório central, implementado tipicamente por uma Activity. Apesar dessa aparente desvantagem, nem todos os AppWidgets requerem algo além de uma interface básica de usuário. Por exemplo, considere o Widget Power Control mostrado na Figura 17.1. O Widget Power Control é um excelente exemplo de simplicidade e valor. Esse widget é usado para habilitar e desabilitar diversos serviços de sistema como Bluetooth, Wi-Fi, GPS e outras funções que impactam as funções. Os serviços GPS drenam consideravelmente a bateria — o fato de que o Widget Power Control expõe esse recurso ligar/desligar com tanta facilida- Figura 17.1  Widget Power de torna o uso de serviços baseados em localização Control na tela inicial.

476

Capítulo 17 AppWidgets

ELSEVIER

uma opção mais realista para os usuários Android. Em outras plataformas de telefone, esse tipo de funcionalidade é geralmente oculto por trás de menus de sistema ou de opções. Você adiciona AppWidgets à tela inicial mantendo uma área vazia pressionada até que um menu seja iniciado, como mostrado na Figura 17.2. Nesse menu, selecione Widgets e os AppWidgets disponíveis são exibidos em uma lista rolável, como mostrado na Figura 17.3. Toque o widget desejado para adicionar uma instância à sua tela inicial. Um AppWidget roda sob outro aplicativo, Ap­ pWidgetHost, que geralmente é a tela inicial do dispositivo. O código de AppWidget é implementado em uma instância de um AppWidgetProvider, que é uma extensão da classe BroadcastReceiver. Como visto nos capítulos anteriores, um Broadcas­ Figura 17.2  tReceiver é definido como receptor do arquivo Adiciona à tela inicial. AndroidManifest.xml. O AppWidgetProvider é um BroadcastReceiver com um IntentFilter especial e um tag metadados que define as características do AppWidgetProvider. Um AppWidget pode ser implementado no código como um BroadcastReceiv­ er isolado, embora o AppWidgetProvider forneça algumas convenientes funcionalidades wrapper e é o meio recomendado de codificar um AppWidget. AppWidgets são projetados para serem atualizados periodicamente. A implementação padrão de um AppWidget é atualizada periodicamente nos intervalos definidos pelo desenvolvedor no momento do projeto. Em geral, essa atualização é programada para longos períodos para economizar bateria. Existem outros mecanismos para atualizar um AppWidget conforme necessário, por meio do uso de Intents. O Ap­ Figura 17.3  pWidgetProvider estende BroadcastReceiver e, Escolha um widget qualquer. portanto, pode receber diferentes Intent Actions baseados nos IntentFilters definidos. A prática comum é definir uma ação In­ tentFilter específica por aplicativo e usar o método sendBroadcast para disparar uma atualização AppWidget conforme necessário. Os detalhes do AppWidgetProvider, os metadados especiais no AndroidMani­ fest, IntentFilters, RemoteViews etc serão todos discutidos neste capítulo. Antes de entrarmos em detalhes sobre a construção de um AppWidget, vamos considerar os vários padrões de projeto que um AppWidget pode satisfazer.



Apresentando o AppWidget

477

17.1.2 Estratégias de implementação do AppWidget Na sua implementação mais básica, um AppWidget pode ser considerado uma espécie de painel de instrumentos. O Widget Power Control mostrado na Figura 17.1 é um bom exemplo desse tipo de App­ Widget. Esse AppWidget não está ligado a nenhuma outra interface de usuário e quaisquer ações tomadas invocam diretamente uma requisição para habilitar ou desabilitar um recurso de sistema. Em qualquer cenário normal, existe pelo menos um Widget Power Control implementado na tela principal. O usuário está livre para adicionar múltiplas cópias do Widget Power Control na sua tela principal, mas não há utilidade ou benefício adicional em fazer isso. Agora considere um AppWidget para Facebook ou Twitter, como mostrado na Figura 17.4. Algumas pessoas possuem múltiplas contas em redes sociais e podem desejar múltiplas instâncias aapWidgets Figura 17.4  para fazer atualizações em contas específicas. Nesse cenário, cada instância AppWidget é ligada ao seu próprio conjunto de dados. Para os objetivos deste capítulo, vamos chamar esses dados o modelo da instância AppWidget. Cada instância do AppWidget possui seu próprio conjunto de dados — que no caso de um widget de conta Twitter seriam informações nome de usuário/senha mais quaisquer dados no cache relacionados à conta específica. Mais à frente neste capítulo, vamos entrar em detalhes sobre como gerenciar esses dados “por widget”. O papel que um AppWidget pode interpretar é o de “atalho inteligente”. Ao invés de simplesmente exibir um atalho estático para um aplicativo, o AppWidget fornece um meio de exibir informações pertinentes e oportunas para o usuário. Quando clicado, o AppWidget carrega a Activity ou página web relevante. Considere, por exemplo, um widget de calendário que exibe os eventos na tela principal. Tocar o widget faz com que o aplicativo do calendário carregue, pulando para o evento de interesse. Devido à natureza variável da estratégia de implementação dos AppWidgets, é importante considerar como um AppWidget interage com os outros componentes baseados em Android. O que pode parecer como um simples aplicativo AppWidget pode de fato requerer a colaboração de diversos componentes. A Tabela 17.1 apresenta uma lista não exaustiva de opções de como um AppWidget pode interagir com outros componentes dentro de uma suíte de aplicativos. O que torna AppWidgets especificamente (e, no Android, geralmente) tão atraente para um desenvolvedor é a habilidade de distribuir código que forneça uma funcionalidade pequena e focalizada. Por exemplo, digamos que você tem uma grande ideia para tornar a interação com o calendário muito mais fácil: o “Killer Calendar App”. Em desenvolvimento móvel tradicional, implementar sua ideia iria

Capítulo 17 AppWidgets

478

ELSEVIER

Tabela 17.1  Diversos padrões de implementação de AppWidget Descrição AppWidget

standalone

AppWidget como

atalho inteligente

Componentes adicionais do aplicativo Único. Sem opções de configuração. Nenhuma Activity requerida. Pode usar um Service para processar uma requisição de longa duração em algumas implementações Usado para apresentar informações e carregar uma Activity com um clique.

AppWidget com

Confirmação necessária. Quantidade variável de dados associados com cada instância widget.

AppWidget com

Confirmação necessária. Quantidade variável de dados associados com cada widget. Service usado para atualizar dados. BroadcastReceiver usado para responder invocações de alarme ou outros gatilhos que informam atualizações em diversos momentos.

dados estáticos específicos

dados dinâmicos

Exemplo Power Control.

Widget de email mostrando o número de mensagens em uma caixa de entrada ou eventos em um calendário. Widget PictureFrame mostrando uma imagem selecionada pelo usuário da galeria. Widgets de aplicativos de notícias. O aplicativo de exemplo deste capítulo, SiteMonitor, demonstra esse padrão.

requerer substituir todo o aplicativo de calendário. Com a arquitetura Android, um desenvolvedor pode distribuir seu aplicativo simplesmente como um AppWidget que fornece uma interface melhor, sem ter que substituir as montanhas de trabalho já feitas nos aplicativos nativos! E mais, partes do seu código podem ser chamadas por aplicativos de terceiros, supondo que eles tenham as permissões apropriadas. Criar um AppWidget não é algo a ser considerado levianamente. Existem decisões a serem tomadas e armadilhas a evitar — e vamos cobrir tudo isso neste capítulo. Antes que mergulhemos nas águas da construção de seu próprio AppWidget, vamos dar um passo para trás e rever os objetivos de projeto do SiteMonitor, nosso aplicativo de exemplo deste capítulo que fornece o contexto para o aprendizado sobre AppWidgets.

17.2 Apresentando o SiteMonitor Para demonstrar o AppWidget, este capítulo apresenta um aplicativo chamado SiteMonitor. O SiteMonitor é um utilitário simples usado para monitorar aplicativos hospedados, como blogs, sites de comércio, etc. — aplicativos baseados na web.

17.2.1 Os benefícios do SiteMonitor A premissa do SiteMonitor é que um dispositivo Android é altamente conectado e muito capaz e, portanto, deve ser alavancado para fornecer mais valor para o usuário do que simplesmente funcionar como um dispositivo de email chique. Embora esse aplicativo possa não ser atraente para o mercado de consumidores de massa,



Apresentando o SiteMonitor

479

existe uma população considerável de indivíduos (empreendedores, administradores de sistemas, provedores de serviços, etc.) que tem interesse em manter um ou mais sites web em execução. As implicações de um site/aplicativo web hospedado não funcionar corretamente vão da irritação, à vergonha e à perda de rendimentos quando um site de comércio não está aceitando transações. Ser capaz de consultar uma coleção de ativos online em qualquer lugar dá poder ao usuário e pode até fazer com que coisas como um dia fora do escritório pareçam mais realistas. Dispositivos móveis hoje em dia se parecem com coleiras com correias longas — talvez esse aplicativo possa adicionar mais alguns metros à correia. É possível, claro, receber alertas SMS ou emails quando um site não está mais disponível com ferramentas do lado do servidor e serviços de terceiros — o que é bom e aplicável em diversas instâncias. Mas tenha em mente que o SiteMonitor trabalha totalmente sem integração do lado do servidor, outro recurso desejável que está de acordo com as tendências dos aplicativos móveis de hoje. O SiteMonitor é um AppWidget projetado para atingir o objetivo de monitorar a saúde de um site web. Vamos começar com a experiência de alto nível do usuário.

17.2.2 A experiência do usuário Hoje é possível verificar sites web com um dispositivo Android — é só colocar um marcador em algumas URLs de aplicativo no navegador WebKit e verificá-los. E então verificá-los de novo. E de novo. Você entendeu. É desejável ter alguma assistência automatizada para essa tarefa básica e repetitiva. A resposta lógica é codificar um aplicativo para fazer isso para você. Nesse caso, o SiteMonitor emprega um Ap­ pWidget para trazer informações úteis diretamente para a tela principal do telefone. Vamos examinar a interface de usuário. A Figura 17.5 mostra a tela principal de um dispositivo Android com quatro instâncias do widget SiteMonitor para monitorar quatro aplicativos diferentes. A IU é declaradamente sem brilho, mas a informação é precisamente o que precisamos nessa situação. Em uma olhada rápida, você pode ver que, dos quatro sites monitorados, três estão funcionando (verde) e um está em condição de erro (vermelho). Você pode ver o nome de cada site e a hora/data da atualização mais recente. Tocar nas instâncias do widget SiteMonitor traz uma Activity onde você pode ver informações detalhadas sobre o site. Os dados específicos do widget incluem não só valores de configuração do aplicativo hospedado, mas também os dados mais recentes recuperados do aplicativo hospedado. Por exemplo, você pode ver na Figura 17.5  Quatro instâncias Figura 17.6 que esse site, chamado “chap 17”, possui do AppWidget SiteMonitor na um alerta de pouco espaço de disco. tela principal.

480

Capítulo 17 AppWidgets

ELSEVIER

O aplicativo pode facilmente suportar múltiplas condições. Por hora, vamos manter as coisas simples com as condições bom e ruim. Sites em boa condição são mostrados em verde e os em má condição em vermelho. Ainda em relação à Figura 17.6, note que a tela possui suporta para manter três campos diferentes, cada um implementado como um controle Edit­ Text. A primeira instância EditText gerencia o nome do site. O espaço é limitado ao widget, então é melhor manter o comprimento desse campo limitado. Note que o widget pode ser expandido para utilizar mais espaço e, portanto, permite nomes mais descritivos, e a maioria dos usuários podem usar um descritor simples como nome de servidor ou apelido do cliente. Mais importante, você quer ajustar diversas instâncias do widget SiteMonitor na tela princi- Figura 17.6  pal, então elas não devem usar mais do que o espaço Detalhes do site, incluindo texto com links ativos. absolutamente necessário. O próximo campo EditText contém a URL que o aplicativo periodicamente envia para verificar o status do site. Quando é hora de atualizar o status de um aplicativo hospedado em particular, o SiteMonitor executa um GET HTTP contra essa URL e espera uma string de retorno delimitada pelo canal. Por exemplo, uma resposta de um site de comércio pode se parecer com o seguinte: GOOD|There are 10 orders today, totaling $1,000.00

Ou talvez um site que esteja fora do ar tenha uma resposta que se parece com isso: BAD|Cannot reach payment processor. Contact fakepaymentprocessor.com at 555-123-4567

O terceiro campo EditText armazena a página principal do site. Quando o botão Visit Site é clicado, o aplicativo abre um navegador e navega para essa URL. Por que esse recurso é incluído? A resposta é simples: a reação mais comum ao recebimento de uma notificação “o site está fora do ar” é verificar o site em primeira mão para ver que tipos de erro podem estar ocorrendo com os visitantes do site. Essa abordagem é muito mais fácil do que iniciar o navegador e digitar uma URL completa — especialmente sobre pressão! Referindo-se novamente à Figura  17.6, note o número de telefone destacado contendo o campo TextView. Selecionar esse link faz com que o telefone inicie o discador como mostrado na Figura  17.7. Esse TextView tem o atributo autoLink habilitado. Quando esse habilitado está habilitado, o aplicativo está requisitando que o Android examine a informação textual e tente utilizar quaisquer dados que se pareçam com um link para um hotspot clicável. O Android pode opcionalmente buscar sites web, endereços de email, números de telefone, etc. Esse recurso é mais



Apresentando o SiteMonitor

481

um passo para tornar as coisas o mais simples possível para um usuário móvel suportar um aplicativo hospedado. Digamos que o usuário tenha saído para jantar e esteja equipado somente com um dispositivo Android quando um site cai ou experimenta uma condição urgente. Pode não ser conveniente ou factível procurar informações de suporte detalhadas sobre um aplicativo hospedado em particular, especialmente se esse site for um entre muitos. Quando uma condição de erro é observada, é útil ter dados chave acionáveis na ponta dos seus dedos. Isso é semelhante a uma situação “quebre o vidro em caso de emergência”. Uma emergência ocorreu, então vamos nos preparar o melhor possível. O aplicativo não se limita a dar más notícias — é factível fazer o aplicativo monitorar também boas Figura 17.7  notícias. Por exemplo, a Figura  17.8 mostra que o Discagem simples para um site Acme recebeu mais de US$1.000 em negócios usuário afetado. hoje! Note os números destacados: um dos efeitos colaterais da autovinculação é que algumas vezes ela retorna falsos positivos. O aplicativo SiteMonitor é centrado em AppWid­ gets. Embora você possa configurar e examinar diversos aspectos de um site específico através da configuração Activity, não há outros meios de interagir com o aplicativo. Esse aplicativo não aparece na tela principal. Como consequência natural de confiar somente em instâncias de AppWidget para a IU, o número de sites monitorados pelo SiteMonitor é limitado pela quantidade de espaço disponível na qual as instâncias de SiteMonitor podem ser colocadas. Lembre-se de manter o projeto de um AppWid­ get o mais conservador possível no que diz respeito ao espaço da tela. É impossível ter um AppWidget que utilize menos de um dos 16 espaços disponíveis em uma página principal, mas é fácil ter um maior que um espaço 1x1. Figura 17.8  Tenha em mente que a escolha de tornar Site- Monitora também as boas notíMonitor disponível somente como um AppWidget é cias – lucros! um projeto arbitrário para demonstrar o funcionamento de um AppWidget. Uma extensão simples desse aplicativo poderia remover essa limitação intencional. Para adicionar esse aplicativo à tela principal, você pode adicionar uma Activity que apresenta cada um dos sites monitorados e, então, adicionar a Activity à tela principal.

482

Capítulo 17 AppWidgets

ELSEVIER

Agora que você tem um entendimento básico do que o SiteMonitor está tentando fazer, é hora de ver como o aplicativo é construído.

17.3 Arquitetura do aplicativo SiteMonitor Vamos começar com um exame de alto nível da arquitetura e, então, nos aprofundar para que você entenda cada aspecto principal do aplicativo SiteMonitor. Alguns dos exemplos de código são fornecidos neste capítulo de modo abreviado devido ao seu tamanho. Encorajamos você a fazer o download do projeto completo para visualizar o código à medida que percorre o capítulo. Vamos começar com uma representação pictórica do aplicativo.

17.3.1 Visão panorâmica do aplicativo O aplicativo SiteMonitor depende de diversos componentes de aplicativo Android para entregar a funcionalidade desejada. A Figura 17.9 mostra os principais componentes do aplicativo. Examinando em mais detalhes os elementos mostrados na Figura 17.9, você vê um dispositivo Android q hospedando diversas instâncias de AppWidgets w. Nesse diagrama, cada um dos quatro AppWidgets representa uma instância de SiteMoni­ torWidget. Essa classe AppWidget é implementada na classe chamada SiteMoni­ torWidgetImpl que estende uma classe fornecida pelo Android chamada AppWid­ getProvider. Cada instância do widget SiteMonitor é configurada pelo usuário para monitorar um aplicativo/site web hospedado distinto na coleção de sites e. A relação entre uma instância de widget específica e seus dados são armazenados no armazenamento permanente SharedPreferences  r do aplicativo. A classe SiteMoni­ torModel fornece métodos para gerenciar e manipular essas instâncias de modelos de dados. Uma Activity  t é empregada para permitir ao usuário configurar os dados da instância do widget. Essa Activity é implementada como a classe Site­ MonitorConfigure. Toda vez que um novo widget SiteMonitor é adicionado à tela principal, a Activ­ ity SiteMonitorConfigure é invocada para pesquisar dados específicos de site do usuário: nome, URL, home page. Essa inicialização automática de uma Activity acontece graças a uma relação especial entre uma classe AppWidget e sua activity de configuração. Essa relação é definida no arquivo de meta dados  s. Os metadados são referenciados pela entrada da classe SiteMonitorWidgetImpl do arquivo de manifesto a. Note que a prática de ter uma Activity de configuração para um AppWidget é opcional. Quando uma instância do widget SiteMonitor é adicionada ou removida, um método correspondente da classe SiteMonitorWidgetImpl é invocado. Os métodos específicos dessa classe são descritos na Seção 17.3.2. A classe AppWidgetManager fornecida pelo Android  y age como um auxiliar para fornecer uma lista de identificadores AppWidget relacionados à classe SiteMonitorWidgetImpl. Nesse ponto, existem diversas instâncias de widget na tela principal, atualizando sua exibição de acordo com a configuração de intervalo de atualização definido no arquivo de meta dados s.



483

Arquitetura do aplicativo SiteMonitor

D

S2 S1

S4

I

SiteMonitorService (Service)

S3

SiteMonitorBootstrap (BroadcastReceiver)

H

C

W1

W2

W3

W4

1) AndroidManifest. xml

Shared Preferences

J

E

SiteMonitorWidgetimpl Instances

Alarm

Meta-data

1!

Home Screen

B

G AppWidgetManager (Android class)

F SiteMonitorConfigure (Activity)

Figura 17.9  Diagrama arquitetural do aplicativo SiteMonitor.

Como mencionado antes, é prática comum realizar uma atualização do App­ Widget fora do intervalo de atualização normalmente definido. Essa atualização é geralmente realizada por meio do uso de um Service, geralmente disparado por um Alarm. Não é prática recomentada ter Services de longa duração em segundo plano, então você usa o método de empregar um Alarm  i que propaga um PendingIntent. PendingIntent contém um Intent recebido pela classe SiteMonitorBootstraps i. Essa classe também contém métodos estáticos para gerenciar o alarme, chamado em diversos pontos do aplicativo, cada um dos quais será discutido mais à frente neste capítulo. Considere a condição onde não existem instâncias de widgets SiteMonitor na tela principal. Se não houverem aplicativos hospedados no monitor, não é necessário ter um alarme periódico ativado. Do mesmo modo, quando um widget SiteMonitor é adicionado à tela principal, é desejável que um alarme seja configurado para que o widget seja atualizado periodicamente. A relação entre a Intent Action disparada pelo alarme e consumida pela classe SiteMonitorBootstrap é definida pelo manifesto a. O campo Action do Intent configurado no PendingIntent do Alarm corresponde a IntentFilter Action do SiteMonitorBootstrap.

Quando o SiteMonitorBootstrap i recebe o Intent no seu método onReceive, o passo necessário é o início do SiteMonitorService u. O SiteMonitorService é responsável por executar as atualizações e verificar os aplicativos hospedados.

Capítulo 17 AppWidgets

484

ELSEVIER

Quando iniciado, o SiteMonitorService itera pelos widgets disponíveis, novamente graças à assistência do AppWidgetManager y, que fornece uma lista de widgets. Para cada instância de widget ativo, o Service extrai a URL do aplicativo hospedado e executa um GET HTTP para recuperar a informação de status mais atualizada. O modelo de dados de cada AppWidget ativo é atualizado com as informações recuperadas do aplicativo hospedado. Quando todos os dados do site foram atualizados, o Service envia uma transmissão Intent, solicitando efetivamente à classe Site­ MonitorWidgetImpl que atualize o status visual dos próprios widgets. Como você pode ver, existem algumas peças móveis nesse aplicativo AppWid­ get protótipo. Pode ser útil voltar a esta seção conforme você considera cada uma das descrições de código subsequentes. Vamos fazer um tour pelos arquivos do projeto.

17.3.2 Arquivo por arquivo Veremos os trechos de código em breve, mas primeiro vamos ver o projeto no nível mais alto, discutindo o objetivo de cada arquivo significativo do projeto. A Figura 17.10 mostra o projeto no Eclipse IDE e a Tabela 17.2 fornece um breve comentário de cada arquivo.

Figura 17.10  SiteMonitorWidget no Eclipse.

Tabela 17.2  Lista de arquivos desse projeto Nome do arquivo AndroidManifest.xml sitemonitorwidget.xml SiteMonitorWidgetImpl.java SiteMonitorConfigure.java SiteMonitorModel.java SiteMonitorService.java

SiteMonitorBootstrap.java

Comentário Contém definições de cada componente Application do aplicativo em conjunto com IntentFilters e permissões necessárias. Define atributos específicos AppWidgetProvider, incluindo dimensões, activity de configuração, ícone e layout inicial de IU. Contém a implementação de AppWidgetProvider. Contém a Activity usada para manipular os dados de uma entrada específica e visualizar dados recebidos de um aplicativo hospedado remotamente. Contém os métodos para gerenciar as SharedPreferences que armazenam elementos de dados específicos do widget. Service responsável por realizar o monitoramento real de sites remotos. Comunicações de rede têm lugar em um thread de segundo plano. Contém códigos relativos ao gerenciamento de alarmes e é responsável por disparar SiteMonitorService sob diversas condições, incluindo disparar alarmes.



Gerenciamento de dados de AppWidget

Nome do arquivo

485

Comentário

monitor.xml

Define os elementos de interface de usuário usados por AppWidget na tela principal.

main.xml

Define os elementos de interface de usuário usados na Activity SiteMonitorConfigure.

strings.xml

Contém strings externalizadas, útil para gerenciamento fácil de dados textuais para localização potencial.

Com esse entendimento fundamental de como as várias partes se relacionam umas às outras, é hora de começar a examinar o código por trás desse aplicativo. Embora possa ser tentador pular para a implementação de AppWidgetProvider, precisamos primeiro ver o código que gerencia os dados específicos de AppWidget.

17.4 Gerenciamento de dados de AppWidget Como mencionado antes, cada instância de AppWidget possui um identificador numérico único representado por uma primitiva do tipo inteiro (int). Sempre que o aplicativo é solicitado a trabalhar com um AppWidget, o valor desse identificador está disponível para o código. Às vezes, ele é fornecido, como em um bundle extra de um Intent. Em outras circunstâncias, uma coleção de identificadores widget é recuperada de AppWidgetManager como um array de inteiros (int []). Independente da fonte, gerenciar a relação entre esse identificador e os dados específicos à instância de AppWidget definido por seus próprios aplicativos é crucial para o sucesso. Para o monitor SiteMonitor, todo o gerenciamento de dados é feito pela classe SiteMonitorModel, contida no arquivo fonte SiteMonitorModel.java. Essa classe pode ser separada em duas seções lógicas: os dados de instância e métodos e o método estático. A parte da instância da classe inclui diversas variáveis String, seus respectivos métodos getter e setter e métodos úteis para montar e desmontar bundles. O método de armazenamento permanente de dados é o SharedPreferences do aplicativo, que apresentamos no Capítulo 5. Para manter as coisas simples, todos os elementos de dados são armazenados como java.lang.String. Quando o “registro” completo precisa ser armazenado, os elementos de dados são combinados em uma String composta delimitada. Quando os dados são lidos de SharedPref­ erences, a String recuperada é analisada e armazenada em membros respectivos baseados na posição ordinal na string. Embora essa abordagem seja talvez primária, é perfeitamente adequada pera nossos objetivos. Alternativamente, poderíamos ter empregado um banco de dados SQLite ou construído nosso próprio ContentPro­ vider, mas esses dois mecanismos são demais para nosso objetivo atual. Um Con­ tentProvider geralmente somente se justifica se os dados precisarem ser armazenados com componentes fora de uma única suíte de aplicativos. Os elementos de dados gerenciados por cada AppWidget incluem: ¡ Nome do site. ¡ URL de atualização do site. ¡ URL da página inicial do site.

Capítulo 17 AppWidgets

486

ELSEVIER

¡ Status. ¡ Data do último status. ¡ Mensagem/comentários.

A classe também inclui quatro métodos estáticos usados como métodos auxiliares para manipular instâncias de dados de widget por meio do aplicativo. Três desses métodos são relacionados à persistência dos dados de SiteMonitorModel, e um quarto fornece a formatação da data. Esse método de formatação da data foi incluído para ajudar a padronizar e centralizar a representação de strings Date. A listagem a seguir apresenta a implementação da classe SiteMonitorModel, menos alguns setter/getters, que são omitidos aqui, mas estão incluídos na listagem do código-fonte completo disponível para download. Listagem 17.1  Classe SiteMonitorModel package com.msi.unlockingandroid.sitemonitor; import import import import

java.text.SimpleDateFormat; android.content.Context; android.content.SharedPreferences; android.util.Log;



as q Contém constantes para

persistência de SharedPreferences

public class SiteMonitorModel { private static final String tag = "SiteMonitorModel";

private static final String PREFS_NAME "com.msi.unlockingandroid.SiteMonitor"; private static final String PREFS_PREFIX = "sitemonitor_"; private String name; private String url; private String homepageUrl; Contém elementos private String status; de dados dos private String statusDate; widgets private String message;

w

public SiteMonitorModel(String name,String url,String homepageUrl, String status,String statusDate,String message) { Define o this.name = name; construtor this.url = url; this.homepageUrl = homepageUrl; this.status = status; this.statusDate = statusDate; this.message = message; } Define construtor/ parser public SiteMonitorModel(String instring) { Log.i(SiteMonitorModel.tag,"SiteMonitorModel(" + instring + ")"); String[] data = instring.split("[|]"); if (data.length == 6) { this.name = data[0]; this.url = data[1]; this.homepageUrl = data[2]; this.status = data[3]; this.statusDate = data[4]; this.message = data[5]; } else {

r

e



487

Gerenciamento de dados de AppWidget this.name = "?"; this.url = "?"; this.homepageUrl = "?"; this.status = "WARNING"; this.statusDate = java.util.Calendar.getInstance().getTime().toString(); this.message = ""; } } public String getName() { return this.name; } public void setName(String name) { this.name = name; }

t Define getter/setter

// veja o código-fonte completo para os métodos getter/setter restantes Prepara os dados public String storageString() { para armazenamento return this.name + "|" + this.url + "|" + this.homepageUrl + "|" + this.status + "|" + this.statusDate + "|" + message; }

y

public String toString() { return this.storageString();

Redefine

}

u toString()

Salva dados de widget public static void saveWidgetData(Context context,int widgetId,SiteMonitorModel model) { Log.i(SiteMonitorModel.tag,"saveWidgetData(" + widgetId + "," + model.storageString() + ")"); SharedPreferences.Editor prefsEditor = context.getSharedPreferences(PREFS_NAME, 0).edit(); prefsEditor.putString(PREFS_PREFIX + widgetId,model.storageString()); prefsEditor.commit(); } public static SiteMonitorModel Recupera getWidgetData(Context context,int widget) { dados do Log.i(SiteMonitorModel.tag,"getWidgetData(" + widget + ")"); widget

i

o

SharedPreferences prefs = context.getSharedPreferences (PREFS_NAME, 0); String ret = prefs.getString(PREFS_PREFIX + widget,"BAD"); if (ret.equals("BAD")) return null; Remove dados do return new SiteMonitorModel(ret); Retorna instância de de widget } SiteMonitorModel

1)

public static void deleteWidgetData(Context context,int widgetId) { Log.i(SiteMonitorModel.tag,"deleteWidgetData(" + widgetId + ")"); SharedPreferences.Editor prefsEditor = context.getSharedPreferences(PREFS_NAME, 0).edit(); prefsEditor.remove(PREFS_PREFIX + widgetId); prefsEditor.commit(); } public static String getFormattedDate() { Formata data SimpleDateFormat sdf = new SimpleDateFormat do status ("MMM dd HH:mm"); return sdf.format(java.util.Calendar.getInstance().getTime()); } }

1@

1!

488

Capítulo 17 AppWidgets

ELSEVIER

A classe SiteMonitorModel atende aos requerimentos de gerenciamento de dados do AppWidget SiteMonitor. O método de persistência de dados é o aplicativo Shared­ Preferences e, assim, alguns valores de String constantes são empregados q para identificar os dados SharedPreferences. Cada elemento de dados é definido como uma variável membro String  w. Dois construtores diferentes são empregados. O primeiro construtor e é para criar uma nova instância de valores String distintos e o segundo construtor r é usado para analisar dados para um widget existente que foi recuperado de um SharedPreference. Somente um dos métodos getter/setter t é mostrado nessa listagem, mas todos empregam o mesmo bean padrão básico. Quando preparamos os dados para serem armazenados em SharedPreferences, os dados de instância do widget são reduzidos a uma única String delimitada com a assistência do método storageString y. O método toString() u é sobrescrito e invoca o método storageString. Armazenamento, recuperação e exclusão de dados são feitos em métodos definidos estaticamente. O método saveWidgetData i armazena os dados do widget com uma chave de NAME + widgetIdentifier. Isso significa que os dados de um widget com um ID de 200 seria assim: sitemonitor_200 = "sitename|url|homepageurl|status|statusDate|message"

Para mais detalhes sobre como usar SharedPreferences, veja o Capítulo 5. Dados de widget são recuperados de SharedPreferences no método getWid­ getData  i. Esse método retorna um SiteMonitorModel  a empregando a versão de análise do construtor. Quando um widget é removido do dispositivo, excluímos os dados associados com uma chamada para deleteWidgetData() s. Por fim, o método deleteWidget()  d. é responsável por formatar uma string java.util.Date em uma representação String com o auxílio de uma classe Sim­ pleDataFormat. Nesse ponto você deve ter uma boa ideia de como os dados são gerenciados e onde ficam. Agora vamos fazer o código implementar de verdade um AppWidget!

17.5 Implementando o AppWidgetProvider O AppWidgetProvider para o aplicativo SiteMonitor é implementado no arquivo SiteMonitorWidgetImpl.java. O AppWidgetProvider é responsável por realizar atualizações na IU, além de responder a eventos de manutenção relacionados ao ciclo de vida do AppWidget,e é talvez o aspecto mais importante que devemos entender sobre a programação de um AppWidget. Devido à sua centralidade e importância no trabalho com AppWidgets,vamos examinar o código de duas perspectivas.

17.5.1 Inventário do método AppWidgetProvider Os métodos apresentados na Tabela 17.3 representam a funcionalidade básica de AppWidgetProvider. Embora esses métodos sejam comuns aos AppWidgetProvid­ ers, os comentários são feitos no contexto do aplicativo SiteMonitor. Além disso, os dois métodos finais (marcados com *) são exclusivos do aplicativo SiteMonitor.



Implementando o AppWidgetProvider

489

Tabela 17.3  Inventário dos métodos AppWidgetProvider Nome do método

Comentário

onReceive

Esse é o mesmo método encontrado em todas as classes BroadcastReceiver. Ele é usado para detectar requisições ad hoc, que ele então entrega para o método onUpdate.

onUpdate

Esse método é responsável por atualizar uma ou mais instâncias de widgets. Esse método recebe um array de identificadores widget a ser atualizado.

onDeleted

Esse método é invocado quando um ou mais widgets são excluídos. Como o método onUpdate, esse método recebe um array de identificadores widget — nesse caso, cada um desses widgets foi excluído. Esse método é responsável por limpar quaisquer dados armazenados em uma base “por widget”.

onEnabled

Esse método é invocado quando a primeira instância de AppWidget é colocada na tela principal. Em Site monitor esse método inicia uma sequência de Alarmes, que forçam a atualização a intervalos específicos como definido dentro da classe SiteMonitorBootstrap.

onDisabled

Esse método é invocado quando a última instância de AppWidget é removida da tela principal. Quando não existem instâncias do widget SiteMonitor, não é necessário atualizá-las. Portanto o alarme é limpo. Esse método não é chamado com confiabilidade quando você pensa que deveria.

*UpdateOneWidget

Esse método estático é responsável por atualizar um widget específico. Uma vez que existem diversos cenários para interação com AppWidgets na nossa classe, ele é desejável para consolidar todas as UIs de widget, impactando o código de um método único.

*checkForZombies

O subsistema AppWidget tem o péssimo hábito de deixar widgets para trás sem um meio efetivo de limpá-los sem reiniciar o aparelho. Consequentemente, nossa instância AppWidgetProvider está sendo sempre solicitada a realizar operações em widgets que não existem mais. Esse método é usado como um helper para o método onDisabled. Sempre que o método onDelete é invocado, chame esse método para realizar um passo adicional de limpeza. Quando nenhum widget legítimo é detectado, limpa o alarme de atualização, realizando o trabalho que o método onDisabled não realiza com confiabilidade.

Agora você sabe quais são os nomes dos métodos e as responsabilidades de cada um. É hora de examinar o código. Vamos começar com a implementação de um Ap­ pWidgetProvider conforme examinamos SiteMonitorWidgetImpl.

17.5.2 Implementando SiteMonitorWidgetImpl Existe muito código para examinar nessa classe, então, vamos dividi-lo em algumas seções. Na Listagem 17.2, você pode ver os callbacks básicos ou ganchos que respondem aos eventos AppWidget. Como você sabe, cada widget do sistema possui um identificador do tipo inteiro. Quando estiver trabalhando com AppWidgets, é comum manipular um array desses identificadores, como mostrado nas listagens seguintes, então fique de olho nesses identificadores quando revisar o código.

Capítulo 17 AppWidgets

490

ELSEVIER

Listagem 17.2  SiteMonitorWidgetImpl, que implementa a funcionalidade AppWidget package com.msi.unlockingandroid.sitemonitor; import import import import import import import import import import

android.content.Context; android.content.ComponentName; android.content.Intent; android.app.PendingIntent; android.appwidget.AppWidgetProvider; android.appwidget.AppWidgetManager; android.widget.RemoteViews; android.net.Uri; android.util.Log; android.graphics.Color;

q

Importa o AppWidget

public class SiteMonitorWidgetImpl extends AppWidgetProvider { private static final String tag = "SiteMonitor"; String usada public static final String UPDATE_WIDGETS = para atualizações "com.msi.unlockingandroid.sitemonitor.UPDATE_WIDGETS";

w

@Override public void onUpdate(Context context,AppWidgetManager appWidgetManager,int[] appWidgetIds ) { super.onUpdate(context, appWidgetManager, appWidgetIds); Método onUpdate int count = appWidgetIds.length; Log.i(SiteMonitorWidgetImpl.tag,"onUpdate::" + count); // podemos ter múltiplas instâncias desse widget... // ... garanta que todas foram consideradas for (int i=0;i