Presentation made in 2011 about Development Patterns in Android at The Developer's Conference 2011.

1. Desenvolvendo para
Android
Dividindo responsabilidades da melhor forma

2. About Me
Marcos Paulo Damasceno
Software Developer @NavitaTecnologia
Formado em Desenvolvimento de Software pelo IFCE
Cearense de língua presa, amante de música,
do trabalho e das pessoas.

3. Quero desenvolver para android o/
Activity GPS
Context
Intents Services
Java Geolocalização
ListView Adapters
Ciclo de Vida Android Manifest
Network Content Provider

4. Oi, como vai a sua arquitetura?
Motivações
Problemas pra diminuir o acoplamento
entre tela e regras de negócio.
Activities estavam ficando megazords.
Adapters estavam fazendo muitas formatações de
valores pra exibir na tela, que não eram aproveitáveis.
Código difícil e chato de testar
Aplicação frágil
Falta de padrão bem
definido na comunidade.

5. Então o que devo utilizar?
Simples, vou usar o MVC, claro.
MVC é pros fracos, eu sou
Hippie, vou usar MVP

6. MVC
Onde está o Controller?

7. É óbvio meu caro
Activities são
os controllers

8. Controller
O controlador (controller) recebe a entrada de dados e
inicia a resposta ao utilizador
ao invocar objetos do modelo, e por fim uma visão
baseada na entrada. Ele também é responsável pela
validação e filtragem da entrada de dados.
Wikipedia

9. Mas, será que realmente devemos
considerar activities controllers?

10. Responsabilidades
das Activities
Capturar os componentes do
xml e colocar em objetos.
Certas responsabilidade de
criação de tela, como por
exemplo criação OptionsMenu,
ContextMenu e etc.
Responsabilidades de troca de
tela e chamada de intents.

11. ....
Sim, tudo bem se você trabalha com sua activity como
se ele fosse um controller único.
Mas sua activity pode
acabar assim.

12. Se você acha que ter mais de 300 linhas de código na
sua activity é normal e aceitável.
Você tem probleminha....

13. Brincadeira... não é regra.... Sabemos que
quantidade não é qualidade...
Em nada desse mundo...
seja pra mais ou seja pra menos....

14. Mas se podemos dividir responsabilidades e melhorar o
nosso código, devemos fazê-lo.
Pra isso, criamos mais uma camada,
entre a nossa regra de negócio, e as
activities.... camada que chamaremos
de.... Controllers.

15. Activities
Devem acessar os objetos do xml. No
onCreate instanciar o controller. E nos
listeners chamar métodos específicos do
controller.
Controller
Deve chamar as regras de negócio, obter a
resposta e transformar ela em ViewObjects
para retorná-los para as activities.
ViewObjects
Responsável por conter os dados como
devem ser exibidos em tela, já tratados.
Criado de acordo com componentes.

16. View Objects??? WTF O.o

17. Imagine a seguinte situação:
Aplicativo de monitoramento de
ligações e planos de voz.
Com a seguinte tela.
Ao carregar o aplicativo, um ListView
aparece e mostra minutos utilizados
e a porcentagem de utilização

18. O que fariamos normalmente?
Show me the code

19. O problema dessa abordagem é que:
Se por acaso um dia mudarmos a
forma como os dados são enviados,
devemos modificar a lógica do
Adapter.
Veja que o adapter ficou cheio de
lógica desnecessária e ele está bem
acoplado.

20. Usando View Objects
Show me the code

21. Analisando
A ideia é que o VO tenha mais do que dados, mas
também parâmetros como cores do progress bar
de acordo com a porcentagem utilizado.
Dessa forma nosso Adapter tem a única
responsabilidade de setar os dados nos
componentes da row. A lógica de exibição fica toda
centralizada. Se algo mudar no modelo que vem do
server, nosso adapter continua intacto.

22. Veja que...
Claro que isso não é regra, se sua listview tem
diferentes rows de acordo com dados a serem
exibidos inevitavelmente ela terá alguma lógica.
Dependendo do projeto criar view objects pode
ser trabalhoso e demorado, tem que analisar bem
tudo e trabalhar da melhor forma possível.
Também é válido criar uma Activity abstrata pra obrigar
implementação de métodos para «atachar» os
componentes de xml com suas respectivas Actions e
também para carregar os componentes do XML. Ou
mesmo para manter códigos reaprovetáveis como
funcionamento da action bar.

23. Arre Égua, qual o objetivo da palestra então?
É dizer sim, a arquitetura do projeto importa, não é
porque é um projeto para um dispositivo móvel que
deve ser desenvolvido como vem na telha.
Estratégias devem ser analisadas, design patterns
devem ser utilizados.
Com o sucesso dos tablets a qualquer momento você
pode precisar pegar aquela sua aplicação pra
smartphone e ter que torná-la universal para tablets.
E aí José? O que você vai fazer? Criar um novo
projeto só pra tablets e copiar e colar códigos
reaprovetáveis?
Refatorar o código que tá todo amarrado?

24. Desenvolver Software Mobile é coisa séria!!!!
Vamos abrir nossa mentes e fazer apps pra android com qualidade ;)

25. Let’s Talk Now Doubts?
Questions?
Opnions?
Do you disagree with me? It’s ur turn. Talk!!