Présentation

La restauration d'état est un pilier fondamental du développement moderne d'iOS qui influence directement la perception de la fiabilité et du polissage de votre application. Lorsqu'un utilisateur passe à une autre application, reçoit un appel téléphonique ou active l'appareil, il s'attend à revenir exactement là où il l'a laissé, non à un écran vide ou à une forme perdue. La restauration d'état d'application appropriée assure cette continuité, réduisant la frustration et renforçant la confiance. Au-delà de la commodité de base de l'utilisateur, la restauration d'état joue également un rôle clé dans le maintien d'une expérience transparente après une résiliation initiée par le système, comme lorsque iOS a besoin de récupérer la mémoire.

Comprendre le processus de restauration de l ' État

Concepts clés et aperçu de l'API

La restauration d'état dans iOS est construite sur un ensemble coopératif d'API UIKit qui permettent à votre application de préserver et de restaurer l'état de son interface utilisateur et les données associées. Le mécanisme de base tourne autour du protocole , que vos contrôleurs de vue et d'autres objets adoptent pour encoder et décoder leur état. Chaque objet restituable doit avoir un identificateur de restauration, une chaîne unique que UIKit utilise pour associer l'état sauvegardé à l'instance d'objet correcte à travers les lancements. Les données d'état sont sérialisées en utilisant , le même mécanisme d'archivage utilisé pour et . UIKit gère automatiquement l'enregistrement et le chargement de l'archive de restauration — généralement un fichier plist — aux moments appropriés, comme lorsque les transitions d'applications vers l'arrière-plan ou est terminée.

Restauration d'État par scène dans iOS moderne

Depuis iOS 13, le paradigme multitâches est passé d'un cycle de vie basé sur l'application à un cycle de vie basé sur la scène avec l'introduction de et . Le système de restauration d'état a été mis à jour pour supporter plusieurs scènes, chacune avec sa propre archive de restauration. Au lieu de se fier uniquement aux méthodes des délégués de l'application et , vous utilisez maintenant les méthodes correspondantes des délégués de la scène : et . Chaque scène obtient une archive de restauration unique liée à sa session de scène. Ce changement nécessite un changement de pensée : la restauration n'est plus un concept d'application unique mais une responsabilité par scène.

Préservation par l ' État

Identification des caractéristiques de restauration

La première étape vers la préservation de l'état consiste à attribuer des identifiants de restauration à chaque contrôleur de vue que vous souhaitez restaurer. Ces identifiants peuvent être définis dans Interface Builder via le champ Identification de restauration ou programmatiquement en utilisant la propriété . Par exemple, un contrôleur de vue de paramètres peut avoir l'identifiant . L'identifiant doit être unique dans le contexte de la scène ou de l'application, selon votre architecture. UIKit utilise l'identificateur de restauration pour créer la hiérarchie d'objet pendant la restauration. Si les identifiants sont manquants ou dupliqués, la restauration échouera ou produira des résultats incorrects. Une bonne pratique consiste à définir les identifiants de restauration comme constantes dans un enum ou une structure dédié.

État codant avec encodeÉtat reservable

Une fois les identifiants de restauration en place, vous implémentez dans chaque contrôleur de vue qui contribue à l'état sauvegardé. À l'intérieur de cette méthode, vous écrivez les données nécessaires pour restaurer l'interface et le contexte du contrôleur de vue à l'instance fournie . Par exemple, un contrôleur de vue de formulaire peut enregistrer l'entrée du champ texte actuel, l'index sélectionné d'un sélecteur ou la position du défilement d'une vue de table. Encodez seulement ce qui est essentiel — évitez de sauvegarder de grands ensembles de données ou des images en cache. Utilisez , ] et des méthodes similaires. Gardez à l'esprit que le codeur est automatiquement archivé et ne doit pas être utilisé pour des informations sensibles, car le fichier de restauration est stocké sur disque.

override func encodeRestorableState(with coder: NSCoder) {
 super.encodeRestorableState(with: coder)
 coder.encode(selectedSegmentIndex, forKey: "selectedSegmentIndex")
 coder.encode(searchQuery, forKey: "searchQuery")
}

Préserver l'État de la demande dans l'application ou le délégué de la scène

En plus de l'encodage par le contrôleur de vue, vous devez indiquer à UIKit si vous devez enregistrer l'état au niveau de l'application ou de la scène. Pour les applications utilisant le cycle de vie de l'application, implémenter et retourner . Pour les applications basées sur la scène, utilisez la méthode de délégation de scène pour fournir une qui contient des informations de restauration légères. Le levage lourd — l'état du contrôleur de vue complète — est automatiquement sauvegardé par UIKit lorsqu'il code l'ensemble de la hiérarchie de restauration. Cependant, vous pouvez personnaliser les métadonnées stockées en implémentant ou l'équivalent de la scène. Cette méthode vous permet d'ajouter l'état de l'application ou de la scène à l'échelle de l'ensemble avant que UIKit n'écrisse l'archive.

Rétablissement de l ' État d ' exécution

Décodage de l'état avec décodageÉtat reservable

Lorsque l'application lance et UIKit détermine qu'une restauration doit se produire (basée sur la valeur de retour de ou de son homologue de scène), elle reconstruise la hiérarchie du contrôleur de vue en utilisant le storyboard ou l'instantanéation programmatique, puis appelle sur chaque contrôleur de vue restituable. Dans cette méthode, vous relisez les valeurs encodées en utilisant , , etc., et les appliquez pour restaurer l'interface utilisateur à son état précédent.

override func decodeRestorableState(with coder: NSCoder) {
 super.decodeRestorableState(with: coder)
 selectedSegmentIndex = coder.decodeInteger(forKey: "selectedSegmentIndex")
 searchQuery = coder.decodeObject(forKey: "searchQuery") as? String ?? ""
}

Restauration de la Hiérarchie du Contrôleur

La reconstruction de la hiérarchie du contrôleur de vue se produit automatiquement si vous utilisez des storyboards et que l'identificateur de restauration correspond à un identifiant de storyboard. Pour les hiérarchies créées par programme, vous devez implémenter dans le délégué de l'application ou utiliser l'équivalent de scene delegator. Cette méthode devrait activer le contrôleur de vue avec le chemin d'identification de restauration donné et le retourner. UIKit continue ensuite de traverser pour restaurer les contrôleurs de vue enfant. Assurez-vous que l'identificateur de restauration de la vue retournée correspond au dernier composant de chemin pour éviter une récursion infinie.

Gestion de la cohérence des données

La restauration de l'état peut être fragile lorsque les dépendances de données changent entre les lancements d'applications. Par exemple, un utilisateur peut avoir navigué vers une vue détaillée d'un élément qui a été supprimé par la suite du serveur. Validez toujours que l'état restauré a toujours un sens avant de l'appliquer. Si les données codées se rapportent à un objet modèle qui n'existe plus, retournez à un état par défaut, comme afficher une vue vide ou une nouvelle liste. De même, évitez de restaurer l'état qui dépend des requêtes réseau ou des grandes récupérations de bases de données qui peuvent ne pas être terminées dans le temps.

Sujets avancés

Restauration d'État avec SwiftUI

L'API clé est l'enveloppeur de propriété , qui persiste automatiquement de petites quantités de données par scène pour les userDefaults. Par exemple, vous pouvez stocker l'index d'onglet sélectionné ou un terme de recherche. Pour un état plus complexe, SwiftUI s'intègre au protocole et aux API . Utilisez le modificateur pour gérer la restauration à partir d'activités de main ou de système. SwiftUI prend également en charge la restauration d'état pour et automatiquement lorsque vous utilisez des identifiants appropriés. Cependant, sa restauration est plus limitée que celle d'UIKit. Il ne permet pas automatiquement de sauvegarder et de restaurer la hiérarchie du contrôleur de vue intégrale. Vous devez explicitement persister l'état important en utilisant , , ou un calque de persistance personnalisé.

Restauration dans les hiérarchies de vue complexes

Chaque contrôleur de la vue enfant doit avoir son propre identifiant de restauration et coder son propre état. De plus, le conteneur parent doit gérer correctement la restauration de ses enfants. Par exemple, un doit mettre en œuvre [ pour stocker l'index de la page actuelle et utiliser le chemin de l'identificateur de restauration pour recréer les enfants commandés. De même, et doivent gérer automatiquement la restauration de leurs contrôleurs de la vue enfant si les identifiants de restauration sont correctement assignés. Toujours tester ces hiérarchies en restituant l'application et en relançant; utiliser le Simulator -=Trigger Memory Warning= pour simuler la terminaison.

Chargement des données asynchrones

Un écueil commun consiste à restaurer l'état qui dépend de données asynchrones, comme une vue de table qui montrait les résultats d'une requête réseau. Le processus de restauration se produit synchronement pendant le lancement, avant que les appels réseau ne soient lancés. Si vous essayez de remplir un contrôleur de vue avec des données sauvegardées qui n'est pas encore disponible, la restauration apparaîtra incomplète ou vide. La solution est de restaurer uniquement les metadata nécessaires pour retoucher les données (par exemple, l'identificateur de la dernière vue, ou une chaîne de requête). Ensuite, dans ou ], lancez une récupération et une mise à jour asynchrones de l'interface utilisateur une fois les données arrivées. Vous pouvez également combiner la restauration d'état avec des tâches de fond pour les caches pré-chauffés, mais gardez l'interface utilisateur sensible.

Restauration de l'État d'essai

Pour des scénarios plus réalistes, activez l'option -Simula Memory Warning , dans le menu Déboguer pendant que l'application est en arrière-plan. Cela force le système à mettre fin à l'application, et à relancer, la restauration de l'état devrait démarrer. De plus, testez avec différentes orientations de l'appareil, multitâchez les vues fractionnées et après des interruptions comme les appels téléphoniques. Utilisez les journaux de console pour vérifier les avertissements ou les erreurs liés à la restauration, comme les identifiants de restauration manquants.

Meilleures pratiques pour la restauration de l'État robuste

  • Conservez les données de restauration minimales: Encodez uniquement les informations nécessaires pour reconstruire le contexte de l'utilisateur — évitez de sauvegarder de grands blobs, des images ou des graphiques de modèle entiers.
  • Utilisez des identifiants de restauration uniques et stables[ : Chaînes de code dur ou définissez des constantes; n'utilisez jamais d'identifiants générés automatiquement qui peuvent changer entre les build.
  • Validation de l'état restauré : Vérifiez toujours que les données restaurées sont toujours valides et que les objets du modèle référencé existent avant d'appliquer l'état.
  • Procédez à une version en main gracieusement: Si votre application change de modèle de données, implémentez des vérifications de version dans votre logique d'encodage/de décodage pour éviter les pannes.
  • Combinez avec NSUserActivity[: Pour une restauration légère (p. ex., pour continuer un appel FaceTime ou une recherche), utilisez en même temps que la restauration complète pour obtenir les meilleurs résultats.
  • Respecter la confidentialité des utilisateurs[: Ne jamais encoder des données sensibles telles que les mots de passe, les numéros de carte de crédit ou les renseignements personnels sur la santé dans les archives de restauration.
  • Set classe de restauration pour les contrôleurs de vue instantanés programmatiquement: Si vous créez des contrôleurs de vue sans storyboard, définissez leur propriété à une classe qui sait comment les injecter.
  • Test avec les arguments de lancement: Utilisez l'argument de lancement pour inspecter l'archive de restauration pendant le développement.

Pièges courants et comment les éviter

  • Désignations de restauration manquantes sur les contrôleurs de vue enfant : Chaque contrôleur de vue qui apparaît dans la hiérarchie restaurée doit avoir un identifiant de restauration, y compris ceux intégrés dans les contrôleurs de navigation ou les contrôleurs de barres d'onglets. Sinon, UIKit saute l'ensemble du sous-arbre.
  • État encodé mais jamais décodé parce que la hiérarchie de vue a changé: Si vous restructurez votre storyboard ou changez l'ordre des contrôleurs de vue, l'état précédemment encodé peut devenir abandonné. Mitigatez ceci en utilisant le décodage optionnel et en revenant aux valeurs par défaut.
  • La restauration a tenté de procéder à une nouvelle installation ou après la mise à jour de l'application: La restauration de l'état n'est invoquée que lorsque l'application était déjà en cours d'exécution.
  • État de l'écriture pendant le décodage: Évitez d'appeler de l'intérieur .
  • Ignorer les connexions et les déconnexions de scène: Dans les applications basées sur la scène, la restauration d'état s'applique par scène.
  • Restoration des opérations asynchrones trop tôt: Ne comptez pas sur les appels réseau qui se terminent avant la fin de la restauration.

Ressources externes et lectures complémentaires

For an in-depth understanding of UIKit’s state restoration, start with Apple’s official documentation on Preserving Your App’s UI. The WWDC 2014 session “State Restoration in Practice” covers many real-world scenarios. For SwiftUI-specific guidance, refer to the SceneStorage documentation. A comprehensive third-party tutorial can be found on Apple View Controller Programming Guide (archivé mais toujours pertinent) contient des conseils détaillés sur les identifiants de restauration et le processus de désarchivage.

Conclusion

La restauration de l'état de l'application n'est pas une fonctionnalité optionnelle, c'est une partie attendue d'une application iOS bien conçue. Les utilisateurs investissent du temps dans la navigation de votre interface, le remplissage des formulaires et l'exploration du contenu; la capacité de reprendre sans heurt cette expérience après une interruption a une incidence directe sur la satisfaction et la rétention de l'utilisateur. En comprenant les API de restauration de l'état de l'UIKit, en mettant en œuvre des identifiants de restauration appropriés, en encodant uniquement les données nécessaires et en traitant des cas de bord comme les changements de données et les opérations asynchrones, vous pouvez fournir une expérience robuste qui se sent fiable et polie.

Rappelez-vous que le but n'est pas de reproduire chaque pixel de la session précédente mais de recréer l'utilisateurintent.Une restauration d'état réussie laisse l'utilisateur se demander si l'application a jamais vraiment fermé — et c'est le compliment le plus élevé.