Werken met iCloud integratie van kerngegevens

Het bijhouden van toepassingsgegevens gesynchroniseerd tussen apparaten is een complexe en ontmoedigende taak. Gelukkig is dat precies waarom Apple iCloud heeft gebouwd. In deze Tuts + Premium-serie leert u hoe iCloud werkt en hoe uw applicaties naadloos gegevens kunnen delen op meerdere apparaten.


Ook verkrijgbaar in deze serie:

  1. Werken met iCloud: introductie
  2. Werken met iCloud: opslag van sleutel / waarde
  3. Werken met iCloud: documentopslag
  4. Werken met iCloud: integratie van kerngegevens

In de vorige delen van deze serie hebben we onze voorbeeldtoepassing aangepast om over te schakelen van iCloud Key-Value Storage naar iCloud-documentopslag. iCloud's Document Storage is veel flexibeler dan Key-Value Storage en daarom beter geschikt voor data-zware applicaties. Core Data is een persistentiekader dat is gebouwd voor applicaties die grote hoeveelheden data en complexe datamodellen beheren. In de loop der jaren heeft Core Data zijn sporen verdiend en staat het bekend als een betrouwbaar en flexibel raamwerk voor gegevenspersistentie. Deze serie zou niet compleet zijn zonder bespreking van Core Data en de integratie ervan met iCloud.


Toepassingen van kerngegevens

In termen van Core Data zijn er twee soorten applicaties, (1) document-gebaseerde applicaties en (2) library-achtige applicaties. Documentgebaseerde applicaties, zoals Apples Pages-applicatie, beheren documenten die worden ondersteund door een Core Data-winkel. Toepassingen in bibliotheekstijl, zoals de ingebouwde muziekapp van de iPhone, maken gebruik van één permanente winkel die in de hele applicatie wordt gebruikt.

In deze zelfstudie zal ik beide soorten toepassingen bespreken en een overzicht op hoog niveau schetsen van hoe elk toepassingstype kan worden geïntegreerd met iCloud. Core Data is een zeer breed onderwerp en een van de geavanceerdere aspecten van Mac- en iOS-ontwikkeling. Deze tutorial zal alleen het oppervlak van wat mogelijk is en de integratie-opties die beschikbaar zijn met iCloud krassen.


Document-gebaseerde applicaties

UIManagedDocument

UIManagedDocument is een concrete subklasse van UIDocument en is afgestemd op de behoeften van documentgebaseerde Core Data-applicaties. Voor document-gebaseerde applicaties, UIManagedDocument biedt het beste van twee werelden, (1) UIDocumentgebruiksgemak en (2) ingebouwde ondersteuning voor Core Data. Het is de moeite waard om dat te vermelden UIManagedDocument kan ook worden gebruikt als iCloud-integratie niet nodig is. Hoewel UIManagedDocument wordt vaak genoemd in de context van iCloud, het is nuttig om een ​​moment te nemen en de voordelen van de. te onderstrepen UIManagedDocument klasse zelf.

Net als zijn superklasse, UIDocument, UIManagedDocument maakt documentbeheer eenvoudig en duidelijk. Het belangrijkste verschil met UIDocument is dat UIManagedDocument is specifiek gericht op Core Data. Beide UIDocument en UIManagedDocument hebben veel te bieden uit de doos. Vergeet niet van de vorige tutorial dat UIDocument beschikt over automatische opslag en laad- en opslagbewerkingen worden in een achtergrondwachtrij verwerkt terwijl de nitty-zanderige details worden weggevaagd. Als u beslist om Core Data te gebruiken in een document-gebaseerde applicatie, is het aan te bevelen om gebruik te maken van UIManagedDocument zelfs als iCloud niet op de functielijst van uw toepassing staat.

Voor de introductie van UIManagedDocument, de Core Data-stack werd van oudsher opgezet en geconfigureerd in de applicatiedelegate. Dit is niet langer nodig tijdens het gebruik UIManagedDocument. Een van de voordelen van de UIManagedDocument klasse is de ingebouwde Core Data-stack. Na het initialiseren van een instantie van UIManagedDocument, een complete Core Data-stack is voor u beschikbaar. UIManagedDocumentDe interface toont zowel een beheerde objectcontext als de persistente winkelcoördinator en het beheerde objectmodel. Het configureren van de permanente winkelcoördinator is net zo eenvoudig als het leveren van een woordenboek met opties, net als bij het handmatig initialiseren van een persistente winkelcoördinator.

Zoals de naam al aangeeft, UIManagedDocument is een concrete subklasse van UIDocument, wat betekent dat het kan worden gebruikt zoals het is, zonder de noodzaak om te subclass UIDocument. Achter de schermen, UIManagedDocument verzamelt automatisch beheerde objectmodellen automatisch in uw toepassingsbundel en bereidt een Core Data-stack voor waarmee u kunt werken. Als uw toepassing complexere vereisten heeft, is het aan u om te subclassiseren UIManagedDocument om aan deze vereisten te voldoen.

Makkelijk te gebruiken

Iedereen die bekend is met Core Data weet dat wijzigingen zijn doorgevoerd in de permanente winkel door de beheerde objectcontext a te verzenden opslaan: bericht. Dit is niet langer nodig tijdens het gebruik UIManagedDocument. Dit is niet alleen niet nodig, het moet worden vermeden. De reden is dat, onder de motorkap, UIManagedDocument beheert een context van een privé beheerd object. Deze context van particulier beheerd object beheert een context van door kinderen beheerde objecten, de doorlopende context van het beheerde object UIManagedDocumentopenbare interface. Door de child managed object-context te verzenden a opslaan: bericht, zijn de wijzigingen alleen toegewezen aan de context van het ouderbeheerd object en niet aan het permanente archief dat wordt beheerd door de context van het ouderbeheerd object.

Kortom, je zou het vertrouwde moeten gebruiken UIDocument methoden om wijzigingen in de permanente winkel op te slaan, de rest wordt achter de schermen afgehandeld. Er is een reden waarom UIManagedDocument erft van UIDocument!


Op bibliotheken gebaseerde applicaties

Op bibliotheken gebaseerde applicaties, zoals de ingebouwde muziek- en fotoappentoepassingen van de iPhone, beheren meestal één Core Data-stack met één persistente winkelcoördinator en één permanente winkel.


Onder de motorkap

U vraagt ​​zich misschien af ​​hoe Core Data met iCloud onder de motorkap werkt. Dit is afhankelijk van het type winkel dat u gebruikt, dat wil zeggen (1) een SQLite- of (2) een binair (atomisch) archief. In de meeste gevallen wordt het aanbevolen om te kiezen voor SQLite. Als u echter te maken krijgt met kleine hoeveelheden gegevens, is een binaire winkel ook een optie. In het licht van iCloud is het grootste nadeel van een binaire winkel dat elke wijziging ertoe leidt dat de hele winkel wordt vervangen. Dit is niet alleen inefficiënt, maar kan ook resulteren in aanzienlijke gevolgen voor de prestaties als de winkel in omvang toeneemt. In de rest van deze discussie zal ik me richten op SQLite als de back-upwinkel.

Met SQLite als de back-upopslag, is het grote voordeel dat wijzigingen stapsgewijs worden doorgegeven in plaats van de hele winkel te vervangen door elke toegewijde wijziging. Om te begrijpen hoe Core Data en iCloud samenwerken, is het belangrijk om te weten dat de SQLite-database niet in iCloud is opgeslagen. In plaats daarvan wordt elke wijziging geregistreerd in zogenaamde transactielogboeken en die logboeken worden gebruikt om wijzigingen op verschillende apparaten door te geven. De transactielogboeken zijn licht van gewicht en resulteren in een fijnmazig, snel en efficiënt synchronisatieproces. De transactielogboeken worden opgeslagen in een map in de iCloud-container. De exacte locatie kan worden opgegeven door de NSPersistentStoreUbiquitousContentURLKey toets in het optieswoordenboek doorgegeven aan de blijvende winkelcoördinator.

Een ander essentieel aspect van synchronisatie is het up-to-date houden van de gebruikersinterface. Bij het gebruik van Core Data kan dit worden bereikt door de juiste controllers te registreren als een waarnemer voor NSPersistentStoreDidImportUbiquitousContentChangesNotification meldingen, die worden verzonden wanneer een externe wijziging wordt doorgevoerd. Op basis van de wijzigingen kan uw toepassing de gebruikersinterface bijwerken om de wijzigingen weer te geven die zijn doorgevoerd in de lokale persistente winkel.


Samenvoegen

Een ander belangrijk voordeel van Core Data is de gedetailleerde controle die u heeft over uw gegevens. Dit geldt met name voor het samenvoegen van gegevens, een essentieel onderdeel van het werken met iCloud. Dankzij deze granulariteit, die alleen mogelijk is dankzij het gebruik van transactielogboeken, gebeurt het merendeel van de samenvoegingen automatisch door Core Data.


Gedachten sluiten

De rode draad doorheen deze reeks is hoe uw applicaties kunnen profiteren van iCloud en hoe te integreren met iCloud. Ik wil deze serie beëindigen door enkele kanttekeningen te plaatsen waarop u mogelijk wilt letten bij het toevoegen van iCloud-ondersteuning aan een toepassing. In het tweede en derde deel van deze serie heb ik je laten zien hoe te gebruiken NSFileManager's URLForUbiquityContainerIdentifier: methode om een ​​verwijzing naar een specifieke iCloud-container te krijgen voor het opslaan van gegevens in iCloud. In onze voorbeelden gingen we er altijd van uit dat iCloud was ingeschakeld op de apparaten waarmee we werkten, maar
dit zal niet altijd het geval zijn. Het is daarom belangrijk om een ​​noodoplossing te hebben voor situaties waarin iCloud niet is ingeschakeld. Hieronder staan ​​twee voorbeelden om deze voorbehouden beter te illustreren.

Het eerste voorbeeld is wanneer een gebruiker geen iCloud-account heeft of ze niet met haar iCloud-account op het apparaat is ingelogd. Dit betekent dat uw applicatie geen toegang heeft tot de iCloud-container waarin het gegevens wil opslaan. Het wordt nog ingewikkelder wanneer zij iCloud inschakelt nadat uw applicatie een aantal weken is gebruikt. De gebruiker verwacht dat haar gegevens op al haar apparaten worden gesynchroniseerd. Met andere woorden, u zult een manier nodig hebben om de gegevens van de toepassingssandbox naar de iCloud-container over te brengen.

Het tweede voorbeeld richt zich op gegevenspersistentie. Wat gebeurt er wanneer een gebruiker iCloud op zijn apparaat heeft ingeschakeld, maar na een paar weken besluit om in te loggen met een ander iCloud-account? De gegevens die zijn opgeslagen in de iCloud-container zijn niet langer beschikbaar voor de gebruiker, omdat een ander iCloud-account wordt gebruikt. Dit is een beveiligingsmaatregel die is ingesteld door Apple. Gegevens zijn gekoppeld aan een iCloud-account, niet aan een apparaat. De gegevens zijn daarom niet toegankelijk als een ander iCloud-account wordt gebruikt. Het komt zelden voor dat één gebruiker meerdere iCloud-accounts heeft, maar het is belangrijk om op de hoogte te zijn van deze mogelijkheid en de gevolgen die dit kan hebben.


Conclusie

Ik hoop dat deze serie over iCloud je een goed idee heeft gegeven van wat iCloud is en wat het voor jou als ontwikkelaar kan doen. Het basisidee achter iCloud is eenvoudig en het gebruik van iCloud is relatief eenvoudig als het datamodel van uw toepassing niet te complex is. Deze laatste installatie heeft echter aangetoond dat iCloud-integratie erg complex kan worden als de complexiteit van het datamodel van uw toepassing toeneemt.