Comment obtenir le contexte dans le ViewModel MVVM d'Android ?

Question

J'essaie de mettre en œuvre le modèle MVVM dans mon application Android. J'ai lu que les ViewModels ne devraient pas contenir de code spécifique à Android (pour faciliter les tests), mais j'ai besoin d'utiliser le contexte pour diverses choses (obtenir des ressources à partir de xml, initialiser les préférences, etc). Quelle est la meilleure façon de faire cela ? J'ai vu que AndroidViewModel contient une référence au contexte de l'application, mais comme il contient du code spécifique à Android, je ne suis pas sûr qu'il doive se trouver dans le ViewModel. Ces éléments sont également liés aux événements du cycle de vie de l'activité, mais j'utilise Dagger pour gérer la portée des composants, donc je ne suis pas sûr que cela ait une incidence. Je suis novice en matière de modèle MVVM et de Dagger, alors toute aide est la bienvenue !

Answer 1

Pour les composants de l'architecture Android Modèle de vue,

Ce n'est pas une bonne pratique de passer votre contexte d'activité au ViewModel de l'activité car cela entraîne une fuite de mémoire.

Par conséquent, pour obtenir le contexte dans votre ViewModel, la classe ViewModel devrait étendre la classe Modèle de vue Android La classe. De cette façon, vous pouvez obtenir le contexte comme indiqué dans l'exemple de code ci-dessous.

class ActivityViewModel(application: Application) : AndroidViewModel(application) {

    private val context = getApplication<Application>().applicationContext

    //... ViewModel methods 

}

Answer 2

Vous pouvez utiliser un Application qui est fourni par le AndroidViewModel vous devez étendre AndroidViewModel qui est simplement un ViewModel qui comprend un Application référence.

Answer 3

Ce n'est pas que les ViewModels ne doivent pas contenir de code spécifique à Android pour faciliter les tests, puisque c'est l'abstraction qui facilite les tests.

La raison pour laquelle les ViewModels ne doivent pas contenir une instance de Context ou quoi que ce soit d'autre comme des Views ou d'autres objets qui s'accrochent à un Context est qu'ils ont un cycle de vie distinct de celui des Activities et des Fragments.

Ce que je veux dire par là, c'est que, disons que vous faites un changement de rotation sur votre application. Cela entraîne la destruction de votre activité et de votre fragment, qui se recrée alors. Le ViewModel est censé persister pendant cet état, il y a donc des chances que des crashs et d'autres exceptions se produisent s'il tient toujours une vue ou un contexte de l'activité détruite.

Quant à la façon de faire ce que vous voulez faire, MVVM et ViewModel fonctionnent très bien avec le composant Databinding de JetPack. Pour la plupart des choses que vous stockez typiquement un String, int, ou etc pour, vous pouvez utiliser Databinding pour faire les vues l'afficher directement, donc pas besoin de stocker la valeur dans ViewModel.

Mais si vous ne voulez pas de liaison de données, vous pouvez toujours passer le contexte dans le constructeur ou les méthodes pour accéder aux ressources. Mais ne gardez pas une instance de ce contexte dans votre ViewModel.

Answer 4

Ce que j'ai fini par faire, c'est qu'au lieu d'avoir un contexte directement dans le ViewModel, j'ai créé des classes de fournisseurs telles que ResourceProvider qui me donneraient les ressources dont j'ai besoin, et j'ai injecté ces classes de fournisseurs dans mon ViewModel.

Answer 5

Réponse courte - Ne faites pas ça

Pourquoi ?

Cela va à l'encontre de l'objectif des modèles de vue

Presque tout ce que vous pouvez faire dans le modèle de vue peut être fait dans l'activité/fragment en utilisant des instances LiveData et diverses autres approches recommandées.