mobile-best-practice/chapters/MBP_006_fr.md

## Optimiser la récupération des données en fonction du cycle de vie

### Identifiants

### Catégories

| Cycle de vie |  Tiers  |       Responsable        |
|:---------:|:----:|:------------------------:|
| 2. Conception | Utilisateur/Terminal | Developpeur/Développeuse |

### Indications

| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
|:-------------------:|:-------------------------:|:---------------------:|
| 3 | 4 | 3 |

| Ressources Economisées |
|:----------------------:|
|    Mémoire / Réseau    |

### Description

Lorsqu'une personne navigue d'un écran à un autre au sein d'une application, mais également entre plusieurs applications sur son mobile, ces applications transitionnent entre différents états. Selon ces changements d'état, pour optimiser l'usage de la mémoire du téléphone, le système va effectuer des opérations telles que : libérer partiellement la mémoire si l'application passe en arrière-plan, supprimer les données en mémoire de l'écran en cours si l'utilisateur quitte celui-ci en appuyant par exemple sur le bouton retour. 


Il convient d'optimiser l'accès aux données faites depuis une activité selon son cycle de vie, afin d'éviter d'effectuer inutilement des requêtes en base de données locale ou sur le réseau.

Il existe plusieurs bonnes pratiques à appliquer à différents niveaux : 
- À l'échelle de la vue :
  - En utilisant correctement les callbacks du cycle de vie fournies au sein d'une `Activity`.
- À l'échelle du `ViewModel` : 
  - En utilisant une classe de type `ViewModel` (par exemple via l'implémentation fournie par l'API **Jetpack ViewModel**) avec un cycle de vie plus long que celui de la vue.
 
#### A l'échelle de la vue : 

Au sein d'une classe de type `Activity`, il est courant de surcharger une ou plusieurs méthodes du cycle de vie afin d'initialiser et d'adapter l'état de la vue (via les méthodes `onCreate`, `onResume`, `onPause`,`onStop`, etc.). Il est important d'éviter de récupérer inutilement les données depuis la base de données locale ou le réseau à chaque fois que la vue redevient visible et utilisable (état `RESUMED`), c'est-à-dire au sein de la fonction `onResume`.
Il convient plutôt d'initialiser l'état de la vue au sein de la fonction `onCreate` et de récupérer les données dont elle a besoin soit dans l'état `CREATED`, soit dans l'état `STARTED`.

Note : Dans certaines situations, il est conseillé de développer ses propres composants "lifecycle aware" afin d'être notifié de la même façon de ces changements d'états et de rendre le code plus maintenable.

#### A l'échelle du `ViewModel` 

Une classe de type `ViewModel` a un cycle de vie d'une durée de vie plus longue qu'une `Activity` ou un `Fragment`.
Gérer et maintenir les données de la vue au sein de ce type de classe permet de les garder en mémoire durant toute la durée de vie de la vue. Typiquement lors des changements de configuration (ex : l'utilisateur change l'orientation de l'écran) ou lorsque la vue passe en arrière-plan. Les données dont la vue a besoin pour se restaurer suite à ces changements restent ainsi accessibles sans avoir besoin d'effectuer une nouvelle requête en base de données ou sur le serveur. L'accès en lecture et en écriture aux données en mémoire est plus rapide et moins consommateur. De plus, une fois que la vue associée au ViewModel est détruit, par exemple si l'utilisateur quitte l'écran en appuyant sur le bouton retour, le ViewModel est aussi détruit, libérant ainsi les données de la mémoire précédemment stockées.

### Exemple

Soit une vue d'une application affichant le profil d'un utilisateur : 

`MainActivity.kt` : 


```
class ProfileActivity : ComponentActivity() {

    private val viewModel: ProfileViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Update the uiState
        lifecycleScope.launch {
            lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collectLatest {
                    // TODO update view
                }
            }
        }
    }
}
```

`ProfileViewModel.kt` : 

```

class ProfileViewModel(userRepository: UserRepository) : ViewModel() {

    val uiState: StateFlow<ProfileUIState> = userRepository.userData.map {
        ProfileUIState.Success(it)
    }.stateIn(
        scope = viewModelScope,
        initialValue = ProfileUIState.Loading,
        started = SharingStarted.WhileSubscribed(5_000),
    )
}

sealed interface ProfileUIState {
    data object Loading : ProfileUIState
    data class Success(val user: User) : ProfileUIState
}

```

### Principe de validation

| Le nombre ...                                                                                       | est inférieur ou égal à |  
|-----------------------------------------------------------------------------------------------------|:-----------------------:|
| d'écrans effectuant des chargements de données à chaque fois que la vue passe dans l'état `RESUMED` |            0            |
| d'écrans rechargeant l'ensemble des données lors d'un changement de configuration                   |            0            |
| d'écrans n'utilisant pas de ViewModel ou équivalent pour maintenir l'état de la vue plus longtemps  |            0            |