Gestion des états et des effets

Introduction

De manière générale, un état désigne toute valeur susceptible de changer au fil du temps. Que ce soit une variable dans une classe, une valeur stockée en base de données, ou encore une valeur fournie par une API tierce. Les écrans de nos applications Android sont, en fait, une représentation à un instant T des différents états qui la composent. Par exemple :

Dans les chapitres précédents, nous avons créé des fonctions Composables dont les états pouvaient se situer à deux endroits différents :

@Composable 
fun MessageContent( 
    message: String, 
    time: String, 
    modifier: Modifier = Modifier 
) { 
    /*...*/ 
} 

@Composable 
fun NewMessageInput( 
    modifier: Modifier = Modifier, 
    onSend: (String) -> Unit 
) {  
    var input by remember { mutableStateOf("") }  
    OutlinedTextField( 
        modifier...

Origine de cette pratique

Certains composants que nous concevons nécessitent l’accès à un état de type Screen UI State. Nous avons vu que ce type d’état est produit dans le State Holder de l’écran, typiquement le ViewModel. Imaginons un instant qu’au sein d’un même écran, chacun des composants accède directement au Screen UI State. Nous nous retrouvons avec de multiples connexions entre la vue et le State Holder, comme illustré ci-dessous. Dans cette situation, comme chaque composant a un cycle de vie unique, le risque de collision et de bogues lors de la manipulation du Screen UI est élevé.

Illustration des multiples connexions

C’est pourquoi une bonne pratique consiste à accéder au Screen UI State uniquement depuis le composant à la racine de l’arbre de composition. Ce composant racine correspond généralement au rendu de l’écran complet. Cette pratique permet d’avoir un point d’entrée unique vers le State Holder de l’écran et d’appliquer ainsi le principe d’architecture de source unique de vérité (ou Single Source of Truth en anglais).

Appliquer cette bonne pratique se traduit par la conception de composants sans état interne, qui reçoivent...

La fonction remember

De prime abord, pour développer un composant avec un état interne, il est tentant de simplement y instancier une variable de manière standard comme dans cet exemple :

@Composable 
fun NewMessage() { 
    var input: String = "" 
    TextField( 
        value = input, 
        onValueChange = { 
            input = it 
        } 
    ) 
} 

Cependant, en faisant ainsi, la variable input sera réinitialisée à chaque recomposition du composant. Pour permettre à une variable d’être persistée au-delà du mécanisme de recomposition d’un composant, il faut utiliser la fonction remember{}.Cette fonction a les caractéristiques suivantes :

Cela donne pour le composant NewMessage le code suivant :

@Composable 
fun NewMessage()...

Introduction

Nous avons vu dans le chapitre La genèse de Jetpack Compose que pour fonctionner de manière optimale, une fonction Composable ne doit pas générer d’effet de bord, dit side effect en anglais.

Pour rappel, un effet de bord désigne toute opération qui échappe au contrôle et à la portée d’une fonction. Cela désigne par exemple des opérations telles que :

Bien que ces opérations soient tout à fait normales au sein d’une application, réaliser celles-ci au sein d’une fonction Composable peut générer des comportements imprévisibles liés au cycle de vie particulier des fonctions Composables.

Pour rappel, une fonction Composable peut subir plusieurs recompositions, être exécutée en parallèle et dans un ordre non prédictible. C’est pour cela qu’idéalement une fonction Composable ne devrait pas contenir d’effet de bord.

Pourtant, il existe certaines situations pour lesquelles il est nécessaire de créer des fonctions avec un effet de bord. Typiquement, lorsqu’une action nécessite de s’exécuter à des moments clés du cycle de vie d’une fonction Composable, par exemple lors de la première apparition d’un composant ou encore à chaque fois que l’état interne d’un composant change.

Exemple d’effet de bord acceptable

Reprenons le composant en charge de représenter la liste des messages au sein d’une conversation. Pour ce type de composant, il est souhaitable pour l’utilisateur que dès son ouverture, la liste des messages soit déroulée...