Share
Garder les données des applications synchronisées sur tous les appareils est une tâche complexe et ardue. Heureusement, c’est précisément pourquoi Apple a construit iCloud. Dans cette série Tuts + Premium, vous apprendrez le fonctionnement de iCloud et comment vos applications peuvent partager des données en toute transparence sur plusieurs appareils..
Dans les versions précédentes de cette série, nous avons restructuré notre exemple d’application pour passer de iCloud Key-Value Storage à iCloud Document Storage. Le stockage de documents iCloud est beaucoup plus flexible que le stockage à valeur clé et convient donc mieux aux applications nécessitant beaucoup de données. Core Data est un cadre de persistance conçu pour les applications qui gèrent de grandes quantités de données et des modèles de données complexes. Au fil des années, Core Data a gagné ses galons et est reconnu comme un cadre fiable et flexible pour la persistance des données. Cette série ne serait pas complète sans discuter de Core Data et de son intégration avec iCloud.
En termes de données de base, il existe deux types d'applications: (1) les applications basées sur les documents et (2) les applications de type bibliothèque. Les applications basées sur les documents, telles que l'application Pages d'Apple, gèrent les documents sauvegardés par un magasin Core Data. Les applications de type bibliothèque, telles que l'application de musique intégrée de l'iPhone, utilisent un seul magasin persistant utilisé dans l'application..
Dans ce didacticiel, nous aborderons les deux types d’application et exposerai un aperçu de haut niveau de la manière dont chaque type d’application peut s’intégrer à iCloud. Les données de base sont un sujet très vaste et l’un des aspects les plus avancés du développement Mac et iOS. Ce tutoriel ne fera qu'effleurer la surface de ce qui est possible et des options d'intégration disponibles avec iCloud.
UIManagedDocument est une sous-classe concrète de UIDocument et est conçu pour répondre aux besoins des applications Core Data basées sur des documents. Pour les applications basées sur des documents, UIManagedDocument offre le meilleur de deux mondes, (1) UIDocumentFacilité d'utilisation et (2) prise en charge intégrée de Core Data. Il est important de mentionner que UIManagedDocument peut être utilisé même si l'intégration iCloud n'est pas nécessaire. Même si UIManagedDocument souvent mentionné dans le contexte de iCloud, il est utile de prendre un moment pour souligner les avantages de la UIManagedDocument classe elle-même.
Tout comme sa super classe, UIDocument, UIManagedDocument rend la gestion des documents facile et directe. La principale différence avec UIDocument est-ce UIManagedDocument vise spécifiquement les données de base. Tous les deux UIDocument et UIManagedDocument ont beaucoup à offrir hors de la boîte. Rappelez-vous du tutoriel précédent que UIDocument Les fonctions de sauvegarde automatique, de chargement et de sauvegarde sont gérées dans une file d’arrière-plan tout en résumant les détails les plus importants. Si vous décidez d'utiliser des données de base dans une application basée sur des documents, il est recommandé d'utiliser UIManagedDocument même si iCloud n'est pas dans la liste des fonctionnalités de votre application.
Avant l'introduction de UIManagedDocument, la pile de données de base était traditionnellement configurée et configurée dans le délégué d'application. Ce n'est plus nécessaire lorsque vous utilisez UIManagedDocument. Une des subtilités de la UIManagedDocument La classe est sa pile de données centrale intégrée. Après avoir initialisé une instance de UIManagedDocument, une pile de données de base complète est à votre disposition. UIManagedDocumentL'interface de 'expose un contexte d'objet géré ainsi que le coordinateur de magasin persistant et le modèle d'objet géré. La configuration du coordinateur de magasin persistant est aussi simple que de fournir un dictionnaire avec des options comme vous le faites lorsque vous initialisez manuellement un coordinateur de magasin persistant..
Comme son nom l'indique, UIManagedDocument est une sous-classe concrète de UIDocument, ce qui signifie qu'il peut être utilisé tel quel, sans qu'il soit nécessaire de sous-classer UIDocument. Dans les coulisses, UIManagedDocument agrège automatiquement les modèles d'objet géré qu'il trouve dans votre lot d'applications et prépare une pile de données de base avec laquelle vous pourrez travailler. Si votre application a des exigences plus complexes, c'est à vous de sous-classer UIManagedDocument pour répondre à ces exigences.
Toute personne familiarisée avec Core Data sait que ces modifications sont validées dans le magasin persistant en envoyant au contexte de l'objet géré un message. enregistrer: message. Ce n'est plus nécessaire lorsque vous utilisez UIManagedDocument. Non seulement ce n'est pas nécessaire, mais il faut éviter. La raison en est que, sous le capot, UIManagedDocument gère un contexte d'objet géré privé. Ce contexte d'objet géré privé gère un contexte d'objet géré enfant, qui est le contexte d'objet géré exposé via UIManagedDocumentL'interface publique de. En envoyant au contexte de l'objet géré par l'enfant une enregistrer: message, les modifications ne sont validées que dans le contexte de l'objet géré parent et non dans le magasin persistant géré par le contexte de l'objet géré parent.
En bref, vous devriez utiliser le familier UIDocument méthodes pour enregistrer les modifications apportées au magasin persistant, le reste est traité en arrière-plan. Il y a une raison pour laquelle UIManagedDocument hérite de UIDocument!
Les applications basées sur une bibliothèque, telles que les applications intégrées de musique et de photos de l'iPhone, gèrent généralement une pile Core Data avec un coordinateur de stockage persistant et un magasin persistant..
Vous vous demandez peut-être comment Core Data fonctionne avec iCloud sous le capot. Cela dépend du type de magasin que vous utilisez, c’est-à-dire (1) un magasin SQLite ou (2) un magasin binaire (atomique). Dans la majorité des cas d'utilisation, il est recommandé d'opter pour SQLite. Cependant, si vous traitez de petites quantités de données, un magasin binaire est également une option. À la lumière d'iCloud, l'inconvénient majeur d'un magasin binaire est que chaque changement entraîne le remplacement de tout le magasin. Non seulement cela est inefficace, mais cela peut également avoir des conséquences importantes sur les performances si la taille du magasin grandit. Dans la suite de cette discussion, je me concentrerai sur SQLite en tant que magasin de sauvegarde..
Avec SQLite comme magasin de sauvegarde, l’avantage majeur est que les modifications sont propagées de manière incrémentielle au lieu de remplacer l’ensemble du magasin par chaque modification validée. Pour comprendre comment Core Data et iCloud fonctionnent ensemble, il est important de savoir que la base de données SQLite n'est pas stockée dans iCloud. Au lieu de cela, chaque changement est enregistré dans ce qu'on appelle journaux de transactions et ces journaux sont utilisés pour propager les modifications sur les périphériques. Les journaux de transactions sont légers et permettent un processus de synchronisation précis, rapide et efficace. Les journaux de transaction sont stockés dans un répertoire du conteneur iCloud. L’emplacement exact peut être spécifié en réglant la NSPersistentStoreUbiquitCContentURLKey clé dans le dictionnaire d'options passé au coordinateur de magasin persistant.
Un autre aspect essentiel de la synchronisation est de maintenir l'interface utilisateur à jour. Lorsque vous utilisez des données de base, ceci peut être accompli en enregistrant les contrôleurs appropriés en tant qu’observateur pour. NSPersistentStoreDidImportUbiquitousContentChangesNotification notifications, qui sont envoyées chaque fois qu'une modification à distance est propagée. En fonction des modifications, votre application peut mettre à jour l'interface utilisateur pour refléter les modifications validées dans son magasin persistant local..
Un autre avantage clé de Core Data est le contrôle granulaire que vous avez sur vos données, notamment en ce qui concerne la fusion des données, élément essentiel du travail avec iCloud. Grâce à cette granularité, qui n'est possible que grâce à l'utilisation de journaux de transactions, l'essentiel de la fusion est effectué automatiquement par Core Data..
Le fil conducteur de cette série est de savoir comment vos applications peuvent tirer parti d’iCloud et comment s’intégrer à iCloud. Je souhaite terminer cette série en exposant quelques mises en garde que vous pouvez surveiller lorsque vous ajoutez le support iCloud à une application. Dans les deuxième et troisième parties de cette série, je vous ai montré comment utiliser NSFileManagerde URLForUbiquityContainerIdentifier: méthode permettant d’obtenir une référence à un conteneur iCloud spécifique pour stocker des données dans iCloud. Dans nos exemples, nous avons toujours supposé qu'iCloud était activé sur les appareils avec lesquels nous travaillions, mais
ce ne sera pas toujours le cas. Il est donc important de mettre en place une solution de secours pour les situations où iCloud n'est pas activé. Voici deux exemples pour mieux illustrer ces mises en garde..
Le premier exemple est lorsqu'un utilisateur ne dispose pas d'un compte iCloud ou ne s'est pas connecté avec son compte iCloud sur le périphérique. Cela signifie que votre application ne peut pas accéder au conteneur iCloud dans lequel elle a l'intention de stocker des données. Elle devient encore plus complexe lorsqu'elle active iCloud après avoir utilisé votre application pendant quelques semaines. L'utilisateur s'attendra à ce que ses données soient synchronisées sur ses appareils. En d'autres termes, vous aurez besoin d'un moyen de transférer les données du sandbox de l'application vers le conteneur iCloud..
Le deuxième exemple porte sur la persistance des données. Que se passe-t-il lorsqu'un utilisateur a activé iCloud sur son appareil, mais décide après quelques semaines de se connecter avec un autre compte iCloud? Les données stockées dans le conteneur iCloud ne sont plus disponibles pour l'utilisateur puisqu'un autre compte iCloud est utilisé. Il s'agit d'une mesure de sécurité mise en place par Apple. Les données sont liées à un compte iCloud, pas à un appareil. Les données ne sont donc pas accessibles lorsqu'un autre compte iCloud est utilisé. Il est rare qu'un utilisateur ait plusieurs comptes iCloud, mais il est important d'être conscient de cette possibilité et de ses conséquences..
J'espère que cette série sur iCloud vous a donné une bonne idée de ce qu'est iCloud et de ce qu'il peut vous apporter en tant que développeur. L'idée de base derrière iCloud est simple et son adoption est relativement facile si le modèle de données de votre application n'est pas trop complexe. Cependant, ce dernier versement a montré que l’intégration iCloud peut devenir très complexe lorsque la complexité du modèle de données de votre application augmente..
Accentsconagua