Présentation de ViewModel   Fait partie d'Android Jetpack.

La classe ViewModel est conçue pour stocker et gérer les données liées à l'interface utilisateur tout en tenant compte du cycle de vie. La classe ViewModel permet aux données de survivre à des modifications de configuration telles que les rotations d'écran.

Le framework Android gère le cycle de vie des contrôleurs d'interface utilisateur tels que les activités et les fragments. Le framework peut décider de détruire ou de recréer un contrôleur d'interface utilisateur en réponse à certaines actions utilisateur ou à des événements d'appareil qui vous appartiennent totalement.

Si le système détruit ou recrée un contrôleur d'interface utilisateur, toutes les données temporaires d'interface utilisateur qui y sont stockées sont perdues. Par exemple, votre application peut inclure une liste d'utilisateurs dans l'une de ses activités. Lorsque l'activité est recréée pour modifier une configuration, la nouvelle activité doit de nouveau récupérer la liste des utilisateurs. Pour les données simples, l'activité peut utiliser la méthode onSaveInstanceState() et restaurer ses données du bundle dans onCreate(), mais cette approche ne convient qu'aux petites quantités de données pouvant être sérialisées puis désérialisées, pas pour des volumes de données plus grands, tels qu'une liste d'utilisateurs ou de bitmaps.

Un autre problème est que les contrôleurs d'interface utilisateur doivent fréquemment effectuer des appels asynchrones dont le retour peut prendre un certain temps. Le contrôleur d'interface utilisateur doit gérer ces appels et s'assurer que le système les nettoie après sa destruction pour éviter toute fuite potentielle de mémoire. Cette gestion nécessite beaucoup de maintenance. Dans le cas où l'objet est recréé pour modifier une configuration, cela gaspille des ressources, car l'objet peut avoir besoin de réémettre des appels qu'il a déjà effectués.

Les contrôleurs d'interface utilisateur tels que les activités et les fragments sont principalement destinés à afficher les données de l'interface utilisateur, à réagir aux actions des utilisateurs ou à gérer la communication du système d'exploitation, comme les demandes d'autorisation. Le fait que les contrôleurs d'interface utilisateur soient également responsables du chargement des données à partir d'une base de données ou d'un réseau ajoute une surcharge à la classe. L'attribution excessive de responsabilités aux contrôleurs de l'interface utilisateur peut entraîner la création d'une classe unique qui tente de gérer seule le travail d'une application, au lieu de déléguer le travail à d'autres classes. Attribuer une responsabilité excessive aux contrôleurs de l'interface utilisateur de cette manière complique considérablement le test.

Il est plus simple et plus efficace de séparer la propriété des données de la vue de la logique du contrôleur d'interface utilisateur.

Implémenter un ViewModel

Les composants d'architecture fournissent une classe d'assistance ViewModel pour le contrôleur d'interface utilisateur chargé de préparer les données pour l'interface utilisateur. Les objets ViewModel sont automatiquement conservés lorsque la configuration change. Ainsi, les données qu'ils contiennent sont immédiatement disponibles pour l'activité ou l'instance de fragment suivante. Par exemple, si vous devez afficher une liste d'utilisateurs dans votre application, veillez à attribuer la responsabilité d'acquisition et de conservation de la liste d'utilisateurs à un ViewModel au lieu d'une activité ou d'un fragment, comme le montre l'exemple de code suivant :

class MyViewModel : ViewModel() {
    private val users: MutableLiveData<List<User>> by lazy {
        MutableLiveData<List<User>>().also {
            loadUsers()
        }
    }

    fun getUsers(): LiveData<List<User>> {
        return users
    }

    private fun loadUsers() {
        // Do an asynchronous operation to fetch users.
    }
}

public class MyViewModel extends ViewModel {
    private MutableLiveData<List<User>> users;
    public LiveData<List<User>> getUsers() {
        if (users == null) {
            users = new MutableLiveData<List<User>>();
            loadUsers();
        }
        return users;
    }

    private void loadUsers() {
        // Do an asynchronous operation to fetch users.
    }
}

Vous pouvez ensuite accéder à la liste à partir d'une activité comme suit :

class MyActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        // Create a ViewModel the first time the system calls an activity's onCreate() method.
        // Re-created activities receive the same MyViewModel instance created by the first activity.

        // Use the 'by viewModels()' Kotlin property delegate
        // from the activity-ktx artifact
        val model: MyViewModel by viewModels()
        model.getUsers().observe(this, Observer<List<User>>{ users ->
            // update UI
        })
    }
}

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        // Create a ViewModel the first time the system calls an activity's onCreate() method.
        // Re-created activities receive the same MyViewModel instance created by the first activity.

        MyViewModel model = new ViewModelProvider(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

Si l'activité est recréée, elle reçoit la même instance MyViewModel que celle créée par la première activité. Une fois l'activité du propriétaire terminée, le framework appelle la méthode onCleared() des objets ViewModel pour pouvoir nettoyer les ressources.

Les objets ViewModel sont conçus pour survivre à des instanciations spécifiques de vues ou de LifecycleOwners. Cette conception vous permet également d'écrire des tests pour couvrir plus facilement une propriété ViewModel, car elle ne connaît pas la vue et les objets Lifecycle. Les objets ViewModel peuvent contenir des éléments LifecycleObservers tels que LiveData. Toutefois, les objets ViewModel ne doivent jamais observer de modifications des objets observables compatibles avec le cycle de vie, tels que les objets LiveData. Si ViewModel a besoin du contexte Application, par exemple pour trouver un service système, il peut étendre la classe AndroidViewModel et avoir un constructeur qui reçoit l'Application, car la classe Application étend le Context.

Créer des ViewModels avec des dépendances

Conformément aux bonnes pratiques concernant l'injection de dépendances, les ViewModels peuvent utiliser des dépendances comme paramètres dans leur constructeur. Il s'agit principalement de types issus des couches de domaines ou de données. Comme le framework fournit les ViewModels, un mécanisme spécial est nécessaire pour créer des instances. Ce mécanisme correspond à l'interface ViewModelProvider.Factory. Seules les implémentations de cette interface peuvent instancier les ViewModels avec le champ d'application approprié.

Si une classe ViewModel reçoit des dépendances dans son constructeur, fournissez une fabrique qui implémente l'interface ViewModelProvider.Factory. Ignorez la fonction create(Class<T>, CreationExtras) pour fournir une nouvelle instance de ViewModel.

CreationExtras vous permet d'accéder à des informations pertinentes pour instancier un ViewModel. Voici une liste de clés accessibles depuis Extras :

Pour créer une instance de SavedStateHandle, utilisez la fonction CreationExtras.createSavedStateHandle().createSavedStateHandle()) et transmettez-la au ViewModel.

L'exemple suivant montre comment fournir une instance d'un ViewModel qui utilise un dépôt limité à la classe Application et à SavedStateHandle en tant que dépendances :

import androidx.lifecycle.SavedStateHandle
import androidx.lifecycle.ViewModel
import androidx.lifecycle.ViewModelProvider
import androidx.lifecycle.ViewModelProvider.AndroidViewModelFactory.Companion.APPLICATION_KEY
import androidx.lifecycle.createSavedStateHandle
import androidx.lifecycle.viewmodel.CreationExtras

class MyViewModel(
    private val myRepository: MyRepository,
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    // ViewModel logic
    // ...

    // Define ViewModel factory in a companion object
    companion object {

        val Factory: ViewModelProvider.Factory = object : ViewModelProvider.Factory {
            @Suppress("UNCHECKED_CAST")
            override fun <T : ViewModel> create(
                modelClass: Class<T>,
                extras: CreationExtras
            ): T {
                // Get the Application object from extras
                val application = checkNotNull(extras[APPLICATION_KEY])
                // Create a SavedStateHandle for this ViewModel from extras
                val savedStateHandle = extras.createSavedStateHandle()

                return MyViewModel(
                    (application as MyApplication).myRepository,
                    savedStateHandle
                ) as T
            }
        }
    }
}

import static androidx.lifecycle.SavedStateHandleSupport.createSavedStateHandle;
import static androidx.lifecycle.ViewModelProvider.AndroidViewModelFactory.APPLICATION_KEY;

import androidx.lifecycle.SavedStateHandle;
import androidx.lifecycle.ViewModel;
import androidx.lifecycle.viewmodel.ViewModelInitializer;

public class MyViewModel extends ViewModel {

    public MyViewModel(
        MyRepository myRepository,
        SavedStateHandle savedStateHandle
    ) { /* Init ViewModel here */ }

    static final ViewModelInitializer<MyViewModel> initializer = new ViewModelInitializer<>(
        MyViewModel.class,
        creationExtras -> {
            MyApplication app = (MyApplication) creationExtras.get(APPLICATION_KEY);
            assert app != null;
            SavedStateHandle savedStateHandle = createSavedStateHandle(creationExtras);

            return new MyViewModel(app.getMyRepository(), savedStateHandle);
        }
    );
}

Vous pouvez ensuite utiliser cette fabrique pour récupérer une instance de ViewModel :

import androidx.activity.viewModels

class MyActivity : AppCompatActivity() {

    private val viewModel: MyViewModel by viewModels { MyViewModel.Factory }

    // Rest of Activity code
}

import androidx.appcompat.app.AppCompatActivity;
import androidx.lifecycle.ViewModelProvider;

public class MyActivity extends AppCompatActivity {

    MyViewModel myViewModel = new ViewModelProvider(
        this,
        ViewModelProvider.Factory.from(MyViewModel.initializer)
    ).get(MyViewModel.class);

    // Rest of Activity code
}

import androidx.lifecycle.viewmodel.compose.viewModel

@Composable
fun MyScreen(
    modifier: Modifier = Modifier,
    viewModel: MyViewModel = viewModel(factory = MyViewModel.Factory)
) {
    // ...
}

Vous pouvez également utiliser la DSL de fabrique de ViewModel pour créer des fabriques à l'aide d'une API Kotlin plus idiomatique :

import androidx.lifecycle.SavedStateHandle
import androidx.lifecycle.ViewModel
import androidx.lifecycle.ViewModelProvider
import androidx.lifecycle.ViewModelProvider.AndroidViewModelFactory.Companion.APPLICATION_KEY
import androidx.lifecycle.createSavedStateHandle
import androidx.lifecycle.viewmodel.initializer
import androidx.lifecycle.viewmodel.viewModelFactory

class MyViewModel(
    private val myRepository: MyRepository,
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    // ViewModel logic

    // Define ViewModel factory in a companion object
    companion object {
        val Factory: ViewModelProvider.Factory = viewModelFactory {
            initializer {
                val savedStateHandle = createSavedStateHandle()
                val myRepository = (this[APPLICATION_KEY] as MyApplication).myRepository
                MyViewModel(
                    myRepository = myRepository,
                    savedStateHandle = savedStateHandle
                )
            }
        }
    }
}

Fabriques pour une version de ViewModel antérieure à la version 2.5.0

Si vous utilisez une version de ViewModel antérieure à la version 2.5.0, vous devez fournir des fabriques d'un sous-ensemble de classes qui étendent le ViewModelProvider.Factory et implémentent la fonction create(Class<T>). Selon les dépendances dont le ViewModel a besoin, une autre classe doit être étendue à partir de :

• AndroidViewModelFactory si la classe Application est nécessaire.
• AbstractSavedStateViewModelFactory si SavedStateHandle doit être transmis en tant que dépendance.

Si Application ou SavedStateHandle ne sont pas nécessaires, étendez simplement depuis ViewModelProvider.Factory.

L'exemple suivant utilise une propriété AbstractSavedStateViewModelFactory pour un ViewModel qui utilise un dépôt et le type SavedStateHandle comme dépendance :

class MyViewModel(
    private val myRepository: MyRepository,
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    // ViewModel logic ...

    // Define ViewModel factory in a companion object
    companion object {
        fun provideFactory(
            myRepository: MyRepository,
            owner: SavedStateRegistryOwner,
            defaultArgs: Bundle? = null,
        ): AbstractSavedStateViewModelFactory =
            object : AbstractSavedStateViewModelFactory(owner, defaultArgs) {
                @Suppress("UNCHECKED_CAST")
                override fun <T : ViewModel> create(
                    key: String,
                    modelClass: Class<T>,
                    handle: SavedStateHandle
                ): T {
                    return MyViewModel(myRepository, handle) as T
                }
            }
    }
}

import androidx.annotation.NonNull;
import androidx.lifecycle.AbstractSavedStateViewModelFactory;
import androidx.lifecycle.SavedStateHandle;
import androidx.lifecycle.ViewModel;

public class MyViewModel extends ViewModel {
    public MyViewModel(
        MyRepository myRepository,
        SavedStateHandle savedStateHandle
    ) { /* Init ViewModel here */ }
}

public class MyViewModelFactory extends AbstractSavedStateViewModelFactory {

    private final MyRepository myRepository;

    public MyViewModelFactory(
        MyRepository myRepository
    ) {
        this.myRepository = myRepository;
    }

    @SuppressWarnings("unchecked")
    @NonNull
    @Override
    protected <T extends ViewModel> T create(
        @NonNull String key, @NonNull Class<T> modelClass, @NonNull SavedStateHandle handle
    ) {
        return (T) new MyViewModel(myRepository, handle);
    }
}

Vous pouvez ensuite utiliser la fabrique pour récupérer votre ViewModel :

import androidx.activity.viewModels

class MyActivity : AppCompatActivity() {

    private val viewModel: MyViewModel by viewModels {
        MyViewModel.provideFactory((application as MyApplication).myRepository, this)
    }

    // Rest of Activity code
}

public class MyActivity extends AppCompatActivity {

    MyViewModel myViewModel = new ViewModelProvider(
        this,
        new MyViewModelFactory(((MyApplication) getApplication()).getMyRepository())
    ).get(MyViewModel.class);

    // Rest of Activity code
}

import androidx.lifecycle.viewmodel.compose.viewModel

@Composable
fun MyScreen(
    modifier: Modifier = Modifier,
    viewModel: MyViewModel = viewModel(
        factory = MyViewModel.provideFactory(
            (LocalContext.current.applicationContext as MyApplication).myRepository,
            owner = LocalSavedStateRegistryOwner.current
        )
    )
) {
    // ...
}

Cycle de vie d'un ViewModel

Les objets ViewModel sont limités au Lifecycle transmis au ViewModelProvider lors de l'obtention du ViewModel. Le ViewModel reste en mémoire jusqu'à ce que le Lifecycle auquel il est limité soit définitivement supprimé : dans le cas d'une activité, lorsqu'elle se termine, et dans le cas d'un fragment, lorsqu'il est dissocié.

La figure 1 illustre les différents états de cycle de vie d'une activité lorsqu'elle est soumise à une rotation, et lorsqu'elle est terminée. L'image montre également la durée de vie du ViewModel à côté du cycle de vie de l'activité associé. Ce diagramme illustre les différents états d'une activité. Les mêmes états de base s'appliquent au cycle de vie d'un fragment.

Vous demandez généralement un objet ViewModel la première fois que le système appelle la méthode onCreate() d'un objet d'activité. Le système peut appeler onCreate() plusieurs fois au cours d'une activité, par exemple lors de la rotation de l'écran d'un appareil. Le ViewModel existe entre le moment où vous demandez un ViewModel pour la première fois et le moment où l'activité est terminée et détruite.

Partager des données entre fragments

Il est très courant que plusieurs fragments d'une activité doivent communiquer entre eux. Imaginez un cas courant de fragments de vue fractionnée (list-detail), constituée d'un fragment dans lequel l'utilisateur sélectionne un élément d'une liste et d'un autre fragment qui affiche le contenu de l'élément sélectionné. Ce cas n'est jamais simple, car les deux fragments doivent définir une description de l'interface, et l'activité du propriétaire doit lier les deux. En outre, les deux fragments doivent gérer le scénario dans lequel l'autre fragment n'est pas encore créé ni visible.

Ce problème peut être résolu à l'aide d'objets ViewModel. Ces fragments peuvent partager un objet ViewModel à l'aide de leur champ d'application d'activité pour gérer cette communication, comme illustré par l'exemple de code suivant :

class SharedViewModel : ViewModel() {
    val selected = MutableLiveData()

    fun select(item: Item) {
        selected.value = item
    }
}

class ListFragment : Fragment() {

    private lateinit var itemSelector: Selector

    // Use the 'by activityViewModels()' Kotlin property delegate
    // from the fragment-ktx artifact
    private val model: SharedViewModel by activityViewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        itemSelector.setOnClickListener { item ->
            // Update the UI
        }
    }
}

class DetailFragment : Fragment() {

    // Use the 'by activityViewModels()' Kotlin property delegate
    // from the fragment-ktx artifact
    private val model: SharedViewModel by activityViewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        model.selected.observe(viewLifecycleOwner, Observer { item ->
            // Update the UI
        })
    }
}

public class SharedViewModel extends ViewModel {
    private final MutableLiveData<Item> selected = new MutableLiveData<Item>();

    public void select(Item item) {
        selected.setValue(item);
    }

    public LiveData getSelected() {
        return selected;
    }
}

public class ListFragment extends Fragment {
    private SharedViewModel model;

    public void onViewCreated(@NonNull View view, Bundle savedInstanceState) {
        super.onViewCreated(view, savedInstanceState);
        model = new ViewModelProvider(requireActivity()).get(SharedViewModel.class);
        itemSelector.setOnClickListener(item -> {
            model.select(item);
        });
    }
}

public class DetailFragment extends Fragment {

    public void onViewCreated(@NonNull View view, Bundle savedInstanceState) {
        super.onViewCreated(view, savedInstanceState);
        SharedViewModel model = new ViewModelProvider(requireActivity()).get(SharedViewModel.class);
        model.getSelected().observe(getViewLifecycleOwner(), item -> {
           // Update the UI.
        });
    }
}

Notez que les deux fragments récupèrent l'activité qui les contient. Ainsi, lorsque les fragments obtiennent chacun la valeur ViewModelProvider, ils reçoivent la même instance SharedViewModel, qui est limitée à cette activité.

Cette approche offre les avantages suivants :

• L'activité n'a rien à faire et ne sait rien de cette communication.
• Les fragments n'ont pas besoin de se connaître en dehors du contrat SharedViewModel. Si l'un des fragments disparaît, l'autre continue de fonctionner normalement.
• Chaque fragment a son propre cycle de vie et n'est pas affecté par le cycle de vie de l'autre. Si un fragment remplace l'autre, l'interface utilisateur continue de fonctionner sans problème.

Remplacer les chargeurs par ViewModel

Les classes de chargement telles que CursorLoader sont fréquemment utilisées pour synchroniser les données de l'interface utilisateur d'une application avec une base de données. Vous pouvez utiliser ViewModel avec d'autres classes pour remplacer le chargeur. L'utilisation d'un objet ViewModel permet de séparer votre contrôleur d'interface utilisateur de l'opération de chargement des données, ce qui signifie que vous avez moins de références fortes entre les classes.

Une approche courante pour utiliser des chargeurs consiste à observer le contenu d'une base de données à l'aide d'un CursorLoader. Lorsqu'une valeur de la base de données change, le chargeur déclenche automatiquement une actualisation des données et met à jour l'interface utilisateur :

ViewModel fonctionne avec Room et LiveData pour remplacer le chargeur. Le ViewModel garantit que les données survivront à une modification de la configuration de l'appareil. Room informe LiveData lorsque la base de données change, puis LiveData met à jour votre interface utilisateur avec les données révisées.

Utiliser des coroutines avec ViewModel

ViewModel est compatible avec les coroutines Kotlin. Pour en savoir plus, consultez Utiliser des coroutines Kotlin avec des composants d'architecture Android.

Informations supplémentaires

À mesure que vos données deviennent plus complexes, vous pouvez choisir de disposer d'une classe distincte pour les charger. L'objectif de ViewModel est d'encapsuler les données pour un contrôleur d'interface utilisateur afin de permettre aux données de survivre aux modifications de configuration. Pour en savoir plus sur le chargement, la conservation et la gestion des données lors des modifications de configuration, consultez Enregistrer des états d'interface utilisateur.

Le Guide de l'architecture des applications Android suggère de créer une classe de dépôt pour gérer ces fonctions.

Ressources supplémentaires

Pour en savoir plus sur la classe ViewModel, consultez les ressources suivantes.

Exemples

• Exemple d'architecture de base pour les composants Android
• Sunflower, une application de jardinage qui illustre les bonnes pratiques de développement Android avec Android Jetpack.

Ateliers de programmation

• Android Room et Viewmodel (Java) (Kotlin)
• Atelier de programmation sur les composants du cycle de vie Android

Blogs

• ViewModels : un exemple simple
• ViewModels : persistance, onSaveInstanceState(), restauration de l'état de l'interface utilisateur et des chargeurs
• ViewModels et LiveData : schémas + antischémas
• Démystifier Kotlin : comprendre la syntaxe Lambda abrégée
• Démystifier Kotlin : fonctions des champs d'application
• Démystifier Kotlin : quand utiliser des accesseurs personnalisés
• Chargement des données tenant compte du cycle de vie avec les composants d'architecture

Vidéos

• Android Jetpack : ViewModel