State Restoration dans les applications mobiles : ce que c'est, mécanisme et principe de fonctionnement

Qu'est-ce que State Restoration ?

State Restoration (restauration d'état) est un mécanisme système qui permet de sauvegarder l'état actuel de l'interface utilisateur d'une application et de le restaurer après son arrêt ou son redémarrage. Lorsqu'un utilisateur minimise une application ou que le système la ferme pour libérer des ressources, State Restoration capture les paramètres clés de l'interface utilisateur et les sauvegarde dans un stockage chiffré.

Sans State Restoration, les utilisateurs perdent toutes les données non sauvegardées lors du changement d'application. Par exemple, un formulaire de commentaires rempli, une longue requête de recherche ou une liste d'actualités partiellement consultée — tout cela disparaît au redémarrage. State Restoration résout ce problème en capturant automatiquement l'état du ViewController ou de l'Activity au moment de la minimisation.

Le mécanisme fonctionne au niveau système et est pris en charge par les deux principales plates-formes mobiles. iOS fournit State Restoration via NSUserActivity et le protocole UIStateRestoring, tandis qu'Android le fournit via SavedStateHandle dans les composants architecturaux Jetpack et ViewModel. L'implémentation diffère, mais le concept est identique.

Comment fonctionne State Restoration ?

Le processus de State Restoration est divisé en deux phases : la sauvegarde et la restauration. Dans la phase de sauvegarde, le système appelle les méthodes correspondantes du cycle de vie, dans lesquelles l'application doit sérialiser l'état actuel de l'interface utilisateur dans une représentation compacte. Dans la phase de restauration, le système renvoie les données sauvegardées et l'application les désérialise pour restaurer l'interface utilisateur.

Mécanisme de sauvegarde d'état

La sauvegarde est initiée par le système lorsque l'application passe en arrière-plan ou reçoit un signal d'arrêt imminent. Sous iOS, la méthode encodeRestorableState de UIViewController est appelée ; sous Android, onSaveInstanceState de l'Activity ou la sauvegarde via SavedStateHandle est déclenchée. Les données sont sérialisées dans un format prenant en charge les types primitifs : chaînes, nombres, tableaux d'octets et objets Parcelable.

La quantité de données sauvegardées doit être minimale — le système impose des limites sur la taille du paquet d'état sauvegardé. Sous Android, la limite est d'environ 50 Ko par processus. Le dépassement de la limite provoque une exception TransactionTooLargeException. Par conséquent, les architectes recommandent de sauvegarder uniquement les identifiants et les clés, et de charger les données complètes depuis le stockage persistant lors de la restauration.

Restauration de l'interface utilisateur à partir de l'état sauvegardé

Lors de la restauration, le système transmet le paquet de données sauvegardées à l'application au moment du lancement. Sous iOS, la méthode decodeRestorableState est appelée ; sous Android, onRestoreInstanceState ou la lecture depuis SavedStateHandle est utilisée. L'application extrait les identifiants et les clés du paquet et restaure l'interface utilisateur : position de défilement, éléments sélectionnés, données saisies.

Il est important de noter que la restauration peut se produire dans un nouveau processus. Si l'application a été complètement déchargée de la mémoire, le processus est créé à nouveau et tous les objets en mémoire sont absents. Par conséquent, l'état doit être sérialisable et indépendant du contexte d'exécution de la session précédente. C'est particulièrement critique pour les grands formulaires comportant plusieurs champs de saisie et les longues interfaces multi-pages.

class MainActivity : AppCompatActivity() {
    private var searchQuery: String = ""

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("search_query", searchQuery)
    }

    override fun onRestoreInstanceState(savedState: Bundle) {
        super.onRestoreInstanceState(savedState)
        searchQuery = savedState.getString("search_query", "")!!
        restoreSearchUI(searchQuery)
    }
}

State Restoration sur iOS et Android

L'implémentation de State Restoration diffère considérablement entre les plates-formes. iOS utilise une approche déclarative via les storyboards et les protocoles UIKit, tandis qu'Android utilise une approche impérative via les méthodes du cycle de vie de l'Activity et les composants architecturaux Jetpack. Le choix de l'approche dépend de la plateforme cible et de l'architecture de l'application.

State Restoration sous iOS (UIKit)

Sous iOS, State Restoration repose sur trois composants : UIApplication gère le processus global, UIViewController implémente le protocole UIStateRestoring et NSUserActivity stocke les données pour la restauration de la navigation. Pour l'activer, vous devez définir restorationIdentifier sur UIViewController et implémenter encodeRestorableState et decodeRestorableState.

iOS sauvegarde automatiquement l'état du contrôleur de navigation (UINavigationController) et de tous les ViewControllers imbriqués s'ils ont un restorationIdentifier défini. Le système gère la pile de navigation et la restaure dans son état d'origine. Cependant, les données à l'intérieur des contrôleurs (texte saisi, position de défilement) doivent être explicitement sauvegardées par le développeur.

State Restoration sous Android (SavedStateHandle)

Sous Android, l'approche moderne de State Restoration repose sur SavedStateHandle — un composant de la bibliothèque AndroidX Lifecycle. SavedStateHandle est accessible dans ViewModel et sauvegarde et restaure automatiquement les données lors des changements de configuration (rotation de l'écran) et du redémarrage du processus. Les données sont stockées dans un Bundle et sérialisées automatiquement.

SavedStateHandle se comporte comme un magasin clé-valeur avec prise en charge de LiveData. Lors des changements de configuration, les données sont automatiquement sauvegardées et restaurées. Pour prendre en charge le redémarrage du processus, le ViewModel doit être créé via SavedStateViewModelFactory — cela permet au ViewModel de survivre à l'arrêt complet de l'application.

class SearchViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    companion object {
        private val KEY_QUERY = string("search_query")
    }

    fun getSearchQuery(): String? = savedStateHandle[KEY_QUERY]

    fun saveSearchQuery(query: String) {
        savedStateHandle[KEY_QUERY] = query
    }
}

Implémentation de State Restoration en code

L'implémentation pratique de State Restoration nécessite de prendre en compte plusieurs aspects : choisir le bon stockage, déterminer la quantité de données à sauvegarder et tester divers scénarios d'arrêt. Examinons une implémentation étape par étape pour une application Flutter utilisant le package state_restoration.

class RestorableSearchField extends RestorableProperty<String> {
  String _value = '';

  @override
  String get value => _value;

  @override
  void set value(String newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  @override
  String? toPrimitives() => _value;

  @override
  void fromPrimitives(String? data) {
    _value = data ?? '';
  }
}

Lors de l'implémentation, il est important de se rappeler les limites de sauvegarde. Tous les champs de l'interface utilisateur n'ont pas besoin d'être restaurés. Une position de défilement dans une longue liste — oui. Un état d'animation temporaire — non. Le développeur doit choisir consciemment quelles données sont critiques pour l'expérience utilisateur et lesquelles peuvent être réinitialisées en toute sécurité sans perte de confort.

Tester State Restoration est une tâche distincte qui nécessite de simuler l'arrêt du processus. Sous Android, cela peut être fait via la commande adb shell am kill ; sous iOS, via la simulation d'arrêt dans Xcode. Les frameworks de test d'interface utilisateur, tels qu'Espresso et XCTest, fournissent des méthodes spéciales pour vérifier la restauration d'état.

Bonnes pratiques de State Restoration

La première règle — sauvegardez des identifiants, pas des données. Au lieu de sauvegarder l'objet complet avec cent champs, sauvegardez son identifiant unique et, lors de la restauration, chargez les données réelles depuis la base de données ou l'API. Cela économise de l'espace dans le Bundle et garantit la fraîcheur des données au moment de la restauration.

La deuxième règle — testez tous les scénarios. Vérifiez la restauration après une rotation d'écran, après une minimisation et un retour une heure plus tard, après que le système a arrêté l'application par manque de mémoire. Chaque scénario peut se comporter différemment selon l'état du système d'exploitation et les ressources disponibles.

La troisième règle — utilisez des mécanismes système, pas des mécanismes personnalisés. iOS et Android fournissent des API intégrées pour State Restoration optimisées pour leur plateforme spécifique. Une implémentation personnalisée via SharedPreferences ou UserDefaults peut entraîner des problèmes de synchronisation et un comportement inattendu lors de la restauration.

La quatrième règle — gérez l'absence d'état. Lors du premier lancement ou après l'effacement des données, l'état peut être absent. L'interface utilisateur doit fonctionner correctement dans son état initial sans lever d'exceptions. Vérifiez toutes les données sauvegardées pour null avant utilisation et fournissez des valeurs par défaut.

La cinquième règle — documentez les clés sauvegardées. Lorsqu'un projet comporte des dizaines d'écrans et que chacun sauvegarde plusieurs champs, sans gestion centralisée des clés, le chaos s'installe. Créez une seule classe ou un fichier avec des constantes de clé pour State Restoration dans chaque module. Cela simplifie la maintenance et empêche les écrasements accidentels de données lors du refactoring.