Komme I Gang Med Core Data Tutorial

Dette er et forkortet kapittel fra vår bok Core Data By Tutorials, som har blitt fullstendig oppdatert For Swift 4.2 og iOS 12. Denne opplæringen presenteres som en del av vår iOS 12 Lanseringsfest-nyt!

Velkommen Til Core Data!

i denne opplæringen skriver du din aller første Kjernedataapp. Du ser hvor enkelt Det er å komme i gang med alle ressursene i Xcode, fra startkodemaler til datamodelleditoren.

Du kommer til å treffe bakken kjører helt fra starten. Ved slutten av opplæringen vil du vite hvordan du:

  • Modelldata ved Hjelp Av xcodes modellredigering
  • Legg til nye poster I Kjernedata
  • Hent et sett med poster Fra Kjernedata
  • Vis de hentede postene ved hjelp av en tabellvisning.

Du får også en følelse av Hva Kjernedata gjør bak kulissene, og hvordan du kan samhandle med de ulike bevegelige brikkene.

Komme I Gang

Åpne Xcode Og opprett et nytt iOS-prosjekt basert På Appmalen For Enkeltvisning. Gi navn til App-Hitlisten og sørg For At Bruk Kjernedata er merket.

Hvis Du Merker Av For Bruk Kjernedata, vil Xcode generere standardtekstkode for det som kalles NSPersistentContainer I AppDelegate.rask.

NSPersistentContainer består av et sett med objekter som letter lagring og henting av informasjon fra Kjernedata. Inne i denne beholderen er et objekt for å administrere Kjernedatatilstanden som helhet, et objekt som representerer Datamodellen, og så videre.

standardstakken fungerer bra for de fleste apper, men avhengig av appen din og datakravene, kan du tilpasse stakken for å være mer effektiv.

Notat: Ikke Alle xcode-maler under ios ▸ – Applikasjonen har muligheten til å starte Med Kjernedata. I Xcode 10 er Det bare Malene I Master-Detail-Appen og Single View-appen Som har Avkrysningsruten Bruk Kjernedata.

ideen til denne prøven app er enkel: Det vil være en tabellvisning med en liste over navn for din egen «hit list». Du kan legge til navn i denne listen, og til slutt bruke Kjernedata for å sikre at dataene lagres mellom økter. Vi tolererer ikke vold på dette nettstedet, så du kan tenke på denne appen som en favorittliste for å holde styr på vennene dine også, selvfølgelig!

Klikk På Hoved.storyboard for å åpne Den I Interface Builder. Velg visningskontrolleren på lerretet, og legg den inn i en navigasjonskontroller. Fra Xcodes Redigeringsmeny velger Du Bygg Inn I … ▸ Navigasjonskontroller.

Klikk på navigasjonskontrollerens navigasjonslinje for å velge den, og klikk Deretter På Foretrekker Store Titler i Attributtsinspektøren. Dette vil gi prøven app en tittel stil som samsvarer Med Apples lager apps.

deretter drar Du En Tabellvisning fra objektbiblioteket til visningskontrolleren, og deretter endrer du størrelsen på den slik at den dekker hele visningen.

hvis det ikke allerede er åpent, bruker du ikonet nederst til venstre på lerretet for å åpne Grensesnittbyggerens dokumentoversikt.

Ctrl-dra Fra Tabellvisningen i dokumentoversikten til den overordnede visningen, og velg Betingelsen For Mellomrom Til Trygt Område:

Gjør dette tre ganger, velge begrensninger Etterfølgende Plass Til Trygt Område, Topp Plass Til Trygt Område Og til slutt, Bunn Plass Til Trygt Område. Hvis du legger til disse fire begrensningene, vil tabellvisningen fylle den overordnede visningen.

deretter drar Du Et Linjeknappelement og plasserer Det på navigasjonslinjen på visningskontrolleren. Til slutt velger du bar-knappen og endrer systemelementet For Å Legge til.

lerretet ditt skal se ut som følgende skjermbilde:

Hver gang Du trykker På Legg til-knappen, vises en varslingskontroller som inneholder et tekstfelt. Derfra kan du skrive inn noen navn i tekstfeltet. Hvis du trykker på Save, lagrer du navnet, lukker varslingskontrolleren og oppdaterer tabellvisningen, og viser alle navnene du har angitt.

men først må du gjøre visningskontrolleren til tabellvisningens datakilde. I lerretet, Ctrl-dra fra tabellvisningen til det gule visningskontrollikonet over navigasjonsfeltet, som vist nedenfor, og klikk på datakilde:

hvis du lurer på, trenger du ikke å sette opp tabellvisningens delegat siden du trykker på cellene, utløser ingen handling. Det blir ikke enklere enn dette!

Åpne assistentredigering ved å trykke På Kommando-Tilvalg-Enter eller ved å velge midtknappen på Redigeringsverktøyet På Xcode-linjen.

Ctrl-dra fra tabellvisningen til ViewController.swift inne i klassen definisjonen for å lage en IBOutlet.

deretter navngi den nye IBOutlet egenskapen tableView, noe som resulterer i følgende linje:

@IBOutlet weak var tableView: UITableView!

Deretter Ctrl-dra Fra Legg til-knappen til ViewController.swift like under din viewDidLoad() definisjon. Denne gangen oppretter du en handling i stedet for et uttak, og navngir metoden addName, med en type UIBarButtonItem:

@IBAction func addName(_ sender: UIBarButtonItem) { }

Du kan nå referere til tabellvisningen og barknappens handling i kode.

deretter konfigurerer du modellen for tabellvisningen. Legg til følgende egenskap For Å ViewController.swift under tableView IBOutlet:

var names: = 

names er et foranderlig array som holder strengverdier som vises av tabellvisningen. Deretter erstatter implementeringen av viewDidLoad() med følgende:

override func viewDidLoad() { super.viewDidLoad() title = "The List" tableView.register(UITableViewCell.self, forCellReuseIdentifier: "Cell")}

Dette vil sette en tittel på navigasjonsfeltet og registrere klassen UITableViewCell med tabellvisningen.

Merk: register(_:forCellReuseIdentifier:) garanterer at tabellvisningen returnerer en celle av riktig type når Cellen reuseIdentifier leveres til dequeue – metoden.

Neste, fortsatt i ViewController.swift, legg til følgende UITableViewDataSource – utvidelse under klassedefinisjonen din for ViewController:

// MARK: - UITableViewDataSourceextension ViewController: UITableViewDataSource { func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return names.count } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath) cell.textLabel?.text = names return cell }}

hvis du noen gang har jobbet med UITableView, bør denne koden se veldig kjent ut. Først returnerer du antall rader i tabellen som antall elementer i names – matrisen.

Neste, tableView(_:cellForRowAt:) dequeues tabellvisning celler og fyller dem med den tilsvarende strengen fra names matrisen.

deretter trenger du en måte å legge til nye navn på, slik at tabellvisningen kan vise dem. Implementer addName IBAction-metoden Du Ctrl-dratt inn i koden din tidligere:

// Implement the addName IBAction@IBAction func addName(_ sender: UIBarButtonItem) { let alert = UIAlertController(title: "New Name", message: "Add a new name", preferredStyle: .alert) let saveAction = UIAlertAction(title: "Save", style: .default) { action in guard let textField = alert.textFields?.first, let nameToSave = textField.text else { return } self.names.append(nameToSave) self.tableView.reloadData() } let cancelAction = UIAlertAction(title: "Cancel", style: .cancel) alert.addTextField() alert.addAction(saveAction) alert.addAction(cancelAction) present(alert, animated: true)}

Hver gang du trykker På Legg til-knappen, vil denne metoden presentere en UIAlertController med et tekstfelt og to knapper: Lagre og Avbryt.

Lagre setter inn tekstfeltene gjeldende tekst i names – matrisen, og laster deretter tabellvisningen på nytt. Siden names – arrayet er modellen som støtter tabellvisningen, vil det du skriver inn i tekstfeltet vises i tabellvisningen.

Til slutt bygger og kjører appen din for første gang. Deretter trykker Du På Legg til-knappen. Varslingskontrolleren vil se slik ut:

Legg til fire eller fem navn på listen. Du bør se noe som ligner på nedenfor:

tabellvisningen vil vise dataene og arrayet ditt vil lagre navnene, men det store som mangler her er utholdenhet. Arrayet er i minnet, men hvis du tvinger avslutte appen eller starter enheten på nytt, blir trefflisten din slettet. Kjernedata gir utholdenhet, noe som betyr at det kan lagre data i en mer holdbar tilstand, slik at den kan overleve en app-omstart eller en omstart av enheten.

Du har ikke lagt Til Noen Kjernedataelementer ennå, så ingenting bør vedvare etter at du navigerer bort fra appen. La oss teste dette ut. Trykk På Hjem-knappen hvis du bruker en fysisk enhet eller tilsvarende (Shift + ⌘ + H) hvis Du bruker Simulatoren. Dette tar deg tilbake til det kjente apprutenettet på startskjermen:

fra hjem-skjermen trykker Du På Hitlisteikonet for å bringe appen tilbake til forgrunnen. Navnene er fortsatt på skjermen. Hva skjedde?

når du trykker På Hjem-knappen, går appen i forgrunnen til bakgrunnen. Når dette skjer, operativsystemet flash-fryser alt som er i minnet, inkludert strengene i navn array. På samme måte, når det er på tide å våkne opp og gå tilbake til forgrunnen, gjenoppretter operativsystemet det som pleide å være i minnet som om du aldri hadde forlatt.

Apple introduserte disse fremskrittene i multitasking tilbake i iOS 4. De skaper en sømløs opplevelse for iOS-brukere, men legger til en rynke i definisjonen av utholdenhet for iOS-utviklere. Er navnene virkelig vedvarende?

Nei, egentlig ikke. Hvis du hadde drept appen helt i fast app switcher eller slått av telefonen, ville disse navnene være borte. Du kan også bekrefte dette. Med appen i forgrunnen skriver du inn den raske appveksleren. Du kan gjøre dette ved å enten dobbelttrykke På Hjem-knappen hvis enheten har en eller sakte dra oppover fra bunnen av skjermen Hvis du er på en iPhone X.

herfra, flick HitList app snapshot oppover for å avslutte programmet. Hvis du jobber med en iPhone X, må du trykke lenge på appbildet til en rød sletteknapp vises øverst til høyre.

etter at du har fjernet appen fra appbryteren, bør det ikke være spor Av HitList i levende minne(ingen ordspill ment). Bekreft navnene er borte ved å gå tilbake til startskjermen og trykke På Hitlisteikonet for å utløse en ny lansering.

forskjellen mellom flash-frysing og utholdenhet kan være åpenbar hvis du har jobbet med iOS i noen tid og er kjent med måten multitasking fungerer på. I brukerens sinn er det imidlertid ingen forskjell. Brukeren bryr seg ikke hvorfor navnene fortsatt er der, om appen gikk inn i bakgrunnen og kom tilbake, eller fordi appen lagret og lastet dem på nytt. Alt som betyr noe er navnene er der fortsatt når app kommer tilbake!

så den virkelige testen av utholdenhet er om dataene dine fortsatt er der etter en ny appstart.

Modellering Av Dataene Dine

nå vet du hvordan du sjekker om utholdenhet, du kan dykke inn I Kjernedata. Målet ditt For HitList-appen er enkelt: fortsett navnene du skriver inn, slik at de er tilgjengelige for visning etter en ny appstart.

Frem til dette punktet har du brukt vanlige Gamle Swift-strenger til å lagre navnene i minnet. I denne delen erstatter du disse strengene med Kjernedataobjekter.

det første trinnet er å lage en administrert objektmodell, som beskriver Hvordan Kjernedata representerer data på disken.

Som Standard Bruker Kjernedata En sqlite-database som vedvarende lager, slik at Du kan tenke På Datamodellen som databaseskjemaet.

Merk: du kommer over ordet klarte ganske mye når du arbeider Med Kjernedata. Hvis du ser «administrert» i navnet på en klasse, for eksempel i NSManagedObjectContext, er sjansen stor for at Du har å gjøre med En Kjernedataklasse. «Managed» refererer Til Kjernedatas styring av livssyklusen Til Kjernedataobjekter.

ikke anta at Alle kjernedataklasser inneholder ordet «administrert». De fleste gjør det ikke. for en omfattende liste Over Kjernedataklasser, sjekk ut Core data framework referansen i dokumentasjonsnavigering.

Siden Du har valgt Å bruke Kjernedata, har Xcode automatisk opprettet En Datamodellfil for deg og kalt Den HitList.xcdatamodeld.

Åpne HitList.xcdatamodeld. Som Du kan se, Har Xcode en kraftig datamodelleditor:

Datamodelleditoren har mange funksjoner du kan utforske senere. For nå, la oss fokusere på å skape en Enkelt Kjernedataenhet.

Klikk På Legg Til Enhet nederst til venstre for å opprette en ny enhet. Dobbeltklikk på den nye enheten og endre navnet Til Person, slik som:

Du lurer kanskje på hvorfor modellredaktøren bruker begrepet Entity. var du ikke bare å definere en ny klasse? Som du snart ser, Kommer Kjernedata med sitt eget ordforråd. Her er en rask oversikt over noen vilkår du ofte møter:

  • en enhet er en klassedefinisjon i Kjernedata. Det klassiske eksemplet er en Employee eller en Company. I en relasjonsdatabase tilsvarer en enhet en tabell.
  • et attributt er et stykke informasjon knyttet til en bestemt enhet. En Employee – enhet kan for eksempel ha attributter for den ansattes name, position og salary. I en database tilsvarer et attributt et bestemt felt i en tabell.
  • en relasjon er en kobling mellom flere enheter. I Kjernedata kalles relasjoner mellom to enheter til-en-relasjoner, mens de mellom en og mange enheter kalles til-mange relasjoner. For eksempel kan en Manager ha et to-many forhold til et sett med ansatte, mens en person Employee vanligvis vil ha et to-one forhold til sin leder.

Merk: du har sikkert lagt merke til enheter høres mye ut som klasser. Like måte, attributter og relasjoner høres mye som egenskaper. Hva er forskjellen? Du kan tenke På En Kjernedataenhet som en klassedefinisjon og det administrerte objektet som en forekomst av den klassen.

nå vet du hva et attributt er, du kan legge til et attributt til Person objekt opprettet tidligere. Fortsatt I Hitlista.xcdatamodeld, velg Person på venstre side og klikk på plusstegnet ( + ) Under Attributter.

Sett det nye attributtets navn til, er, navn og endre type Til Streng:

I Kjernedata kan et attributt være av en av flere datatyper.

Lagrer Til Kjernedata

Åpne ViewController.swift, legg til Følgende Core data module import under import UIKit :

import CoreData

denne importen er alt du trenger for å begynne å bruke Core DATA API i koden din.

erstatt deretter egenskapsdefinisjonen names med følgende:

var people: = 

du lagrer Person enheter i stedet for strengnavn, slik at du gir nytt navn til matrisen som fungerer som tabellvisningens datamodell til people. Det har nå forekomster av NSManagedObject i stedet for enkle strenger.

NSManagedObject representerer et enkelt objekt lagret I Kjernedata; du må bruke det til å opprette, redigere, lagre og slette fra Kjernedatabeholdningen. Som du snart ser, er NSManagedObject en shape-shifter. Det kan ta form av en hvilken som helst enhet i Datamodellen din, og tilordne hvilke attributter og relasjoner du definerte.

Siden du endrer tabellvisningens modell, må du også erstatte begge datakildemetodene som er implementert tidligere. Erstatt UITableViewDataSource – utvidelsen med følgende:

// MARK: - UITableViewDataSourceextension ViewController: UITableViewDataSource { func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return people.count } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let person = people let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath) cell.textLabel?.text = person.value(forKeyPath: "name") as? String return cell }}

den viktigste endringen i disse metodene skjer i tableView(_:cellForRowAt:). I stedet for å matche celler med den tilsvarende strengen i modellgruppen, matcher du nå celler med den tilsvarende NSManagedObject.

Legg merke til hvordan du tar tak i name – attributtet fra NSManagedObject. Det skjer her:

cell.textLabel?.text = person.value(forKeyPath: "name") as? String

Hvorfor må du gjøre dette? Som det viser seg, vet NSManagedObject ikke om name attributtet du definerte i Datamodellen din, så det er ingen måte å få tilgang til den direkte med en egenskap. Den eneste Måten Kjernedata gir for å lese verdien er nøkkelverdikoding, ofte referert TIL SOM KVC.

MERK: KVC er en mekanisme I Grunnlaget for å få tilgang til et objekts egenskaper indirekte ved hjelp av strenger. I DETTE tilfellet GJØR KVC NSMangedObject oppfører seg noe som en ordbok under kjøring.

nøkkelverdikoding er tilgjengelig for alle klasser som arver fra NSObject, inkludert NSManagedObject. Du får ikke tilgang til egenskaper ved HJELP AV KVC på Et Swift-objekt som ikke stammer fra NSObject.

Neste, finn addName(_:) og erstatt save UIAlertAction med følgende:

let saveAction = UIAlertAction(title: "Save", style: .default) { action in guard let textField = alert.textFields?.first, let nameToSave = textField.text else { return } self.save(name: nameToSave) self.tableView.reloadData()}

dette tar teksten i tekstfeltet og sender den over til en ny metode som heter save(name:). Xcode klager fordi save(name:) ikke eksisterer ennå. Legg det under addName(_:):

func save(name: String) { guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else { return } // 1 let managedContext = appDelegate.persistentContainer.viewContext // 2 let entity = NSEntityDescription.entity(forEntityName: "Person", in: managedContext)! let person = NSManagedObject(entity: entity, insertInto: managedContext) // 3 person.setValue(name, forKeyPath: "name") // 4 do { try managedContext.save() people.append(person) } catch let error as NSError { print("Could not save. \(error), \(error.userInfo)") }}

Det er her Kjernedata sparker inn! Her er hva koden gjør:

  1. Før du kan lagre eller hente noe fra Kjernedatabutikken din, må du først få hendene på en NSManagedObjectContext. Du kan vurdere en administrert objektkontekst som en in-memory «scratchpad» for å arbeide med administrerte objekter.

    tenk på å lagre et nytt administrert objekt Til Kjernedata som en to-trinns prosess: først setter du inn et nytt administrert objekt i en administrert objektkontekst; når du er fornøyd, «forplikter du» endringene i den administrerte objektkonteksten for å lagre den på disk.

    Xcode har allerede generert en administrert objektkontekst som en del av det nye prosjektets mal. Husk at dette bare skjer hvis Du merker Av For Bruk Kjernedata i begynnelsen. Denne standard administrerte objektkonteksten lever som en egenskap for NSPersistentContainer i programrepresentanten. For å få tilgang til det, får du først en referanse til app-representanten.

  2. du oppretter et nytt administrert objekt og setter det inn i konteksten for administrert objekt. Du kan gjøre dette i ett trinn med NSManagedObject ‘ s statiske metode: entity(forEntityName:in:).

    du lurer kanskje på hva en NSEntityDescription handler om. Recall tidligere, NSManagedObject ble kalt en shape-shifter klasse fordi den kan representere enhver enhet. En enhetsbeskrivelse er brikken som kobler enhetsdefinisjonen fra Datamodellen med en forekomst av NSManagedObject ved kjøretid.

  1. Med en NSManagedObject i hånden, setter du name attributtet ved hjelp av nøkkelverdikoding. DU må stave KVC-tasten (name i dette tilfellet) akkurat som det vises i Datamodellen din, ellers vil appen din krasje under kjøring.
  2. du forplikter endringene til person og lagrer på disk ved å ringe save i konteksten for administrert objekt. Merk save kan kaste en feil, og derfor kaller du den ved hjelp av try – søkeordet i en do-catch – blokk. Til slutt setter du inn det nye administrerte objektet i people – arrayet, slik at det vises når tabellvisningen lastes på nytt.

Det er litt mer komplisert enn å bruke en rekke strenger, men ikke så ille. Noen av koden her, for eksempel å få den administrerte objektkonteksten og enheten, kan gjøres bare en gang i din egen init() eller viewDidLoad() og deretter gjenbrukes senere. For enkelhets skyld gjør du alt på samme måte.

Bygg og kjør appen, og legg til noen navn i tabellvisningen:

hvis navnene faktisk er lagret I Kjernedata, Bør HitList-appen bestå utholdenhetstesten. Med appen i forgrunnen går du til fast app switcher og avslutter den deretter.

Trykk På HitList-appen Fra Springboard for å utløse en ny lansering. Vent, hva skjedde? Tabellvisningen er tom:

du lagret Til Kjernedata, men etter en ny appstart er people – arrayet tomt! Det er fordi dataene sitter på disken og venter på deg, men du viser det ikke ennå.

Henter Fra Kjernedata

for å få data fra din faste butikk inn i den administrerte objektkonteksten, må du hente den. Åpne ViewController.swift og legge til følgende nedenfor viewDidLoad():

override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) //1 guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else { return } let managedContext = appDelegate.persistentContainer.viewContext //2 let fetchRequest = NSFetchRequest<NSManagedObject>(entityName: "Person") //3 do { people = try managedContext.fetch(fetchRequest) } catch let error as NSError { print("Could not fetch. \(error), \(error.userInfo)") }}

Trinn for trinn, dette er hva koden gjør:

  1. før Du kan gjøre Noe med Kjernedata, trenger du en administrert objektkontekst. Henting er ikke annerledes! Som før trekker du opp applikasjonsdelegaten og tar en referanse til den vedvarende beholderen for å få hendene på NSManagedObjectContext.
  2. som navnet antyder, er NSFetchRequest klassen som er ansvarlig for å hente Fra Kjernedata. Henteforespørsler er både kraftige og fleksible. Du kan bruke henteforespørsler til å hente et sett med objekter som oppfyller de angitte kriteriene (dvs. Gi meg alle ansatte som bor I Wisconsin og har vært med selskapet minst tre år), individuelle verdier (dvs. gi meg det lengste navnet i databasen) og mer.

    Henteforespørsler har flere kvalifikatorer som brukes til å avgrense settet med resultater som returneres. For nå bør du vite NSEntityDescription er en av disse nødvendige kvalifikatorene.

    Angi en henteforespørsel entity – egenskap, eller alternativt initialisere den med init(entityName:), henter alle objekter av en bestemt enhet. Dette er hva du gjør her for å hente alle Person enheter. Merk også NSFetchRequest er en generisk type. Denne bruken av generics angir en henteforespørsel forventet returtype, i dette tilfellet NSManagedObject.

  3. du leverer henteforespørselen til den administrerte objektkonteksten for å gjøre den tunge løftingen. fetch(_:) returnerer en matrise med administrerte objekter som oppfyller kriteriene angitt i henteforespørselen.

Merk: Som save(), fetch(_:) kan også kaste en feil, så du må bruke den i en do blokk. Hvis det oppstod en feil under henting, kan du inspisere feilen i catch – blokken og svare på riktig måte.

Bygg og kjør programmet. Umiddelbart bør du se listen over navn du har lagt til tidligere:

Flott! De er tilbake fra de døde(ordspill ment). Legg til noen flere navn på listen og start appen på nytt for å bekrefte at lagring og henting fungerer. Kort for å slette appen, tilbakestille Simulatoren eller kaste telefonen av en høy bygning, vil navnene vises i tabellvisningen uansett hva.

Merk: Det var noen grove kanter i denne prøven app: du måtte hente den administrerte objektkonteksten fra app-representanten hver gang, og du brukte KVC til å få tilgang til en enhets attributter i stedet for en mer naturlig objektstil person.name.

Nøkkelpunkter

  • Kjernedata gir utholdenhet på disken, noe som betyr at dataene dine vil være tilgjengelige selv etter at du har avsluttet appen eller slått av enheten. Dette er forskjellig fra in-memory persistence, som bare lagrer dataene dine så lenge appen din er i minnet, enten i forgrunnen eller i bakgrunnen.
  • Xcode leveres med en kraftig datamodelleditor, som du kan bruke til å opprette den administrerte objektmodellen.
  • en administrert objektmodell består av enheter, attributter og relasjoner
  • en enhet er en klassedefinisjon i Kjernedata.
  • et attributt er et stykke informasjon knyttet til en enhet.
  • en relasjon er en kobling mellom flere enheter.
  • En NSManagedObject er en kjøretidsrepresentasjon av En Kjernedataenhet. Du kan lese og skrive til sine attributter ved Hjelp Av Nøkkelverdi Koding.
  • du trenger en NSManagedObjectContext til save() eller fetch(_:) data til Og Fra Kjernedata.

Hvor Skal Du Gå Herfra?

du kan laste ned det ferdige prosjektet for denne opplæringen ved å bruke knappene «Last ned materialer» øverst eller nederst i denne opplæringen.

i denne opplæringen har du allerede opplevd flere grunnleggende Kjernedatabegreper: Datamodeller, enheter, attributter, administrerte objekter, administrerte objektkontekster og henteforespørsler.

hvis du likte det du lærte i denne opplæringen, hvorfor ikke sjekke ut de komplette Kjernedataene av Opplæringsboken, tilgjengelig i butikken vår?

her er en smak av hva som er i boken:

1. Kapittel 1, Din Første Kjernedataapp: du klikker På Fil ▸ Nytt Prosjekt og skriver En Kjernedataapp fra bunnen av! Dette kapittelet dekker grunnleggende om å sette opp datamodellen og deretter legge til og hente poster.

2. Kapittel 2, Nsmanagedobject Underklasser: NSManagedObject er basen datalagring klassen Av Kjernen data objekt grafer. Dette kapittelet vil lære deg hvordan du tilpasser dine egne administrerte objektunderklasser for å lagre og validere data.

3. Kapittel 3, Core Data Stack: Under panseret, Kjernedata består av mange deler som arbeider sammen. I dette kapittelet lærer du om hvordan disse delene passer sammen, og beveger deg bort fra start Xcode-malen for å bygge ditt eget tilpassbare system.

4. Kapittel 4, Mellomliggende Henting: appene dine henter data hele tiden, Og Kjernedata gir mange muligheter for å få dataene til deg effektivt. Dette kapittelet dekker mer avanserte henteforespørsler, predikater, sortering og asynkron henting.

5. Kapittel 5, NSFetchedResultsController: Tabellvisninger er kjernen i mange iOS-apper, Og Apple ønsker Å få Kjernedata til å spille pent med dem! I dette kapittelet lærer Du Hvordan NSFetchedResultsController kan spare tid og kode når tabellvisningene støttes av data fra Kjernedata.

6. Kapittel 6, Versjonskontroll Og Migrering: når du oppdaterer og forbedrer appen din, må datamodellen nesten helt sikkert endres. I dette kapittelet lærer du hvordan du oppretter flere versjoner av datamodellen, og deretter overfører brukerne fremover slik at de kan beholde sine eksisterende data etter hvert som de oppgraderer.

7. Kapittel 7, Enhetstester: Testing er en viktig del av utviklingsprosessen, og Du bør ikke forlate Kjernedata ut av det! I dette kapittelet lærer du hvordan du setter opp et eget testmiljø for Kjernedata og ser eksempler på hvordan du tester modellene dine.

8. Kapittel 8: Måling og Forbedring Av Ytelse: Ingen klaget over at en app var for rask, så det er viktig å være årvåken om sporing av ytelse. I dette kapittelet lærer du hvordan du måler appens ytelse med ulike Xcode-verktøy, og deretter henter du noen tips for å håndtere sakte flekker i koden din.

9. Kapittel 9, Flere Administrerte Objektkontekster: i dette siste kapittelet utvider du den vanlige Kjernedatastakken til å inkludere flere administrerte objektkontekster. Du lærer hvordan dette kan forbedre oppfattet ytelse og bidra til å gjøre apparkitekturen mindre monolitisk og mer oppdelt.

og for å hjelpe søte avtalen, er den digitale utgaven av boken på salg for $44,99! Men ikke vent – denne salgsprisen er bare tilgjengelig i en begrenset periode.

Når du Snakker om søte tilbud, sørg for å sjekke ut de flotte premiene vi gir bort i år med iOS 11 Lanseringsfest, inkludert over $9000 i giveaways!

for å være kvalifisert for denne episke iOS 12-giveawayen, er alt du trenger å gjøre, å legge igjen en kommentar til det opprinnelige lanseringsposten, og la oss få vite hvilken bok eller kurs som er din favoritt på denne listen — eller hvilken kommende bok eller kurs du er mest spent på!

vi håper du liker denne oppdateringen, og følg med for flere bokutgivelser og oppdateringer!

raywenderlich.com Ukentlig

Den raywenderlich.com nyhetsbrev er den enkleste måten å holde deg oppdatert på alt du trenger å vite som mobilutvikler.

Få en ukentlig oversikt over våre opplæringsprogrammer og kurs, og motta et gratis, grundig e-postkurs som en bonus!

Gjennomsnittlig Vurdering

4.6/5

Legg til en vurdering for dette innholdet

Logg På For å legge til en vurdering

56 vurderinger

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.