MVVM_ Implementando o padrão de projeto MVVM com Android Binding Saiba como criar um projeto utilizando o padrão de projeto MVVM no Android O padrão de projeto MVVM O MVVM (Model-View-ViewModel) foi divulgado pela primeira vez em 2005 por John Gossman, na época arquiteto da plataforma Silverlight da Microsoft em seu blog. O mesmo se baseou fortemente no padrão de projeto Presentation Model (muito semelhante ao MVP Model-View-Presenter), divulgado por Martin Fowler em 2004. Verifique o diagrama do padrão MVVM na figura 1. Abaixo o papel de cada camada do MVVM: View: a representação visual de elementos e ações que farão a interface com o usuário. ViewModel: uma classe responsável por conter o binding (ligação) com os elementos da View. A descrição real é que a mesma se trata do modelo da tela, representando o estado atual da mesma. Model: referente a um modelo de domínio, representando o estado atual do mesmo. O grande diferencial que o MVVM adotou e que o destaca de outros padrões de projeto conhecidos como o MVC, é sua capacidade de separar a camada de apresentação (View) da lógica de apresentação (ViewModel), facilitando a aplicação de testes unitários na ViewModel. A ViewModel cria seu próprio modelo de representação da View, acabando com os acessos diretos à camada Model. As camadas acabam ficando menos acopladas, facilitando a manutenção. Quando proporcionamos a separação das camadas, podemos separar as responsabilidades no desenvolvimento de sistemas, assim decentralizamos as tarefas. Nesse modelo, as interfaces podem ser criadas por designers e o código por programadores. Graças a sua flexibilidade, o padrão MVVM foi facilmente adaptado às plataformas modernas baseadas no modelo Event-Driven-Developer, como WPF (Windows Presentation Foundation), Silverligh e Android. View Figura 1. Diagrama do padrão de projeto MVVM. ViewModel Model / 50
Giuliano Bem Hur Firmino giulianofirmino@yahoo.com.br Especialista em Engenharia de Software pelo Instituto da Computação da Unicamp e certificado pela Sun (SCJP). Atua na área de desenvolvimento de softwares há 11 anos. Com a plataforma JAVA nos ambientes Web, Mobile e Enterprise. Em um tempo que os principais requisitos são o desenvolvimento de softwares de forma cada vez mais rápida e produtiva e que ainda sejam confiáveis e fáceis de manter, possuir uma boa plataforma de projeto é um diferencial. Apesar do Android prover certas facilidades para o desenvolvedor, nativamente não disponibiliza algumas implementações como padrão de projeto MVVM, basicamente responsável por simplificar a amarração entre design e código, presente em outras plataformas como a Silverlight da Microsoft. Para que possamos adaptar o Android na utilização deste padrão, temos que nos utilizar de frameworks que no caso deste artigo será o Android Binding. Padrões de apresentação Abaixo, poderemos verificar os principais padrões de projeto voltados à apresentação utilizados no mercado e quais as diferenças comparados ao MVVM. MVVM x MVC (Model-View-Controller) O MVC é um padrão de projeto criado em 1979 por Trygve Reenskaug, inicialmente desenvolvido para Smaltalk. O mesmo surgiu com objetivo de melhorar a organização do projeto, separando acesso aos dados, regras de negócios e lógica de apresentação. Atualmente o mesmo é considerado uma arquitetura padrão no desenvolvimento de software. Confira o seu diagrama na figura 2. O MVC se diferencia do MVVM, por conta do livre acesso da View a camada Model, o que o torna fortemente acoplado. MVVM x MVP (Model-View-Presenter) O MVP foi criado originalmente em 1990 pela Taligent, uma parceira da Apple, IBM e HP. É um padrão de projeto que facilita a automação de testes unitários e separação de conceitos na camada de apresentação. Confira o seu diagrama na figura 3. O MVP se diferencia do MVVM, por conta da presença da interface que representa a View. Podemos por exemplo desenvolver uma tela em swing e outra em Android e utilizar o mesmo Presenter, bastando implementar a Interface que representa a View, nas diferentes plataformas. Isso não acontece no MVVM, pois o mesmo é amarrado à plataforma/framework. Observer De acordo com a definição GoF, seu objetivo é Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente. Você pode observar o seu funcionamento no diagrama da figura 4. MVVM x MVP x MVC View Controller View Presenter Model Figura 2. Diagrama do padrão de projeto MVC. Figura 3. Diagrama do padrão de projeto MVP. Model 51 \
<<interface>> Observer + notify() <<interface>> Observable + addobserver(observer) + notifyobservers() O projeto de exemplo Para exemplificar a utilização do padrão de projeto MVVM e algumas das funcionalidades presentes no framework AndroidBinding, vamos criar uma aplicação completa na plataforma Android. Você ainda poderá conferir este projeto na íntegra, baixando o código-fonte do mesmo, no site da revista. Essa aplicação é responsável por armazenar listas de compras. Esse sistema é formado por três telas, conforme descrito abaixo. Tela inicial: contendo todas as listas de compras e os botões para Criar, Editar e Apagar uma lista, conforme mostrado na figura 5. Ao iniciar a tela, o sistema exibe todas as listas de compras cadastradas no banco de dados. Ao clicar em Criar, o sistema irá abrir a tela de edição de lista de compras, com uma nova lista. Clicando em Editar, o sistema irá carregar a tela de edição de lista de compras, com a lista selecionada, o botão apagar exclui a lista de compras do Observerlmpl1 Observablelmpl Observerlmpl2 Figura 4. Diagrama do padrão de projeto Observer. Acoplamento entre View e Model Reutilização do código para N Views Parceria com o padrão Observer MVVM Não Não Sim MVP Não Sim Sim MVC Sim Não Não Sobre o Android Binding Android Binding é um framework open-source desenvolvido para a plataforma Android que provê de maneira simples, binding de componentes visuais contidos em arquivos XML. Sua arquitetura foi criada principalmente para ajudar no desenvolvimento de aplicações utilizando o padrão de projeto MVVM. Para se desenvolver aplicações visuais para Android, são necessários classes do tipo Activity, essas classes na arquitetura padrão, detêm muita das responsabilidades do sistema, como controlar o fluxo da aplicação, entradas dos usuários, comunicação com a camada de negócio, entre outros. Ao utilizar o Android Binding a responsabilidade das classes Activity, são reduzidas a amarrar as camadas View e ViewModel, separando as tarefas e simplificando ainda mais o desenvolvimento para Android. Figura 5. Tela inicial. banco de dados. Tela de edição da Lista de Compras: contendo o nome, lista de itens da compra, totalizador da compra e os botões de Adicionar, Editar e Excluir itens e Salvar e Cancelar as alterações da lista de compras. Conforme mostrado na figura 6. Ao clicar no botão adicionar o sistema abrirá a tela de edição de item da lista de compras, com um item novo. Clicando em Editar, o sistema irá carregar a tela de edição de item da lista de compras, com o item selecionado. O botão Excluir irá excluir o item em cache da lista. Só quando o usuário clicar em Salvar, a lista será incluída/alterada e seus respectivos itens serão todos excluídos do banco e adicionados novamente (isso facilita o processo, uma vez que teríamos que verificar item a item, se o mesmo, deve ser incluído, alterado ou excluído do banco de dados). Se o botão Cancelar for clicado, simplesmente o sistema ignora as alterações retornando a tela principal. Tela de edição do Item da Lista de Compras: / 52
botão Salvar irá incluir o item no cache da lista e fará o sistema retornar a tela da Lista de Compras. Ao clicar em Cancelar o sistema ignora as alterações retornando a tela da Lista de Compras. Veja o diagrama desse pequeno, mas funcional sistema na figura 8. Um detalhe peculiar de implementação do MVVM para a plataforma Android é a representação da camada View através de xmls. A View main_view. xml representa a tela inicial da aplicação, compra_ view.xml representa a tela de edição das Listas de Compras e item_compra_view.xml representa a tela de edição do Item da Lista de Compras. Podemos observar que para cada View existe um respectivo ViewModel, isso ocorre porque cada tela possui um modelo específico de informações e ações. Já a camada Model, responsável por encapsular o domínio do projeto, está representada por duas classes, CompraModel e ItemCompraModel. Pré-requisitos Plugin do eclipse ADT SDK do Android com a versão 2.1 Figura 6. Tela de edição da Lista de Compras. Preparação do ambiente Fazer checkout da última versão do projeto Android Binding, utilizando para isso uma ferramenta cliente de SVN: http://android-binding. googlecode.com/svn. Criar um novo workspace. Importar o projeto AndroidBinding para o workspace. Criando o projeto Clique no menu File, selecione New e clique em Other. Abra a aba Android e selecione Android Project. Clique no botão Next. Em Project Name, digite ListaCompra. Clique no botão Next. main_view.xml compra_view.xml Item_compra_view.xml MailViewModel CompraViewModel ItemCompraViewModel Figura 7. Tela de edição do Item da Lista de Compras. contendo nome, quantidade, valor unitário e valor total e os botões Salvar e Cancelar as alterações do item de compra. Conforme mostrado na figura 7, o CompraModel Figura 8. Diagrama do projeto Lista de Compra. ItemCompraModel 53 \
Selecione a versão do SDK a ser utilizada, no nosso caso a 2.1. Clique no botão Next. Em Package Name, digite android.compra. Clique no botão Finish. Após criar o projeto, acesse suas propriedades. Clique com o botão direito sobre o projeto e clique em Properties. Selecione a aba Android, na caixa Library clique em Add. Selecione o projeto AndroidBinding e clique em ok. Codificando Ciclo de vida do Android Binding O Android Binding tem seu próprio ciclo de vida e para o iniciarmos, devemos chamar o método init da classe Binder antes de começarmos a utilizar qualquer recurso deste framework. Essa inicialização deve ser feita logo que a aplicação seja iniciada. Para isso devemos implementar o método oncreate da classe Application (observe na Listagem 1 a classe que estende Application). Nativamente o android amarra as XMLs às classes Activity, para que possamos prover um binding entre a camada View (XMLs) e a camada ViewModel, as classes Activity deverão estender BindingActivity herdando o método setandbindrootview que deve ser chamado no evento oncreate preparando a funcionalidade para trabalhar no padrão MVVM (conforme podemos ver nas Listagens 3, 4 e 5). Na figura 9 podemos visualizar todo o ciclo de vida do Android Binding e na Listagem 2, como ficou o arquivo AndroidManifest.xml com a classe Application e as classes Activity configuradas. View bind Activity <<framework>> Android Biding ViewModel init Application Listagem 1. Inicializando o ciclo de vida do Android Binding. public class MainApplication extends Application { public void oncreate() { super.oncreate(); Binder.init(this); Listagem 2. AndroidManifest.xml configurado com as classes Activity. <?xml version= 1.0 encoding= utf-8?> <manifest xmlns:android= http://schemas.android.com/ apk/res/android package= android.compra android:versioncode= 1 android:versionname= 1.0 > <uses-sdk android:minsdkversion= 7 /> <application android:icon= @drawable/ic_launcher android:label= @string/app_name android:name= MainApplication > <activity android:name= MainActivity android:label= @string/app_name android:nohistory= true > <intent-filter> <action android:name= android.intent.action.main /> <category android:name= android.intent.category.launcher /> </intent-filter> </activity> <activity android:name= CompraActivity android:label= @string/lista_compras android:nohistory= true ></activity> <activity android:name= ItemCompraActivity android:label= @string/item_lista_compra android:nohistory= true ></activity> </application> </manifest> Figura 9. Diagrama do fluxo de uso do Android Binding. / 54
Listagem 3. Classe MainActivity. public class MainActivity extends BindingActivity { public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); this.setandbindrootview(r.layout.main_view, new MainViewModel(this)); Listagem 4. Classe CompraActivity. public class CompraActivity extends BindingActivity { public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); this.setandbindrootview(r.layout.compra_view, new CompraViewModel(this, model)); Listagem 5. Classe ItemCompraActivity. public class ItemCompraActivity extends BindingActivity { public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); this.setandbindrootview( R.layout.item_compra_view, new ItemCompraViewModel(this, model)); Criando os arquivos de layout (Views) O próximo passo será criarmos as Views que são simplesmente layouts XML padrão do Android, com a adição do schema do Android Binding xmlns:binding= http://www.gueei.com/android- -binding/ que será responsável por marcar os elementos visuais que serão amarrados com a ViewModel. Na Listagem 6 é exibido um dos arquivos, mais especificamente a tela de edição da lista de compras. Note que só são mostradas as principais propriedades do schema do Android Binding, binding:text, binding:onclick, binding:itemsource e binding:itemtemplate, no próximo tópico os mesmos serão explicados com mais detalhes. Listagem 6. Tela de edição da lista de compras, arquivo compra_view.xml. <?xml version= 1.0 encoding= utf-8?> <LinearLayout xmlns:android= http://schemas.android. com/ apk/res/android xmlns:binding= http://www.gueei.com/ android-binding/...> <TextView... android:text= Nome /> <EditText... binding:text= nome > <requestfocus /> </EditText> <TextView... android:text= Itens /> <ListView... binding:itemsource= lista binding:itemtemplate= @layout/lista_item_compra /> <TextView... binding:text= total /> <LinearLayout... android:orientation= vertical > <LinearLayout...> <Button... binding:onclick= adicionar /> <Button... binding:onclick= editar /> <Button... binding:onclick= excluir /> <LinearLayout...> <Button... binding:onclick= salvar /> <Button... binding:onclick= cancelar /> Implementando os arquivos ViewModel Agora devemos criar os respectivos modelos das views anteriores. Esses atuam através de classes normais, pertencentes à camada VIewModel. Nas Listagens 7 e 8 podemos observar alguns dos principais recursos do Android Binding que irá nos auxiliar a implementarmos o padrão de projeto MVVM, iremos estudar cada um deles. StringObservable: refere à propriedade binding:text da View. Este recurso se trata de um observador (implementação do padrão de projeto Observer), cujo o papel é amarrar um valor String a um elemento do tipo EditText. A alteração do conteúdo de objetos desta classe é refletida na tela. DependentObservable: também referente à propriedade binding:text da View. A diferença é 55 \
que o mesmo é acionado caso o valor de um ou mais campos seja alterado. Muito utilizado em campos calculados, como é o caso do campo total, da tela de edição de item da lista de compra que é a multiplicação entre quantidade e valor unitário. ArrayListObservable: refere à propriedade binding:itemsource da View. Este recurso também se trata de um observador, cujo papel é amarrar uma lista ao elemento do tipo ListView. As alterações das informações presentes nos objetos desta lista são refletidas na tela. Command: são ações que no caso do nosso exemplo são acionadas através das propriedades binding:onclick. ArrayListItem: se trata de uma Inner Class (seguindo o padrão do ViewModel) criada para representar uma template do elemento visual ListView, referente à propriedade binding:itemtemplate. Estes templates são arquivos do tipo layout XML que representam os elementos que serão exibidos em cada linha do elemento ListView. Na Listagem 9 note que este arquivo de template adota o mesmo padrão das Views exibidas anteriormente, somente com uma diferença, como representam uma linha, podemos ter propriedades como binding:onclick no elemento LinerLayout, acionando os comandos presentes na Classe ArrayListItem. O Android Binding apresenta ainda mais recursos que não serão discutidos neste artigo. Exemplos completos de utilização destes recursos podem ser obtidos na documentação presente no site do projeto (veja link nas referências, no final do artigo). Listagem 7. Classe CompraViewModel. private CompraModel model; private ArrayListItem itemselecionado; public StringObservable nome = new StringObservable(); public StringObservable total = new StringObservable(); public final ArrayListObservable<ArrayListItem> lista = new ArrayListObservable<ArrayListItem>( ArrayListItem.class); public Command adicionar = new Command(){ ; public Command editar = new Command(){ ; public Command excluir = new Command(){ //... ; public Command salvar = new Command(){ ; public Command cancelar = new Command(){ ; public class ArrayListItem { Listagem 8. Classe ItemCompraViewModel. public class ItemCompraViewModel { private ItemCompraModel model; public StringObservable nome = new StringObservable(); public StringObservable quantidade = new StringObservable(); public StringObservable valorunitario = new StringObservable(); public final DependentObservable<String> total = new DependentObservable<String>( String.class, quantidade, valorunitario){ public String calculatevalue(object... arg0) throws Exception { ; public Command salvar = new Command(){ ; public Command cancelar = new Command(){ voltarcompraview(); ; / 56
Listagem 9. Template da ListView da tela inicial do sistema. / referências <?xml version= 1.0 encoding= utf-8?> <LinearLayout xmlns:android= http://schemas.android. com/apk/res/ android xmlns:binding= http://www.gueei.com/android-binding/ android:layout_width= fill_parent android:layout_height= fill_parent android:orientation= horizontal binding:onclick= selecionar > Site oficial do Android Binding: http://code.google.com/p/ android-binding/ Artigo original de John Gossman sobre MVVM: http://blogs.msdn.com/b/johngossman/ archive/2005/10/08/478683.aspx Artigo original de Martin Fowler sobre Presentation Model: http://martinfowler.com/eaadev/ PresentationModel.html <TextView android:layout_width= 240dip android:layout_height= 22dip android:textsize= 20dip android:gravity= left binding:text= nome /> <TextView android:layout_width= 80dip android:layout_height= 22dip android:textsize= 20dip android:gravity= right binding:text= total /> Implementando os arquivos Model Por último, iremos implementar as classes referentes à camada de domínio (Model). Na Listagem 10 é exibida uma das classes de domínio do sistema. Como o foco do artigo não é sobre acesso a banco de dados, não detalharemos a fundo estas classes, ficando somente a dica que estas, além de deterem o estado dos domínios, também são responsáveis por executar regras de negócios, presentes no nosso exemplo, em métodos como incluir, alterar e excluir. Outro detalhe é que estas classes estendem Serializable, pois o Android serializa objetos complexos, ao serem passados como parâmetro de um Activity para outro. Veja um exemplo na Listagem 10. Listagem 10. Classe CompraModel. public class CompraModel implements Serializable { private Long codigo; private String nome; private List<ItemCompraModel> itens; public CompraModel() { this.itens = new ArrayList<ItemCompraModel>(); // Métodos gets e sets public Double gettotal() { Double total = 0.00; for (ItemCompraModel item : itens) { total += item.gettotal(); return total; public static List<CompraModel> obtertodas() {/* Acesso ao banco de dados */ public static CompraModel obterporcodigo( Long codigo) {/* Acesso ao banco de dados */ public void incluir() {/* Acesso ao banco de dados */ public void alterar() {/* Acesso ao banco de dados */ public void excluir() {/* Acesso ao banco de dados */ Considerações finais Foram apresentados os principais conceitos no desenvolvimento de aplicações utilizando-se o padrão de projeto MVVM, com a ajuda do framework Android Binding. Pudemos observar que esse padrão de projeto simplifica muito o desenvolvimento, separando as camadas e facilitando a criação de testes. Por se tratar de um projeto relativamente novo, o Android Binding tem uma pequena defasagem de documentação a qual pode ser encontrada de forma simplificada em http://code.google.com/p/android-binding/wiki/, mas por ser tratar de um projeto open-source o mesmo pode ser explorado com facilidade. 57 \