Core data fra Scratch: kjernedata Stack
34
Del
8
Del
Dette Cyber Monday Envato Tuts + kurs vil bli redusert til bare $ 3. Ikke gå glipp av
Dette innlegget er en del av en serie kalt kjernedata fra Scratch.Core data fra Scratch:. Datamodell
Innledning
The Core data rammeverket har eksistert i mange år. Det er brukt i tusenvis av søknader og av millioner av mennesker, både på iOS og OS X. Core-data blir vedlikeholdt av Apple og meget godt dokumentert. Det er en moden rammeverk som har bevist sin verdi over og over.
Kjerne data utnyttet Objective-C-språk og sin runtime, og pent integreres med Core Foundation rammeverket. Resultatet er en enkel å bruke rammeverk for å håndtere et objekt graf som er elegant å bruke og utrolig effektiv i form av minnebruk.
1. Forutsetninger
Selv om kjernedata rammeverket er ikke vanskelig i seg selv, hvis du er ny på iOS eller OS X utvikling, så anbefaler jeg at du først gå gjennom vår serie om iOS utvikling. Den lærer deg det grunnleggende av iOS utvikling, og på slutten av serien, vil du ha nok kunnskap til å ta på seg mer komplekse emner, for eksempel kjernedata.
Som jeg sa, Core data isn 't så komplisert eller vanskelig å plukke opp som de fleste utviklerne tror. Men jeg har lært at et solid fundament er avgjørende for å få fart på karrieren med kjernedata. Du må ha en riktig forståelse av kjernedata API for å unngå dårlige rutiner og sørge for at du ikke får problemer ved hjelp av rammeverket.
Hver komponent av Core data rammen har et bestemt formål og funksjon. Hvis du prøver å bruke Core data på en måte det ikke var designet for, vil du uunngåelig ende opp sliter med rammen.
Det jeg dekke i denne serien på kjernedata er aktuelt for iOS 6 + og OS X 10.8+, men vil fokuset være på iOS. I denne serien vil jeg jobbe med Xcode 5 og iOS 7 SDK.
2. Læringskurven
The Core data rammeverket kan virke skremmende i starten, men API er intuitivt og konsis når du forstår hvordan de ulike bitene i puslespillet passer sammen. Og det er akkurat der de fleste utviklerne får problemer. De prøver å bruke Core data før de har sett at velkjente puslespill, de vet ikke hvordan bitene i puslespillet passer sammen, og forholder seg til hverandre.
I denne artikkelen vil jeg hjelpe deg å bli kjent med den såkalte Kjernedata stable
. Når du forstår de sentrale aktørene i kjernedata stabelen, vil rammen føle mindre skremmende, og du vil selv begynne å nyte og sette pris på rammeverket er godt utformet API.
I motsetning til rammeverk som UIKit, som du kan bruke uten å forstå rammene i sin helhet, Core data krever en riktig forståelse av sine byggeklosser. Det er viktig å sette av litt tid til å bli kjent med rammeverk, som vi vil gjøre i denne opplæringen.
3. Hva er kjernedata?
Utviklere ny til Core data rammeverket ofte forveksler den med og forventer at det skal fungere som en database. Hvis det er én ting jeg håper du vil huske fra denne serien, er det at kjernedata er ikke en database, og du bør ikke forvente at det skal fungere som en.
Hva er kjernedata hvis det isn ' t en database? Kjernen data er modellen laget av programmet i videste forstand mulig. Det er det Model
i Model-View-Controller
mønster som gjennomsyrer iOS SDK.
Kjerne data er ikke databasen av søknaden din er heller ikke en API for vedvarende data til en database. Kjernen Data er et rammeverk som forvalter et objekt grafen. Det er så enkelt som det. Kjernen data kan
vedvare at objektet grafen ved å skrive det på harddisken, men det er ikke det primære målet av rammeverket.
4. Kjernen data Stack
Som jeg nevnte tidligere, er kjernen data stabelen midt i kjernen av data. Det er en samling av objekter som gjør kjernedata tick. De sentrale objekter av stabelen er klarte objektmodellen
, vedvarende butikken koordinator
, og en eller flere administrerte objekt sammenhenger
. La oss starte med å ta en rask titt på hver komponent.
NSManagedObjectModel
Den klarte objektmodellen er datamodell av søknaden. Selv om kjernedata er ikke en database, kan du sammenligne klarte objektmodellen til skjemaet fra en database, det vil si den inneholder informasjon om modeller eller enheter av objektet grafen, hvilke attributter de har, og hvordan de forholder seg til hverandre.
NSManagedObjectModel objekt vet om datamodell ved å laste en eller flere data modellfiler i løpet av sin initialisering. Vi vil ta en titt på hvordan dette fungerer i en liten stund.
NSPersistentStoreCoordinator
Som navnet indikerer, vedvarer NSPersistentStoreCoordinator objektet data til disk og sikrer vedvarende butikken (s ) og datamodellen er kompatible. Det formidler mellom den vedvarende butikken (e) og klarte objekt kontekst (s), og også tar seg av lasting og caching av data. Det er riktig. Kjernen data har caching bygget i.
Den vedvarende butikken koordinator er dirigent for kjernedata orkester. Til tross for sin viktige rolle i kjernedata stabelen, vi sjelden samhandle med det direkte.
NSManagedObjectContext
NSManagedObjectContext objekt forvalter en samling av modell objekter, forekomster av NSManagedObject klassen. Det er fullt mulig å ha flere administrerte objekt sammenhenger. Hver klarte objekt sammenheng er støttet av en vedvarende butikken koordinator.
Du kan se en administrert objekt sammenheng som en arbeidsbenk der du arbeide med modell stedene. Du laster dem, du manipulere dem, og lagre dem på at arbeidsbenken. Lasting og lagring er formidlet av den vedvarende butikken koordinator. Du kan ha flere arbeidsbenker, noe som er nyttig hvis søknaden er multithreaded, for eksempel.
Mens en administrert objektmodell og vedvarende butikken koordinator kan deles på tvers av tråder, bør aldri nås administrerte objekt sammenhenger fra en tråd annerledes enn den de ble opprettet på. Vi vil diskutere multithreading i mer detalj senere i denne serien.
5. Utforske kjernedata Stack
Trinn 1: Xcode Mal
La oss utforske Core data stable nærmere ved å ta en titt på Apples Xcode mal for kjernedata. Opprett et nytt prosjekt i Xcode 5 ved å velge New > Prosjekt ...
fra Fil
menyen. Velg Tøm Application
mal fra listen over iOS Søknad
rammer på venstre.
Navn prosjektet kjernedata
, sette Enheter
til iPhone
, og krysser av for Bruk kjernedata
. Fortell Xcode hvor du ønsker å lagre prosjektfiler og trykk på Opprett
Trinn 2:. Oversikt
Som standard setter Apple kode relatert til Core data i programmets delegat klasse, den TSPAppDelegate klassen i vårt eksempel. La oss starte med å utforske grenselandet mellom TSPAppDelegate
#import < UIKit /UIKit.h >interface TSPAppDelegate. UIResponder < UIApplicationDelegate >property (sterk, nonatomic) UIWindow * vinduet;property (skrivebeskyttet, sterk, nonatomic ) NSManagedObjectContext * managedObjectContext;property (skrivebeskyttet, sterk, nonatomic) NSManagedObjectModel * managedObjectModel;property (skrivebeskyttet, sterk, nonatomic) NSPersistentStoreCoordinator * persistentStoreCoordinator, - (void) saveContext, - (NSURL *) applicationDocumentsDirectory;end
Som du kan se, programmet delegat har en egenskap for hver komponent av Core data stable samt to praktiske metoder, saveContext og applicationDocumentsDirectory.
Merk at kjernedata eiendommene er merket som skrivebeskyttet, noe som betyr at tilfeller kan ikke endres av andre enn program delegat selv stedene.
Gjennomføringen av TSPAppDelegate er mye mer interessant og vil vise oss hvordan klarte objektmodellen, den vedvarende butikken koordinator, og klarte objekt sammenheng arbeidet sammen. La oss starte fra toppen
#import "TSPAppDelegate.h"@implementation TSPAppDelegate @ syntetisere managedObjectContext = _managedObjectContext;.synthesize ManagedObjectModel = _managedObjectModel;synthesize persistentStoreCoordinator = _persistentStoreCoordinator;
Fordi egenskapene i grensesnittet til TSPAppDelegate klasse er erklært som skrivebeskyttet, ingen setter-metoder opprettet. Den førstesynthesize direktivet forteller kompilatoren å knytte _managedObjectContext eksempel variabel med managedObjectContext egenskapen vi erklært i grensesnittet av klassen. Dette er et vanlig mønster til dovent laste stedene.
Du kan oppnå samme resultat ved å bruke en privat klasse forlengelse i klassen implementering fil. Ta en titt på følgende kodebiten. Desynthesize direktivene er ikke nødvendig hvis du bruker en privat klasse forlengelse
#import "TSPAppDelegate.h"@interface TSPAppDelegate ()property (sterk, nonatomic) NSManagedObjectContext * managedObjectContext;.property (Sterk, nonatomic) NSManagedObjectModel * managedObjectModel;property (sterk, nonatomic) NSPersistentStoreCoordinator * persistentStoreCoordinator;end
Selv om jeg vanligvis bruker og foretrekker en privat klasse forlengelse, vil vi holde med Apples mal for denne opplæringen
Sette opp. Kjernen data stack er faktisk ganske grei i forhold til metoder som må gjennomføres. Apple bruker ikke spessielle oppsettings metoder for å lage kjernedata stabelen. De tre viktige objekter av kjernedata stabelen skapes når de trengs. Med andre ord, de er dovent lastet eller instansiert.
I praksis betyr dette at gjennomføringen av TSPAppDelegate klassen ligner på hva du forventer i en søknad delegat klasse med unntak av saveContext og applicationDocumentsDirectory metoder, og getter metoder for managedObjectContext, managedObjectModel, og persistentStoreCoordinator. Det er i disse getter metoder som magien skjer. Det er en av de skjønnkjernedata, er oppsettet svært enkel og samspill med Core-data er like enkelt
Trinn 3:. Managed Object Context
Klassen du vil bruke mest ofte, bortsett fra NSManagedObject, når vi samhandler med kjernedata er NSManagedObjectContext. La oss starte med å utforske sin getter Anmeldelser - (NSManagedObjectContext *) managedObjectContext {if (_managedObjectContext = null!) {Return _managedObjectContext.; } NSPersistentStoreCoordinator * koordinator = [selvtillit persistentStoreCoordinator]; if (koordinator = null) {_managedObjectContext = [[NSManagedObjectContext Alloc] init]; [_managedObjectContext setPersistentStoreCoordinator: koordinator]; } Returnere _managedObjectContext;}
De tre første linjene av gjennomføringen er typisk for en getter som dovent laster instansvariabelen. Hvis NSManagedObjectContext objektet ikke er null, returnerer objektet. Det interessante bit er selve oppretting av NSManagedObjectContext objektet.
Vi først hente en referanse til utholdenhet butikken koordinator ved å ringe sin getter metoden. Den vedvarende butikken koordinator er også dovent lastet så vi får se om et øyeblikk. Dersom vedvarende butikken koordinator er ikke null, skaper vi en NSManagedObjectContext eksempel og sette persistentStoreCoordinator eiendom til vedvarende butikken koordinator. Det var ikke så vanskelig. Var det?
For å oppsummere, forvalter klarte objektet sammenheng en samling av modell objekter, forekomster av NSManagedObject klasse, og holder en referanse til et vedvarende butikken koordinator. Ha dette i bakhodet mens du leser resten av denne artikkelen
Trinn 4:. Vedvarende Butikk Koordinator
Som vi så et øyeblikk siden, er persistentStoreCoordinator metode som påberopes av managedObjectContext metoden. Ta en titt på gjennomføringen av persistentStoreCoordinator, men ikke la det skremme deg. Det er faktisk ikke så komplisert Anmeldelser - (NSPersistentStoreCoordinator *) persistentStoreCoordinator {if (_persistentStoreCoordinator = null!) {Return _persistentStoreCoordinator.; } NSURL * storeURL = [[selvtillit applicationDocumentsDirectory] URLByAppendingPathComponent: @ "Core_Data.sqlite"]; NSError * error = null; _persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: [selvtillit managedObjectModel]]; if ([_ persistentStoreCoordinator addPersistentStoreWithType: NSSQLiteStoreType konfigurasjon: nil URL: storeURL alternativer: null feil: & feil]!) {/* Sett denne implementeringen med kode for å håndtere feilen på riktig måte. abortere () fører bruk for å generere en krasj loggen og avslutte. Du bør ikke bruke denne funksjonen i en shipping-program, selv om det kan være nyttig under utvikling. Typiske årsaker til en feil her er: * Den vedvarende butikken er ikke tilgjengelig; * Skjemaet for den vedvarende butikken er uforenlig med dagens klarte objektmodellen. Sjekk feilmeldingen for å finne ut hva det egentlige problemet var. Dersom vedvarende butikken ikke er tilgjengelig, er det vanligvis noe galt med filen banen. Ofte er en fil nettadresse som peker inn i programmets ressurser katalog i stedet for en skrivbar katalog. Hvis du støter på skjema inkompatibilitet feil under utvikling, kan du redusere hyppigheten av: * Bare slette den eksisterende butikken: [[NSFileManagers defaultManager] removeItemAtURL: storeURL error: null] * Utføre automatisk lette migrasjon ved å sende følgende ordboken som alternativer parameter: @ {NSMigratePersistentStoresAutomaticallyOption:YES, NSInferMappingModelAutomaticallyOption:YES} Lett migrasjon vil bare fungere for et begrenset sett med skjemaendringer; konsultere "kjernedata Model Versjons og Data Migration Programming Guide" for detaljer. * /NSLog (@ "Uløste feil% @,% @", feil, [error Userinfo]); abortere (); } Returnere _persistentStoreCoordinator;}
Du vil nesten alltid ønsker å lagre Kjerne Datas objekt grafen til disk og Apples Xcode mal bruker en SQLite database for å oppnå dette
Når vi skaper vedvarende butikken koordinator i persistentStoreCoordinator, vi. angi plasseringen av butikken på disken. Vi starter ved å opprette en NSURL objekt som peker på at plassering i programmets sandkasse. Vi påberope applicationDocumentsDirectory, en hjelper metode, som returnerer plasseringen, en NSURL objekt, for Dokumenter katalog i programmets sandkasse. Vi føyer Core_Data.sqlite til plasseringen og lagre den i storeURL for senere bruk.
Som standard navnet på butikken på disken er den samme som navnet på prosjektet. Du kan endre dette til hva du vil om
NSURL * storeURL = [[selvtillit applicationDocumentsDirectory] URLByAppendingPathComponent: @ "Core_Data.sqlite"];.
Som jeg nevnte et øyeblikk siden, antyder den .sqlite utvidelse som butikken på disken er en SQLite database. Selv om kjernedata støtter flere butikktyper, er SQLite den desidert mest brukte store typen på grunn av sin hurtighet og pålitelighet
_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: [selvtillit managedObjectModel]];.
I neste trinn , instantiate vi den vedvarende butikken koordinator ved å påberope initWithManagedObjectModel: og passerer en NSManagedObjectModel eksempel. Vi ta en referanse til den administrerte objektmodellen ved å påberope seg managedObjectModel metoden, som vi vil utforske neste.
Vi har nå en forekomst av NSPersistentStoreCoordinator klassen, men det er ingen butikker knyttet til den ennå. Vi legger en butikk til den vedvarende butikken koordinator ved å kalle en ganske imponerende metode på det, addPersistentStoreWithType konfigurasjons: URL: alternativer: error :.
if ([_ persistentStoreCoordinator addPersistentStoreWithType:! NSSQLiteStoreType konfigurasjon: nil URL: storeURL alternativer: null feil : & error]) {}
Det første argumentet angir butikken type, NSSQLiteStoreType i dette eksempelet. Kjernen data støtter også binære butikker (NSBinaryStoreType) og en i minnet butikken (NSInMemoryStoreType).
Det andre argumentet forteller kjernen data som konfigurasjon for å bruke for den vedvarende butikken. Vi passerer i null, som forteller kjernedata for å bruke standardkonfigurasjonen. Det tredje argumentet er plasseringen av butikken, som er lagret i storeURL.
Den fjerde argument er en NSDictionary av alternativer som lar oss endre oppførselen til den vedvarende butikken. Vi vil se dette aspektet senere i denne serien og passere i null for nå. Det siste argumentet er en referanse til en NSError pekeren.
Hvis ingen feil dukker opp, returnerer denne metoden en NSPersistentStore objekt. Vi vil ikke holde en referanse til den vedvarende butikken, fordi vi ikke trenger å samhandle med det når det er lagt til den vedvarende butikken koordinator.
Hvis du legger den vedvarende butikken mislykkes, skjønt, betyr det at det er et problem med den vedvarende butikken på programmet, og vi må ta de nødvendige skritt for å løse problemet. . Når dette skjer og hvorfor det skjer er gjenstand for en fremtidig avdrag
I øyeblikket Abort er påberopt når addPersistentStoreWithType: konfigurasjon: URL: alternativer: feil: returnerer nil. Som kommentarene i hvis setningen forklarer, bør du aldri kalle abort i et produksjonsmiljø, fordi det krasjer programmet. Vi vil bøte på dette senere i denne serien
Trinn 5:. Managed Object Model
Den tredje og siste brikken i puslespillet er forvaltet objektmodellen. La oss ta en titt på getter av managedObjectModel eiendom
- (NSManagedObjectModel *) managedObjectModel {if (_managedObjectModel = null!) {Return _managedObjectModel.; } NSURL * modelURL = [[NSBundle mainBundle] URLForResource: @ "Core_Data" withExtension: @ "momd"]; _managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL: modelURL]; returnere _managedObjectModel;}
Gjennomføringen er veldig enkelt. Vi lagrer plasseringen av programmets modell i modelURL og passere modelURL til initWithContentsOfURL. Å opprette en forekomst av NSManagedObjectModel klassen
På dette punktet, er du sannsynligvis lurer på hva som modellen er modelURL peker til og hva filen med .momd utvidelsen er. For å besvare disse spørsmålene, må vi finne ut hva annet Xcode har skapt for oss i løpet av prosjektets oppsett.
Prosjekt Navigator
til venstre, skal du se en fil som heter Core_Data.xcdatamodeld
. Dette er datamodell av programmet som er satt sammen til en .momd fil. Det er den .momd filen som den forvaltes objektmodellen bruker til å lage datamodell for programmet.
Det er mulig å ha flere data modellfiler. Den NSManagedObjectModel klassen er fullt i stand til å slå sammen flere datamodeller til ett, som er en av de mer kraftige og fremskritt funksjoner i grunndata.
The Core data rammeverket støtter også datamodell versjone samt vandringer. Dette sikrer at dataene lagret i den varige lager (e) ikke blir ødelagt. Vi vil dekke versjons og vandringer senere i denne serien.
Datamodellen fil i vårt prosjekt er tom for øyeblikket, noe som betyr at vår datamodell inneholder ingen enheter. Vi vil rette opp dette i neste tutorial som vil fokusere utelukkende på datamodellen.
6. Putting It All Together
Før vi bryte opp denne artikkelen, vil jeg gjerne vise deg et diagram som illustrerer de tre komponentene i kjernedata stabelen.
Diagrammet ovenfor er en visuell representasjon av hva vi utforsket i Xcode mal for et øyeblikk siden. Den NSPersistentStoreCoordinator objektet er hjernen av Core data stabel av søknaden. Den snakker til en eller flere vedvarende butikker og sørger for at data blir lagret, lastet, og skjulested.
Den vedvarende butikken koordinator vet om datamodellen, skjema av objektet grafen hvis du vil, gjennom NSManagedObjectModel objekt . Den klarte objektmodellen skaper datamodell for programmet fra en eller flere .momd filer, binære representasjoner av datamodellen.
Sist men ikke minst, tilgang til applikasjonen objektet graf gjennom en eller flere forekomster av NSManagedObjectContext klasse . En administrert objekt sammenheng vet om datamodellen gjennom vedvarende butikken koordinator, men det vet ikke og holde en referanse til den administrerte objektmodellen. Det er ikke behov for at tilkoblingen.
De klarte objekt sammenheng ber vedvarende koordinator for data, og forteller det til å lagre data når det er nødvendig. Dette er gjort for deg av kjernedata rammeverket og søknaden sjelden behov for å snakke med den vedvarende butikken koordinator direkte.
Konklusjon
I denne artikkelen vi dekket de viktigste spillerne i Core- data stabelen, den vedvarende butikken koordinator, den klarte objektmodellen, og den klarte objekt sammenheng. Pass på at du forstår hvilken rolle hver komponent og, enda viktigere, hvordan de jobber sammen for å lage kjernedata gjøre sin magi.
I neste utgaven av denne serien på kjernedata, dykke vi inn i datamodellen. Vi tar en titt på datamodellen redaktør i Xcode 5 og vi skaper noen enheter, attributter og relasjoner.