ViewModel Android, Como Utilizar Este Componente de Arquitetura
- 3. Separação de conceitos ‣ Importante para qualquer software; ‣ Simplifica o processo de testes; ‣ Facilita a evolução do software; ‣ Padrões de arquitetura foram feitos para permitir a eficiente separação de conceitos. Exemplos: ‣ MVC; ‣ MVP; ‣ MVVM.
- 4. Componentes de arquitetura Android ‣ APIs nativas que permitem a separação de conceitos com, ou sem, um padrão de arquitetura sendo aplicado; ‣ Entidades adicionadas a partir da versão 26 do Android, Oreo; ‣ Na documentação oficial, Junto as APIs, foi divulgado também um modelo de arquitetura que deve atender a maioria dos domínios de problemas de aplicativos desta plataforma; ‣ As APIs de arquitetura vieram para acrescentar e não para substituir os padrões de arquitetura já conhecidos.
- 5. Componentes de arquitetura Android ‣ Lifecycle: ‣ Para dar, às classes de domínio, a propriedade de ter conhecimento sobre o ciclo de vida de algum componente importante sem necessidade de utilizar os métodos de ciclo de vida deste componente. ‣ LiveData: ‣ Permite o uso simples do react, ou observer, no projeto, evitando o uso de APIs terceiras e maior dependência entre as camadas da arquitetura em uso. ‣ ViewModel: ‣ Representante da camada de negócio, responsável por realizar as invocações as camadas inferiores e entregar os dados corretos a camada superior, está última: a camada de visualização, Activity ou Fragment. ‣ Room: ‣ Facilita o trabalho com a camada de modelo, persistência de dados via SQLite, provendo uma interface mais simples.
- 6. Arquitetura recomendada ‣ Para a maioria dos domínios de problemas de aplicativos Android; ‣ Não deve prevalecer sobre uma arquitetura eficiente já em uso; ‣ As classes de domínio que precisão ter seus dados refletidos na camada de visualização, estão vinculadas ao LiveData.
- 8. Características gerais ‣ Principal entidade da camada de lógica de negócio da arquitetura recomendada; ‣ Objetos ViewModel funcionam vinculados a algum escopo: Activity ou Fragment; ‣ Objetos ViewModel mantém os dados em memória enquanto, por exemplo, há uma reconstrução da entidade vinculada; ‣ Em relação as APIs concorrentes: o ViewModel é mais simples e fácil de, respectivamente, vincular e utilizar.
- 9. Referência Gradle App Level ‣ Pacote android.arch; ‣ Na documentação não há definição de API mínima para uso, logo, podemos assumir a API 10,Android Gingerbread, ainda em mercado, sendo a mínima; ‣ Utilize a referência 'android.arch.lifecycle:runtime' somente se a API de suporte em uso for menor do que a versão 26.1; ‣ Referenciando somente o ViewModel no build.gradle (Module: app): 'android.arch.lifecycle:extensions'.
- 10. Codificação ‣ Apesar de não estar explícito na documentação, nas classes ViewModel têm de haver um construtor vazio, sem parâmetros; ‣ ViewModelProviders é a classe utilitária que provê o ViewModel solicitado. O ViewModel é criado caso já não esteja em memória; ‣ of() pode receber um objeto Activity ou um Fragment; ‣ Objetos ViewModel nunca devem ter referência a algum objeto da camada de visualização (Activity e Fragment, por exemplo), isso para evitar vazamento de memória.
- 11. Ciclo de vida ‣ Possibilidade de vinculo somente ao escopo de Activity ou Fragment; ‣ O objeto ViewModel somente é removido da memória quando o componente vinculado é destruído permanentemente; ‣ A remoção total do ViewModel somente ocorre quando a entidade vinculada passa pelo onDestroy() / onDetach() e o sistema sabe que não foi uma reconstrução e sim uma finalização definitiva. Caso contrário o novo objeto, Activity ou Fragment, têm o ViewModel vinculado a ele. Escopo de um objeto ViewModel vinculado a uma atividade
- 12. Comunicação entre fragmentos ‣ Outra característica de destaque da API, sendo uma melhor escolha, para comunicação, ante a: ‣ Bundle; ‣ EventBus; ‣ LocalBroadcastManager. ‣ Fragmentos não sabem da existência um do outro; ‣ O escopo da atividade é que deve ser utilizado para permitir a comunicação.
- 13. vs SavedInstanceState ViewModel SavedInstanceState Durabilidade dos dados em memória Menor Maior Quantidade de dados (bytes) em memória Maior Menor Auxílio de Interface para serialização e desserialização de objetos Não Sim ‣ Não há uma melhor do que a outra, há o contexto certo para cada API.
- 14. Com as novas APIs de componentes de arquitetura o desenvolvimento de aplicativos Android mais robustos, ao menos na estrutura, tende a se tornar algo comum. Sem receios é possível dizer que a luta entre quais APIs, externas, MVP ou MVVM utilizar tende a diminuir, pois agora temos APIs nativas que podem trabalhar junto a aplicação de qualquer padrão de arquitetura. O ViewModel é robusto mesmo quando não tendo algum LiveData sendo utilizado. Logo, vale o estudo se realmente é viável manter o Parcelable e cia. quando somente um ViewModel poderia reter, pelo ciclo necessário, os dados em memória. Sempre assegure-se de não referenciar no ViewModel alguma entidade de origem na camada de visualização, pois está API será retida em memória em alguns momentos onde uma atividade, ou fragmento, não será, e precisará ser removida para a construção uma nova atividade, ou fragmento. Conclusão
- 15. Fontes Conteúdo completo, em texto e em vídeo, no link a seguir: ‣ https://www.thiengo.com.br/viewmodel-android-como-utilizar-este-componente-de-arquitetura Fontes: ‣ https://developer.android.com/topic/libraries/architecture/guide.html ‣ https://developer.android.com/topic/libraries/architecture/adding-components.html ‣ https://developer.android.com/topic/libraries/architecture/lifecycle.html ‣ https://developer.android.com/topic/libraries/architecture/livedata.html ‣ https://developer.android.com/reference/android/arch/lifecycle/ViewModel.html ‣ https://developer.android.com/topic/libraries/architecture/viewmodel.html
- 16. ViewModel Componente de Arquitetura Android thiengo.com.br Vinícius Thiengo thiengocalopsita@gmail.com