Utilisation d’Android Jetpack ViewModel – Développement de logiciels
Fondamentalement, ViewModel fait partie des composants d’architecture Android. L’un des principaux objectifs de l’objet ViewModel est de servir des données aux composants de l’interface utilisateur Android, tels que des activités ou des fragments, et de séparer la logique de traitement des données de l’interface utilisateur. Un autre aspect de ViewModel est la gestion des données liées à l’interface utilisateur d’une manière soucieuse du cycle de vie. Cette fonctionnalité permet aux données de survivre aux changements de configuration comme les rotations d’écran. Cet essai vise à discuter des concepts de ViewModel, ainsi que des étapes requises pour implémenter ViewModel dans les applications Android.
Présentation et introduction
le Classe ViewModel est conçu pour stocker et gérer les données liées à l’interface utilisateur en tenant compte du cycle de vie. La classe ViewModel permet aux données de survivre aux changements de configuration tels que les rotations d’écran.
Fondamentalement, les ViewModels sont des objets qui prennent en charge les données des composants d’interface utilisateur et survivent aux modifications de configuration. En fait, la rotation de votre téléphone mobile est considérée comme un changement de configuration. Les modifications de configuration entraînent la recréation de l’ensemble de votre activité. Si vous ne sauvegardez pas et ne restaurez pas correctement les données de l’activité détruite, vous perdrez ces données. De plus, vous devrez faire face à certains bugs ou plantages de l’interface utilisateur. Ainsi, au lieu de stocker toutes vos données d’interface utilisateur dans votre activité, vous devez les placer dans le ViewModel. Dans ce cas, cela aide aux changements de configuration; cependant, c’est également une meilleure pratique pour la conception de logiciels. En d’autres termes, un écueil courant lors du développement pour Android consiste à mettre beaucoup de variables, de logique et de données dans vos activités et vos fragments. Cela crée une grande classe non gérable et enfreint la règle du principe de responsabilité unique dans les principes SOLID. Par conséquent, vous pouvez utiliser ViewModel pour répartir facilement cette responsabilité. Le ViewModel sera responsable de la conservation de toutes les données que vous souhaitez afficher dans votre interface utilisateur, puis l’activité est uniquement responsable de savoir comment afficher ces données à l’écran pour recevoir les interactions des utilisateurs, mais pas pour le traitement de ces données. Un autre point important est que si votre application Android charge et stocke des données, vous pouvez créer une classe de référentiel comme expliqué dans le Guide de l’architecture des applications document par Google, car votre ViewModel ne doit pas être confronté à des responsabilités excessives.
En d’autres termes, les contrôleurs d’interface utilisateur tels que les activités et les fragments sont principalement destinés à afficher les données d’interface utilisateur, à réagir aux interactions des utilisateurs ou à gérer la communication du système d’exploitation comme les demandes d’autorisation. De plus, les contrôleurs d’interface utilisateur peuvent être responsables du chargement des données à partir d’une base de données ou d’une connexion réseau. En fait, attribuer une responsabilité excessive aux contrôleurs d’interface utilisateur peut entraîner une seule classe, qui essaie de gérer toutes les tâches d’une application seule, au lieu de déléguer le travail à d’autres classes. Ainsi, attribuer une responsabilité excessive aux contrôleurs de l’interface utilisateur de cette manière peut rendre le processus de test beaucoup plus difficile.
ViewModel est une classe chargée de préparer et de gérer les données d’une activité ou d’un fragment. Il gère également la communication de l’activité / du fragment avec le reste de l’application (par exemple, appeler les classes de logique métier).
Un autre problème important est que les contrôleurs d’interface utilisateur (activités et fragments) doivent fréquemment effectuer des appels asynchrones qui peuvent prendre un certain temps pour renvoyer le résultat. Ainsi, le contrôleur d’interface utilisateur doit gérer ces appels et s’assurer que le système les nettoie après la destruction pour éviter certaines fuites de mémoire potentielles. Il est clair que ce problème nécessite beaucoup de maintenance, car un objet est recréé pour un changement de configuration, ce qui entraîne un gaspillage de ressources en raison de ces processus répétés.
La seule responsabilité de ViewModel est de gérer les données de l’interface utilisateur. Il ne doit jamais accéder à votre hiérarchie de vues ni conserver une référence à l’activité ou au fragment.
Implémentation de ViewModel
- Créer une sous-classe de ViewModel
Pour créer un ViewModel, vous devrez étendre la classe ViewModel, puis vous pouvez placer vos variables d’instance liées à l’interface utilisateur qui étaient auparavant dans votre activité dans votre ViewModel. Par exemple:
class UserViewModel: ViewModel() {val user = User(name = "", address = "")}
2. Configurez ViewModel Provider dans votre activité onCreate
Ensuite, dans onCreate de votre activité, vous obtenez le ViewModel à partir d’une classe d’utilitaires d’infrastructure appelée ViewModel Provider. Notez que le fournisseur ViewModel prend une instance d’activité. Il s’agit du mécanisme qui vous permet de faire pivoter l’appareil, d’obtenir une nouvelle instance d’activité techniquement, mais assurez-vous toujours que cette instance d’activité est connectée avec le même ViewModel.
override fun onCreate(savedInstanceState: Bundle?) {val userViewModel =
ViewModelProviders.of(this).get(UserViewModel)::class.java)
userViewModel.user.name = "John"
}
En utilisant l’instance de ViewModel, vous pouvez utiliser des Getters et Setters pour accéder aux données de l’interface utilisateur de votre activité. Si vous souhaitez personnaliser le constructeur par défaut, qui actuellement aucun paramètre, vous pouvez utiliser un ViewModel Factory pour implémenter un constructeur personnalisé.
3. Utilisez LiveData et Data Binding avec votre ViewModel
Actuellement, il s’agit de la forme la plus simple d’un ViewModel, mais la classe ViewModel est également conçue pour fonctionner correctement avec Données en direct et Liaison de données bibliothèques. En utilisant toutes ces approches, vous pouvez créer une interface utilisateur réactive pour votre application Android, ce qui indique que votre interface utilisateur sera automatiquement mise à jour chaque fois que les données changent.
le Bibliothèque de liaison de données est une bibliothèque de support qui vous permet de lier des composants d’interface utilisateur dans vos présentations à des sources de données dans votre application en utilisant un format déclaratif plutôt que par programme.
ViewModel + LiveData + liaison de données = interface utilisateur réactive
Données en direct est une classe de détenteurs de données observables. Contrairement à un observable normal, LiveData est sensible au cycle de vie, ce qui signifie qu’il respecte le cycle de vie des autres composants de l’application, tels que les activités, les fragments ou les services. Cette prise de conscience garantit que LiveData ne met à jour que les observateurs de composants d’application qui sont dans un état de cycle de vie actif.
Cela suppose que toutes vos données dans votre ViewModel, que vous prévoyez de représenter à l’écran, sont regroupées dans LiveData comme suit:
class UserViewModel: ViewModel() { private val _user MutableLiveData() val user : LiveData
get() = _user}
Ensuite, vous devez configurer la liaison de données. Par exemple, le XML avec la balise de mise en page de liaison de données et la balise variable pour votre ViewModel sont les suivants:
name="viewmodel"
type="android.example.com.UserViewModel"/>
<.../>
Après avoir terminé cette étape, vous devez ajouter ces lignes de codes à la création de votre activité comme ci-dessous:
override fun onCreate(savedInstanceState: Bundle?) {// Rest of the onCreate method...
val binding = ActivityMainBinding.inflate(layoutInflater)
binding.viewmodel = userViewModel
binding.setLifecycleOwner(this)
setContentView(binding.root)
}
Dans le code ci-dessus, la méthode setLifecycleOwner () permet à la liaison d’observer vos objets LiveData dans le ViewModel, et cela aide la mise à jour de la liaison chaque fois que le LiveData change.
Le cycle de vie d’un ViewModel
Dans le diagramme ci-dessous, vous pouvez voir le cycle de vie d’une activité, qui fait face à une rotation. La durée de vie du ViewModel est affichée à côté du cycle de vie d’activité associé. En fait, ViewModel peut être facilement utilisé avec des fragments et des activités. Le ViewModel existe à partir du moment où vous demandez un ViewModel en premier (dans l’activité onCreate) jusqu’à ce que l’activité soit terminée et détruite. Ainsi, onCreate () pourrait être appelé plusieurs fois au cours de la vie d’une activité.
Différences entre ViewModel et onSaveInstanceState
Fondamentalement, bien que ViewModel soit conçu pour être appliqué en plus de onSaveInstanceState comme une autre option, certaines différences peuvent être clairement mentionnées. ViewModels ne survit pas à l’arrêt du processus en raison de restrictions de ressources, mais les bundles onSaveInstance effectuent cette tâche. ViewModel est un excellent choix pour stocker d’énormes quantités de données; tandis que les bundles onSaveInstanceState ne sont pas une option appropriée à cette fin. Les ViewModels sont utilisés pour stocker autant de données d’interface utilisateur que possible. Par conséquent, ces données n’ont pas besoin d’être rechargées ou régénérées lors d’une modification de configuration. onSaveInstanceState, d’autre part, doit stocker la plus petite quantité de données nécessaires pour restaurer l’état de l’interface utilisateur si le processus est arrêté par le framework. Par exemple, vous pouvez stocker toutes les données de l’utilisateur dans le ViewModel tout en stockant simplement l’ID de la base de données de l’utilisateur dans onSaveInstanceState.
ViewModel et Context
Les ViewModels ne doivent pas contenir de référence aux activités, fragments ou contextes. En outre, ViewModels ne doit pas inclure de références à des contrôleurs d’interface utilisateur comme des vues, car cela créera une référence indirecte à un contexte. Lorsque vous faites pivoter l’écran que l’activité est détruite, vous disposez d’un ViewModel qui contient une référence à une activité détruite, et il s’agit d’une fuite de mémoire. Donc, si vous devez utiliser des contextes, vous devez utiliser le contexte d’application (AndroidViewModel sous-classe).
En conclusion
En fait, ViewModel est une classe qui est responsable de la préparation et du traitement des données pour une activité ou un fragment. En outre, il gère la communication de l’activité et du fragment avec le reste de l’application, comme l’appel des classes de logique métier. Cet essai a examiné les concepts de ViewModel, ainsi que les étapes requises pour implémenter ViewModel dans les applications Android.
