Desenvolvendo para Android

Dividindo responsabilidades da melhor forma

About Me

Marcos Paulo DamascenoSoftware Developer @NavitaTecnologia

Formado em Desenvolvimento de Software pelo IFCE

Cearense de língua presa, amante de música, do trabalho e das pessoas.

Quero desenvolver para android o/

Java

ActivityContext

ListView Adapters

Intents

Ciclo de Vida

Geolocalização

Content Provider

Services

GPS

Network

Android Manifest

MotivaçõesOi, como vai a sua arquitetura?

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.

Então o que devo utilizar?

Simples, vou usar o MVC, claro.

MVC é pros fracos, eu sou Hippie, vou usar MVP

MVCOnde está o Controller?

É óbvio meu caro

Activities são os controllers

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

Mas, será que realmente devemos considerar activities controllers?

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.

....Sim, tudo bem se você trabalha com sua activity como

se ele fosse um controller único.

Mas sua activity pode acabar assim.

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

Você tem probleminha....

Brincadeira... não é regra.... Sabemos que quantidade não é qualidade...

Em nada desse mundo... seja pra mais ou seja pra menos....

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.

ActivitiesDevem acessar os objetos do xml. No onCreate instanciar o controller. E nos

listeners chamar métodos específicos do controller.

ControllerDeve 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.

View Objects??? WTF O.o

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

O que fariamos normalmente?

Show me the code

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.

Usando View Objects

Show me the code

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.

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.

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?

Desenvolver Software Mobile é coisa séria!!!!

Vamos abrir nossa mentes e fazer apps pra android com qualidade ;)

Let’s Talk NowQuestions?

Doubts?

Opnions?

Do you disagree with me? It’s ur turn. Talk!!