Arquitetura no Android, realmente importa? - TDC 2011
Upcoming SlideShare
Loading in...5
×
 

Arquitetura no Android, realmente importa? - TDC 2011

on

  • 987 views

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

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

Statistics

Views

Total Views
987
Views on SlideShare
978
Embed Views
9

Actions

Likes
2
Downloads
13
Comments
0

1 Embed 9

http://www.linkedin.com 9

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Arquitetura no Android, realmente importa? - TDC 2011 Arquitetura no Android, realmente importa? - TDC 2011 Presentation Transcript

  • Desenvolvendo para AndroidDividindo responsabilidades da melhor forma
  • About Me Marcos Paulo Damasceno Software Developer @NavitaTecnologiaFormado 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/ Activity GPS Context Intents Services Java Geolocalização ListView Adapters Ciclo de Vida Android Manifest Network Content Provider
  • 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 devalores 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 caroActivities sãoos controllers
  • ControllerO controlador (controller) recebe a entrada de dados e inicia a resposta ao utilizador ao invocar objetos do modelo, e por fim uma visãobaseada na entrada. Ele também é responsável pela validação e filtragem da entrada de dados. Wikipedia
  • Mas, será que realmente devemosconsiderar activities controllers?
  • Responsabilidades das Activities Capturar os componentes do xml e colocar em objetos. Certas responsabilidade de criação de tela, como porexemplo 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 asactivities.... camada que chamaremos de.... Controllers.
  • 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.
  • 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 ListViewaparece 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 aforma 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
  • AnalisandoA ideia é que o VO tenha mais do que dados, mastambé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 temdiferentes rows de acordo com dados a seremexibidos 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 prasmartphone 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 Now Doubts? Questions? Opnions?Do you disagree with me? It’s ur turn. Talk!!