Pular para o conteúdo principal

Entendendo uma aplicação para Android

No post passado, o objetivo era apresentar aos que não conheciam, ou esclarecer melhor aos que sabiam pouco, a respeito da plataforma do Google para smartphones (e agora também para tablets), o Android. E antes de começarmos a falar diretamente de código, temos que entender como uma aplicação é estruturada e falar do que podemos chamar de os quatro pilares de uma aplicação para o Android.

Os quatro pilares
Uma aplicação Android se baseia em quatro tipos de classes principais: Activities, services, broadcast receivers e content providers. Cada um desses tipos representa uma forma de interação que sua aplicação irá ter com o usuário, plataforma ou com outras aplicações. Elas podem coexistir em uma única aplicação ou também podem existir separadamente. Mas, vamos entender isso melhor discutindo cada tipo.

Activities
As classes responsáveis pela interação visual da aplicação com o usuário são as que extendem de Activity. Essas classes irão apresentar menus, listas, formulários ou qualquer outra interação que você deseje fazer através das "telas" da sua aplicação. Uma classe Activity é composta por um ou vários objetos do tipo View, que pode ser um texto, uma imagem, um botão ou qualquer outro elemento de interação com o usuário.
Sua aplicação poderá ter uma ou várias activities, tudo isso depende de como você irá fazer o design de navegação. E além disso, sua aplicação pode não ter nenhuma Activity, isso pode acontecer se ela for um serviço, como veremos abaixo.

Services
Uma classe Service não tem interação visual com o usuário, mas ele tem a característica de executar em background tarefas por tempo indefinido. Como por exemplo, tocar uma música ou buscar alguma atualização na Internet.
Esses serviços podem se comunicar com outros serviços, inclusive do sistema operacional, e também fazer a chamada de aplicações, postar notificações e qualquer outro tipo de operação que uma aplicação normal faria.

Broadcast Receivers
Os broadcast receivers são componentes que não "fazem nada" a não ser receber e reagir aos broadcasts que são enviados, inclusive pelo sistema, como por exemplo: mudança no fuso-horário, bateria fraca, uma foto foi tirada ou que algum valor nas configurações foi alterado. Além disso, uma aplicação também pode emitir algo através de broadcast e esperar que um destes recebedores faça o devido tratamento.

Content Providers
Através dos Content Providers é possível tornar disponível um conjunto de dados de sua aplicação através de SQLite ou outra forma que você deseje.

A arquitetura de uma aplicação Android (simplificada)
Então, caso você deseje fazer uma aplicação que possua diversas telas (o que o mais normal) você sempre usará activities para fazer essa interação. Além disso, pode também ter serviços que rodam em background e trazendo notificações ao usuário ou emitem "broadcasts" que são interceptados pelos broadcast receivers.

No próximo post, vamos fazer um primeiro exemplo, demonstrando como criar o projeto no Eclipse, criar sua primeira Activity e configurar o manifest.xml que irá fazer com que o seu aplicativo funcione de forma correta. E de quebra, vamos ver como funciona o processo de publicação de uma aplicação no Market.

Vem mais por ai!

Abraços
Neto

Comentários

tmoreira2020 disse…
Este comentário foi removido pelo autor.
tmoreira2020 disse…
Dae Neto! Ótimo post, especialmente para quem está querendo ampliar os conhecimentos no mundo mobile! Ficarei na espera da continuação ou das continuações!

Um abraço

Postagens mais visitadas deste blog

10 reasons why we love JSF

1. One-slide technology: it's so simple that I can explain basic JSF with one slide. 2. Easy to extend: components, listeners, render kit, Events, Controller, etc. 3. Real-world adoption: JBoss, Exadel, Oracle, IBM, ... 4. Architecture model: you can choose between more than 100 different architecture. 5. Open-mind community: using JSF you are going to meet very interesting people. 6. We are using JSF the last 5 years and we found very good market for JSF in Brazil 7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard! 8. Many professionals now available 9. It's a standard. It's JCP. Before complain, report and help! 10. Ed Burns, spec leader, is an old Globalcode community friend! EXTRA: My wife is specialist in JSF. She's my F1 for JSF :) Nice job JSF community! -Vinicius Senger

Spring Brasil User Group nasceu saudável em 2010

O Spring Brasil User Group nasceu forte e saudável junto com o ano novo e, com menos de um mês de vida, já conta com mais de 100 membros. Venha participar também desta comunidade! Se ainda não é um membro, clique aqui !. Este grupo é uma rede social dedicada a fortalecer e fomentar a comunidade de usuários e desenvolvedores das tecnologias relacionadas ao Spring Framework . Fórum, Blog, Notícias e Chat <=> Comunidade O Spring Brasil User Group , carinhosamente apelidado de SBUG, está baseado na infraestrutura do site de redes sociais chamado Ning e, por isso, disponibiliza os mecanismos de fórum, blog, publicação de fotos e vídeos, divulgação de eventos e troca de mensagens entre os integrantes do grupo. Portanto, esta rede social permitirá a todos os participantes enviar dúvidas ou abrir discussões através do fórum, escrever notícias ou mini-tutoriais sobre Spring no blog e acompanhar as novidades e possíveis reuniões virtuais ou presenciais do grupo. De maneira tímida...

Desenvolvimento Softwares Vs. Construção Civil

Eu sei que a metáfora da construção civil tem sido utilizada para referenciar modelos mais rígidos, porém, analisando de um novo ponto de vista, o de um pedreiro, eu vejo uma analogia interessante.  Já são conhecidas as inúmeras comparações entre "engenharia" de software e engenharia civil: pilares da arquitetura Java EE, diagramas como planta e código como a casa construida, a função de arquiteto, engenheiro e a famosa frase que o programador é o pedreiro do software... Tudo isso nos perseguiu muito nos últimos 20 anos e muitos dos profissionais de T.I. não gostam dessas comparações. O fato é que influenciado por tais comparações, há exatamente 9 anos atraz quando tinhamos uma equipe enxuta e dinâmica de desenvolvimento, eu costumava dizer: "Vamos fazer uma imersão em uma obra e entender quais são as razões de uma casa ser levantada aparentemente com menor esforço organizacional e corportativo que um software". Nunca fizemos. Porém refletindo recentemente ach...

Devo fazer um curso ou ler um livro?

Acredito que todos os instrutores ou professores, independentemente da área, escola ou centro de treinamento, já devam ter recebido essa pergunta alguma vez na vida: devo fazer um curso ou ler um livro? Para responder a essa pergunta, precisamos avaliar os prós e contras de cada opção. Trabalho com treinamento há algum tempo e, hoje, recebi essa pergunta de um aluno. Não adianta responder a ou b sem argumentar, demonstrando as opções conforme a situação do aluno. O conteúdo, a forma de transmissão e a capacidade de assimilação do indivíduo são chaves para haver benefício maior de aprendizado. Tanto em um bom curso quanto em um bom livro, o conteúdo é a premissa básica . Por conteúdo entendemos: se está organizado; se respeita pré-requisitos; se promove o aprendizado guiado e incremental; se aborda de forma satisfatória os principais pontos; se tem bom balanço entre teoria, exemplos e prática (favorecendo exemplos e prática); se tem como premissa a acessibilidade possível (e cabível) pa...

Appengine e os períodos de manutenção

Uma das funcionalidades do Google AppEngine(GAE) que eu acho mais fantásticas -principalmente para nós desenvolvedores-, é a possibilidade de deixar sua aplicação preparada para momentos em que haverá alguma manutenção nos servidores do GAE ou mesmo uma 'queda' inesperada de um serviço. Isso fizemos também no site da YaW . Qualquer serviço web, por mais que esteja disponível 24/7/365 em algum momento deverá sofrer uma paralisação seja por uma manutenção, atualização ou qualquer problema imprevisto. Com o GAE não é diferente, a grande vantagem é que o próprio ambiente lhe avisa destes momentos, sendo que você pode deixar sua aplicação já pronta para continuar funcionando(mesmo que não 100%) durante estes períodos. A camada de persistência(Datastore) por exemplo, em períodos de manutenção, entra em um estado especial em que somente é possível realizar leituras na base(read-only), nenhuma modificação ou alteração na base é permitida. Nestes períodos, se a aplicação realizar alguma...

1o. Concurso para alunos Globalcode - Google App Engine

Estava conversando com o Rafael Nunes , um dos fundadores da YAW , Unidade Globalcode São Bernardo do Campo , autor do Hands-on Google App Engine , sobre prática, motivação e tendências, e a conversa terminou em uma criação a quatro mãos do 1o. Concurso para alunos Globalcode com o tema Desenvolvimento na Nuvem utilizando a plataforma de Cloud Computing da Google, o Google App Engine! O 1o. Concurso é restrito aos alunos da Globlacode para motivar os alunos a participarem, pois é natural que sintam insegurança ao participar de uma competição usando uma tecnologia na qual eles não estão familiarizados. Ao receber os trabalhos a Comissão Julgadora poderá escolher novas categorias, mas inicialmente haverão as seguintes categorias: - O melhor site estático : Sites pessoais, "hot sites", mashups e agregadores de conteúdo. - Aplicações dinâmicas : Acesso ao banco de dados, Web Porque participar ?  Se você fez ou está fazendo um treinamento provavelmente tem objetivos pro...