Kom godt i gang med Core Data Tutorial

dette er en forkortet kapitel fra vores bog Core Data af Tutorials, som er blevet fuldstændig opdateret til hurtig 4.2 og iOS 12. Denne tutorial præsenteres som en del af vores iOS 12 Launch Party — god fornøjelse!

velkommen til Core Data!

i denne tutorial, vil du skrive din allerførste Core Data app. Du kan se, hvor nemt det er at komme i gang med alle de ressourcer, der er angivet i kode, fra startkodeskabeloner til Datamodeleditoren.

du kommer til at ramme jorden kører lige fra starten. Ved udgangen af tutorial vil du vide, hvordan man:

  • Føj nye poster til kernedata
  • Hent et sæt poster fra kernedata
  • Vis de hentede poster ved hjælp af en tabelvisning.

Du får også en fornemmelse af, hvad kernedata gør bag kulisserne, og hvordan du kan interagere med de forskellige bevægelige stykker.

Kom godt i gang

Åbn kode og opret et nyt iOS-projekt baseret på appskabelonen med en enkelt visning. Navngiv appens hitliste, og sørg for, at brug af kernedata er markeret.

hvis du kontrollerer feltet Brug kernedata, genereres standardkode for det, der er kendt som en NSPersistentContainer i AppDelegate.Hurtig.

NSPersistentContainer består af et sæt objekter, der letter lagring og hentning af information fra kernedata. Inde i denne beholder er et objekt til at styre Kernedatatilstanden som helhed, et objekt, der repræsenterer Datamodellen osv.

standardstakken fungerer godt for de fleste apps, men afhængigt af din app og dens datakrav kan du tilpasse stakken til at være mere effektiv.

Bemærk: Ikke alle kodeskabeloner under iOS-applikation har mulighed for at starte med kernedata. I Kode 10 er det kun skabeloner til Master-Detail-App og Enkeltvisning, der har afkrydsningsfeltet Brug kernedata.

ideen til denne prøveapp er enkel: der vil være en tabelvisning med en liste over navne til din helt egen “hitliste”. Du kan tilføje navne til denne liste og til sidst bruge kernedata for at sikre, at dataene gemmes mellem sessioner. Vi tolererer ikke vold på dette site, så du kan tænke på denne app som en favoritliste for at holde styr på dine venner også, selvfølgelig!

Klik på Main.storyboard til at åbne den i Interface Builder. Vælg visningscontrolleren på lærredet, og integrer den inde i en navigationscontroller. Vælg Integrer i navigationscontroller.

Klik på navigationscontrollerens navigationslinje for at vælge den, og klik derefter på foretrækker store titler i Attributinspektøren. Dette giver prøve-appen en titelstil, der matcher Apples lagerapps.

træk derefter en tabelvisning fra objektbiblioteket til visningscontrolleren, og ændr derefter størrelsen på den, så den dækker hele visningen.

hvis det ikke allerede er åbent, skal du bruge ikonet i nederste venstre hjørne af dit lærred til at åbne Interface Builder ‘ s dokumentoversigt.

Ctrl-træk fra tabelvisningen i dokumentoversigten til dens overordnede visning, og vælg den førende plads til sikkert område begrænsning:

gør dette tre gange mere, Vælg de begrænsninger, der følger plads til sikkert område, Top plads til sikkert område og endelig Bundplads til sikkert område. Tilføjelse af disse fire begrænsninger får tabelvisningen til at udfylde dens overordnede visning.

træk derefter et element på Bjælkeknappen og placer det på visningskontrollerens navigationslinje. Til sidst skal du vælge elementet bar button og ændre dets systemelement for at tilføje.

dit lærred skal ligne følgende skærmbillede:

hver gang du trykker på knappen Tilføj, vises en alarmcontroller, der indeholder et tekstfelt. Derfra kan du skrive en persons navn i tekstfeltet. Hvis du trykker på Save, gemmer du navnet, afviser alarmcontrolleren og opdaterer tabelvisningen og viser alle de Navne, du har indtastet.

men først skal du gøre visningskontrolleren til tabelvisningens datakilde. I lærredet, Ctrl-træk fra tabelvisningen til det gule visningskontrollerikon over navigationslinjen, som vist nedenfor, og klik på dataSource:

hvis du undrer dig, behøver du ikke at konfigurere tabelvisningens delegat, da tapping på cellerne ikke udløser nogen handling. Det bliver ikke enklere end dette!

Åbn assistenteditoren ved at trykke på Command-Option-Enter eller ved at vælge den midterste knap på Redigeringsværktøjssættet på Kodelinjen.

Ctrl-træk fra tabelvisningen til Visningskontroller.hurtig inde i klassedefinitionen for at oprette en IBOutlet.

navngiv derefter den nye IBOutlet ejendom tableView, hvilket resulterer i følgende linje:

@IBOutlet weak var tableView: UITableView!

næste, Ctrl-træk fra knappen Tilføj til Visningcontroller.hurtigt lige under din viewDidLoad() definition. Denne gang skal du oprette en handling i stedet for en stikkontakt og navngive metoden addName med en type UIBarButtonItem:

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

du kan nu henvise til tabelvisningen og bjælkeknappens handling i kode.

dernæst konfigurerer du modellen til tabelvisningen. Tilføj følgende egenskab for at Secontroller.hurtig under tableView IBOutlet:

var names: = 

names er et foranderligt array, der holder strengværdier, der vises af tabelvisningen. Udskift derefter implementeringen af viewDidLoad() med følgende:

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

dette sætter en titel på navigationslinjen og registrerer klassen UITableViewCell med tabelvisningen.

Bemærk: register(_:forCellReuseIdentifier:) garanterer, at din tabelvisning returnerer en celle af den korrekte type, når Cell reuseIdentifier leveres til dequeue – metoden.

næste, stadig i Visningcontroller.Hurtig, tilføj følgende UITableViewDataSource udvidelse under din klassedefinition 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 nogensinde har arbejdet med UITableView, skal denne kode se meget velkendt ud. Først returnerer du antallet af rækker i tabellen som antallet af elementer i dit names array.

næste, tableView(_:cellForRowAt:) dekoder tabelvisning celler og udfylder dem med den tilsvarende streng fra names array.

Dernæst har du brug for en måde at tilføje nye navne på, så tabelvisningen kan vise dem. Gennemføre addName IBAction metode, Du Ctrl-trukket ind i din kode 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å knappen Tilføj, vil denne metode præsentere en UIAlertController med et tekstfelt og to knapper: Gem og Annuller.

Gem indsætter tekstfelterne aktuel tekst i names arrayet genindlæser derefter tabelvisningen. Da arrayet names er den model, der understøtter tabelvisningen, vises uanset hvad du skriver i tekstfeltet i tabelvisningen.

endelig Bygge og køre din app for første gang. Tryk derefter på knappen Tilføj. Alarmcontrolleren vil se sådan ud:

tilføj fire eller fem navne til listen. Du skal se noget, der ligner nedenfor:

din tabelvisning viser dataene, og dit array gemmer navnene, men den store ting, der mangler her, er vedholdenhed. Arrayet er i hukommelsen, men hvis du tvinger til at afslutte appen eller genstarte din enhed, bliver din hitliste udslettet. Kernedata giver vedholdenhed, hvilket betyder, at de kan gemme data i en mere holdbar tilstand, så de kan overleve en app-genstart eller en genstart af enheden.

du har ikke tilføjet nogen Kernedataelementer endnu, så intet skal fortsætte, når du navigerer væk fra appen. Lad os teste dette ud. Tryk på startknappen, hvis du bruger en fysisk enhed eller tilsvarende (Shift + liter + H), hvis du bruger simulatoren. Dette fører dig tilbage til det velkendte appgitter på startskærmen:

tryk på Hitlisteikonet på startskærmen for at bringe appen tilbage til forgrunden. Navnene er stadig på skærmen. Hvad skete der?

når du trykker på knappen Hjem, går den app, der aktuelt er i forgrunden, til baggrunden. Når dette sker, operativsystemet flash-fryser alt i øjeblikket i hukommelsen, herunder strengene i Navne array. Tilsvarende, når det er tid til at vågne op og vende tilbage til forgrunden, gendanner operativsystemet det, der plejede at være i hukommelsen, som om du aldrig havde forladt.

Apple introducerede disse fremskridt inden for multitasking tilbage i iOS 4. De skaber en problemfri oplevelse for iOS-brugere, men tilføjer en rynke til definitionen af vedholdenhed for iOS-udviklere. Er navnene virkelig vedvarende?

Nej, ikke rigtig. Hvis du helt havde dræbt appen i den hurtige appskifter eller slukket for din telefon, ville disse navne være væk. Du kan også bekræfte dette. Med appen i forgrunden skal du indtaste den hurtige appskifter. Du kan gøre dette ved enten at dobbeltklikke på startknappen, hvis din enhed har en eller langsomt trække opad fra bunden af skærmen, hvis du bruger en iPhone.

herfra, svirp Hitlist app snapshot opad for at afslutte app. Hvis du arbejder på en iPhone, skal du trykke længe på appens øjebliksbillede, indtil en rød sletningsknap vises øverst til højre.

når du har fjernet appen fra appskifteren, skal der ikke være spor af HitList i living memory (ingen ordspil beregnet). Kontroller, at navnene er væk ved at vende tilbage til startskærmen og trykke på Hitlisteikonet for at udløse en ny lancering.

forskellen mellem flashfrysning og vedholdenhed kan være indlysende, hvis du har arbejdet med iOS i nogen tid og er bekendt med den måde, multitasking fungerer på. I en brugers sind er der dog ingen forskel. Brugeren er ligeglad med, hvorfor navnene stadig er der, om appen gik i baggrunden og kom tilbage, eller fordi appen gemte og genindlæste dem. Det eneste, der betyder noget, er, at navnene stadig er der, når appen kommer tilbage!

så den virkelige test af vedholdenhed er, om dine data stadig er der efter en ny applancering.

modellering af dine Data

nu ved du, hvordan du kontrollerer for vedholdenhed, du kan dykke ned i kernedata. Dit mål for HitList-appen er enkel: Fortsæt de Navne, du indtaster, så de er tilgængelige til visning efter en ny applancering.

indtil dette tidspunkt har du brugt almindelige gamle hurtige strenge til at gemme navnene i hukommelsen. I dette afsnit erstatter du disse strenge med Kernedataobjekter.

det første trin er at oprette en administreret objektmodel, der beskriver den måde, kernedata repræsenterer data på disken.

som standard bruger kernedata en database som den vedvarende butik, så du kan tænke på Datamodellen som databaseskemaet.

Bemærk: Du kommer på tværs af ordet administreret ganske lidt, når du beskæftiger dig med kernedata. Hvis du ser “administreret” i navnet på en klasse, som i NSManagedObjectContext, er chancerne for, at du har at gøre med en Kernedataklasse. “Managed” henviser til Kernedatas styring af livscyklussen for Kernedataobjekter.

Antag dog ikke, at alle Kernedataklasser indeholder ordet “administreret”. De fleste gør det ikke.For en omfattende liste over Kernedataklasser, se referencen til Kernedatarammen i dokumentationssiden.

da du har valgt at bruge kernedata, oprettede Kcode automatisk en Datamodelfil til dig og kaldte den HitList.- datamodeld.

Åbn Hitlisten.- datamodeld. Som du kan se, har en kraftfuld Datamodeleditor:

Datamodeleditoren har mange funktioner, du kan udforske senere. Lad os nu fokusere på at oprette en enkelt Kernedataenhed.

Klik på Tilføj enhed nederst til venstre for at oprette en ny enhed. Dobbeltklik på den nye enhed, og skift navn til Person, som sådan:

du undrer dig måske over, hvorfor modeleditoren bruger udtrykket Entity. var du ikke bare ved at definere en ny klasse? Som du snart vil se, kommer kernedata med sit eget ordforråd. Her er en hurtig gennemgang af nogle udtryk, du ofte støder på:

  • en enhed er en klassedefinition i kernedata. Det klassiske eksempel er en Employee eller en Company. I en relationsdatabase svarer en enhed til en tabel.
  • en attribut er et stykke information knyttet til en bestemt enhed. For eksempel kan en Employee enhed have attributter for medarbejderens name, position og salary. I en database svarer en attribut til et bestemt felt i en tabel.
  • et forhold er et link mellem flere enheder. I kernedata kaldes relationer mellem to enheder til-en relationer, mens de mellem en og mange enheder kaldes til-mange relationer. For eksempel kan en Manager have et til mange forhold til et sæt medarbejdere, mens en person Employee normalt vil have et til-en forhold til sin leder.
Bemærk: du har sikkert bemærket, at enheder lyder meget som klasser. Ligeledes, attributter og relationer lyder meget som egenskaber. Hvad er forskellen? Du kan tænke på en Kernedataenhed som en klassedefinition og det administrerede objekt som en forekomst af den pågældende klasse.

nu ved du, hvad en attribut er, du kan tilføje en attribut til Person objekt oprettet tidligere. Stadig i hitlisten.vælg Person i venstre side og klik på plustegnet ( + ) under attributter.

Indstil den nye attributs navn til, er, navn og ændre dens type til streng:

i kernedata kan en attribut være af en af flere datatyper.

Lagring til kernedata

Åbn Visningskontroller.Hurtig, tilføj følgende Kernedatamodul import under import UIKit :

import CoreData

denne import er alt hvad du behøver for at begynde at bruge Core Data API i din kode.

udskift derefter names ejendomsdefinitionen med følgende:

var people: = 

du gemmer Personenheder i stedet for strengnavne, så du omdøber det array, der fungerer som tabelvisningens datamodel, til people. Det indeholder nu forekomster af NSManagedObject snarere end enkle strenge.

NSManagedObject repræsenterer et enkelt objekt, der er gemt i kernedata; du skal bruge det til at oprette, redigere, gemme og slette fra din vedvarende butik med kernedata. Som du snart vil se, er NSManagedObject en formskifter. Det kan tage form af enhver enhed i din datamodel og tildele de attributter og relationer, du har defineret.

da du ændrer tabelvisningens model, skal du også erstatte begge datakildemetoder, der er implementeret tidligere. Udskift din UITableViewDataSource udvidelse 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 væsentligste ændring af disse metoder forekommer i tableView(_:cellForRowAt:). I stedet for at matche celler med den tilsvarende streng i modelarrayet, matcher du nu celler med den tilsvarende NSManagedObject.

bemærk, hvordan du griber attributten namefra NSManagedObject. Det sker her:

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

hvorfor skal du gøre det? Som det viser sig, ved NSManagedObject ikke om attributten name, du definerede i din datamodel, så der er ingen måde at få adgang til den direkte med en ejendom. Den eneste måde, hvorpå kernedata giver mulighed for at læse værdien, er nøgleværdikodning, ofte benævnt KVC.

Bemærk: KVC er en mekanisme til at få adgang til et objekts egenskaber indirekte ved hjælp af strenge. I dette tilfælde gør KVC NSMangedObject opfører sig lidt som en ordbog ved kørsel.

Nøglekodning er tilgængelig for alle klasser, der arver fra NSObject, inklusive NSManagedObject. Du kan ikke få adgang til egenskaber ved hjælp af KVC på et hurtigt objekt, der ikke stammer fra NSObject.

find derefter addName(_:) og erstat 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 tager teksten i tekstfeltet og overfører den til en ny metode med navnet save(name:). Kcode klager, fordi save(name:) ikke findes endnu. Tilføj det nedenfor 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 kernedata sparker ind! Her er hvad koden gør:

  1. før du kan gemme eller hente noget fra din Core datalager, skal du først få dine hænder på en NSManagedObjectContext. Du kan betragte en administreret objektkontekst som en “scratchpad” i hukommelsen til at arbejde med administrerede objekter.

    tænk på at gemme et nyt administreret objekt i kernedata som en totrinsproces: først indsætter du et nyt administreret objekt i en administreret objektkontekst; når du er glad, “forpligter du” ændringerne i din administrerede objektkontekst for at gemme det på disken.

    Kcode har allerede genereret en administreret objektkontekst som en del af det nye projekts skabelon. Husk, at dette kun sker, hvis du markerer afkrydsningsfeltet Brug kernedata i starten. Denne standardkontekst for administreret objekt lever som en egenskab for NSPersistentContainer i programdelegatet. For at få adgang til det får du først en henvisning til appdelegatet.

  2. du opretter et nyt administreret objekt og indsætter det i konteksten administreret objekt. Du kan gøre dette i et trin med NSManagedObject‘s statiske metode: entity(forEntityName:in:).

    du undrer dig måske over, hvad en NSEntityDescription handler om. Husk tidligere, NSManagedObject blev kaldt en formskifterklasse, fordi den kan repræsentere enhver enhed. En objektbeskrivelse er det stykke, der forbinder enhedsdefinitionen fra din datamodel med en forekomst af NSManagedObject ved kørsel.

  1. med en NSManagedObject i hånden indstiller du attributten name ved hjælp af nøglekodning. Du skal stave KVC-tasten (name i dette tilfælde) nøjagtigt som den vises i din datamodel, ellers vil din app gå ned ved kørsel.
  2. du forpligter dine ændringer til person og gemmer på disken ved at ringe til save i den administrerede objektkontekst. Bemærk save kan kaste en fejl, hvorfor du kalder det ved hjælp af try nøgleordet inden for en do-catch blok. Til sidst skal du indsætte det nye administrerede objekt i people – arrayet, så det vises, når tabelvisningen genindlæses.

det er lidt mere kompliceret end at bruge en række strenge, men ikke så dårligt. Nogle af koden her, såsom at få den administrerede objektkontekst og enhed, kunne gøres kun en gang i din egen init() eller viewDidLoad() derefter genbruges senere. For enkelhed gør du det hele i samme metode.

Byg og kør appen, og tilføj et par navne til tabelvisningen:

hvis navnene faktisk er gemt i kernedata, skal HitList-appen bestå persistenstesten. Med appen i forgrunden skal du gå til den hurtige appskifter og derefter afslutte den.

fra Springboard skal du trykke på HitList-appen for at udløse en ny lancering. Vent, hvad skete der? Tabelvisningen er tom:

du gemte til kernedata, men efter en ny app-lancering er arrayet people tomt! Det skyldes, at dataene sidder på disken og venter på dig, men du viser dem ikke endnu.

hentning fra kernedata

for at hente data fra din vedvarende butik i den administrerede objektkontekst skal du hente den. Åbn Visningskontroller.hurtig og tilføj 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)") }}

trin for trin, Dette er hvad koden gør:

  1. før du kan gøre noget med kernedata, skal du have en administreret objektkontekst. Hentning er ikke anderledes! Som før trækker du applikationsdelegaten op og tager en henvisning til dens vedvarende container for at få dine hænder på dens NSManagedObjectContext.
  2. som navnet antyder, er NSFetchRequest den klasse, der er ansvarlig for at hente fra kernedata. Hent anmodninger er både kraftfulde og fleksible. Du kan bruge Hent anmodninger til at hente et sæt objekter, der opfylder de angivne kriterier (dvs. har været i virksomheden mindst tre år), individuelle værdier (dvs.give mig det længste navn i databasen) og mere.

    Hent anmodninger har flere kvalifikationer, der bruges til at forfine det sæt resultater, der returneres. For nu skal du vide NSEntityDescription er en af disse krævede kvalifikationer.

    Indstilling af en henteanmodnings entity egenskab, eller alternativt initialisering af den med init(entityName:), henter alle objekter fra en bestemt enhed. Dette er hvad du gør her for at hente alle Person enheder. Bemærk også NSFetchRequest er en generisk type. Denne brug af generika angiver en hentningsforespørgsels forventede returtype, i dette tilfælde NSManagedObject.

  3. du afleverer hentningsanmodningen til den administrerede objektkontekst for at gøre det tunge løft. fetch(_:) returnerer en række administrerede objekter, der opfylder de kriterier, der er angivet i hentningsanmodningen.

Bemærk: ligesom save() kan fetch(_:) også kaste en fejl, så du skal bruge den inden for en do blok. Hvis der opstod en fejl under hentningen, kan du inspicere fejlen inde i catch – blokken og svare korrekt.

Byg og kør programmet. Umiddelbart skal du se listen over Navne, du tilføjede tidligere:

fedt! De er tilbage fra de døde (ordspil beregnet). Tilføj et par flere navne til listen, og genstart appen for at kontrollere, at lagring og hentning fungerer. Kort for at slette appen, nulstille simulatoren eller smide din telefon fra en høj bygning, navnene vises i tabelvisningen uanset hvad.

Bemærk: Der var et par ru kanter i denne prøve app: du var nødt til at hente den administrerede objektkontekst fra appdelegatet hver gang, og du brugte KVC til at få adgang til en enheds attributter snarere end en mere naturlig objektstil person.name.

nøglepunkter

  • kernedata giver persistens på disken, hvilket betyder, at dine data vil være tilgængelige, selv efter at du har afsluttet din app eller lukket din enhed. Dette adskiller sig fra in-memory persistens, som kun gemmer dine data, så længe din app er i hukommelsen, enten i forgrunden eller i baggrunden.
  • kode leveres med en kraftfuld Datamodeleditor, som du kan bruge til at oprette din administrerede objektmodel.
  • en administreret objektmodel består af enheder, attributter og relationer
  • en enhed er en klassedefinition i kernedata.
  • en attribut er et stykke information knyttet til en enhed.
  • et forhold er et link mellem flere enheder.
  • en NSManagedObject er en kørselstidsrepræsentation af en Kernedataenhed. Du kan læse og skrive til dens attributter ved hjælp af nøgle-værdi kodning.
  • du har brug for en NSManagedObjectContext til save() eller fetch(_:) data til og fra kernedata.

hvor skal vi hen herfra?

du kan hente det afsluttede projekt til denne tutorial ved hjælp af knapperne “Hent materialer” øverst eller nederst i denne tutorial.

i denne vejledning har du allerede oplevet flere grundlæggende Kernedatakoncepter: datamodeller, enheder, attributter, administrerede objekter, administrerede objektkontekster og hent anmodninger.

hvis du nød det, du lærte i denne tutorial, hvorfor ikke tjekke den komplette kernedata af Tutorials bog, tilgængelig i vores butik?

her er en smagsprøve på, hvad der er i bogen:

1. Kapitel 1, Din første Core Data-App: du klikker på fil til nyt projekt og skriver en Core Data-app fra bunden! Dette kapitel dækker det grundlæggende ved opsætning af din datamodel og derefter Tilføjelse og hentning af poster.

2. Kapitel 2, Nsmanagedobject underklasser: NSManagedObject er basen datalagring klasse af dine centrale data objekt grafer. Dette kapitel vil lære dig, hvordan du tilpasser dine egne administrerede objekt underklasser til at gemme og validere data.

3. Kapitel 3, Kernedatastakken: under hætten består kernedata af mange dele, der arbejder sammen. I dette kapitel lærer du om, hvordan disse dele passer sammen, og bevæger dig væk fra startkodeskabelonen for at opbygge dit eget system, der kan tilpasses.

4. Kapitel 4, mellemliggende hentning: dine apps henter data hele tiden, og kernedata giver mange muligheder for at få dataene til dig effektivt. Dette kapitel dækker mere avancerede henteanmodninger, prædikater, sortering og asynkron hentning.

5. Kapitel 5, NSFetchedResultsController: Bordvisninger er kernen i mange iOS-apps, og Apple ønsker at få kernedata til at spille pænt med dem! I dette kapitel lærer du, hvordan NSFetchedResultsController kan spare dig tid og kode, når dine tabelvisninger understøttes af data fra kernedata.

6. Kapitel 6, versionsstyring og migrering: når du opdaterer og forbedrer din app, skal dens datamodel næsten helt sikkert ændres. I dette kapitel lærer du, hvordan du opretter flere versioner af din datamodel og derefter migrerer dine brugere fremad, så de kan beholde deres eksisterende data, når de opgraderer.

7. Kapitel 7, Unit Tests: Test er en vigtig del af udviklingsprocessen, og du bør ikke forlade kernedata ud af det! I dette kapitel lærer du, hvordan du opretter et separat testmiljø for kernedata og ser eksempler på, hvordan du tester dine modeller.

8. Kapitel 8: måling og forbedring af ydeevnen: Ingen har nogensinde klaget over, at en app var for hurtig, så det er vigtigt at være opmærksom på sporing af ydeevne. I dette kapitel lærer du, hvordan du måler din apps ydeevne med forskellige kodeværktøjer og derefter henter nogle tip til håndtering af langsomme pletter i din kode.

9. Kapitel 9, flere administrerede Objektkontekster: i dette sidste kapitel udvider du den sædvanlige Kernedatastak til at omfatte flere administrerede objektkontekster. Du lærer, hvordan dette kan forbedre den opfattede ydeevne og hjælpe med at gøre din apparkitektur mindre monolitisk og mere opdelt.

og for at hjælpe med at sødme aftalen er den digitale udgave af bogen til salg for $44,99! Men vent ikke-denne salgspris er kun tilgængelig i en begrænset periode.

Apropos søde tilbud, Sørg for at tjekke de fantastiske præmier, vi giver væk i år med iOS 11 Launch Party, inklusive over $9,000 i gaver!

for at være berettiget til denne episke iOS 12 — gave er alt hvad du skal gøre, at efterlade en kommentar til det originale lanceringsindlæg og fortælle os, hvilken bog eller kursus der er din favorit på denne liste-eller hvilken kommende bog eller kursus du er mest begejstret for!

vi håber du nyder denne opdatering, og hold øje med flere bogudgivelser og opdateringer!

raywenderlich.com ugentlig

den raywenderlich.com nyhedsbrev er den nemmeste måde at holde dig opdateret om alt hvad du behøver at vide som mobiludvikler.

få en ugentlig fordøjelse af vores tutorials og kurser, og modtag et gratis dybtgående e-mail-kursus som en bonus!

gennemsnitlig bedømmelse

4.6/5

Tilføj en bedømmelse for dette indhold

Log ind for at tilføje en bedømmelse

56 bedømmelser

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.