Data Persistens og Sandboxing på iOS
to
Del
10
Del
Dette Cyber mandag Envato Tuts + Kursene vil bli redusert til bare $ 3. Ikke gå glipp av
Dette innlegget er en del av en serie som heter Lær iOS SDK Development Fra Scratch.Exploring Tab Bar ControllerBuilding en handleliste Application From Scratch:. Del 1
Vedvarende data på tvers av programmer startes er et krav at de fleste iOS-applikasjoner har, fra å lagre brukerinnstillinger ved hjelp av brukerstandarder system for å håndtere store datasett i en relasjonsdatabase. I denne artikkelen vil vi utforske de mest vanlige strategier som brukes for lagring av data i en iOS-applikasjon. Jeg vil også snakke om filsystemet på iOS og hvordan søknaden sandboxing påvirker data utholdenhet.
Innledning
Du har kommet en lang vei, gresshoppe, og du har lært masse. Men det er en viktig del av iOS utvikling som vi ikke har diskutert ennå, data utholdenhet. Nesten hver iOS-programmet lagrer data for senere bruk. Dataene dine iOS-programmet lagrer kan være alt fra brukerinnstillinger til midlertidige cacher eller selv store relasjons datasett.
Før diskutere de vanligste data utholdenhet strategier utviklere har på iOS-plattformen, jeg først kommer til å tilbringe en noen minutter diskutere filsystemet og begrepet søknaden sandboxing. Trodde du virkelig at du kan lagre programmets data uansett hvor du vil på filsystemet? Tro om igjen, padawan.
File System og Application Sandboxing
Sikkerhet på iOS-plattformen har vært en av Apples topp prioritet helt siden iPhone ble lansert i 2007. I motsetning til OS X-programmer, er en iOS-applikasjon plassert i et program sandkasse. I motsetning til hva folk flest tror, ikke et program sandkasse ikke bare henvise til et program sandkasse katalog i filsystemet. Søknaden sandbox omfatter også kontrollert og begrenset tilgang til brukerdata som er lagret på enheten, systemtjenester og maskinvare.
Med introduksjonen av Mac App Store, har Apple begynt å håndheve søknad sandboxing på OS X, så vel . Selv om de begrensninger satt på OS X-programmer er ikke like strenge som de er pålagt iOS-applikasjoner, er det generelle begrepet like, men ikke identiske. Søknaden sandkasse av en iOS-applikasjon, for eksempel, inneholder programmet bundle, som ikke er sant for OS X-programmer. Årsakene til disse forskjellene er hovedsakelig historisk.
Sandboxing og Kataloger
operativsystemet installeres hver iOS program i en sandkasse katalogen, som inneholder programmet bunt katalog og ytterligere tre kataloger, dokumenter, Bibliotek og tmp. Programmets sandkasse katalog, ofte referert til som sitt hjemmeområde, kan nås ved å ringe en enkel Foundation funksjon, NSHomeDirectory ()
NSLog (@ "HOME >% @", NSHomeDirectory ());.
Du kan prøve dette selv. Opprett en ny Xcode prosjekt basert på Enkel visning Application mal og name it data Persistence
Åpne TSPAppDelegate.m Hotell og legge den over koden til søknaden. DidFinishLaunchingWithOptions :.
< p> Hvis du kjører programmet i iOS Simulator, vil produksjonen i konsollen se noe som utgangs vist nedenfor
2014-03-27 09: 48: 16,794 data Persistence. [1 426: 60b] HOME > /Users /Bart /Bibliotek /Application Support /iPhone Simulator /7.1 /Programmer /5024403A-C65E-44DD-BCD2-F93097FB502E
Men hvis du kjører programmet på en fysisk enhet, ser resultatet litt annerledes som du kan se nedenfor. Søknaden sandkasse og begrensningene er identiske om
2014-03-27 09: 48: 51,571 data Persistence [1 426: 60b]. HJEM > /var /mobile /Programmer /A4D17A73-84D7-4628-9E32-AEFEA5EE6153
Hente banen til dokumenter katalogen programmets krever litt mer arbeid som du kan se i kodebiten nedenfor.
NSArray * kataloger = NSSearchPathForDirectoriesInDomains (NSDocumentDirectory, NSUserDomainMask, YES); NSString * dokumenter = [kataloger firstObject]; NSLog (@ "DOKUMENTER >% @", dokumenter);
Vi bruker NSSearchPathForDirectoriesInDomains () -funksjonen og bestå NSDocumentDirectory konstant som det første argumentet for å vise at vi er bare interessert i Dokumenter-katalogen for programmet. Den andre og tredje argument er av mindre betydning for denne diskusjonen. Funksjonen returnerer en forekomst av NSArray inneholder ett resultat, banen til dokumenter katalogen programmets
Du lurer kanskje på hvorfor jeg bruker firstObject istedenfor objectAtIndex. Å hente den første og eneste objekt i forskjellige veier. Selv om jeg kan være ganske sikker på at matrisen som returneres ikke er tom, hvis matrisen skulle være tom og matrisen vil motta et budskap om objectAtIndex: med et argument fra 0, vil programmet krasje på grunn av en uoppfanget unntak <. br>
Ved å ringe firstObject på tabellen, men tabell returnerer nil hvis den ikke inneholder noen gjenstander, noe som betyr at intet unntak ville bli kastet. Husk at dokumentasjonen er din venn.
Hvorfor Sandboxing?
Hva er fordelen med sandboxing? Den primære årsaken til Sandboxing applikasjoner er sikkerhet. Ved å avgrense søknader til sin egen sandkasse, kan kompromittert programmer ikke føre til skade på operativsystemet eller andre programmer.
Etter kompromitterte applikasjoner, mener jeg begge programmene som har blitt hacket, programmer som er vilje ondsinnet, samt applikasjoner som inneholder kritiske feil som kan utilsiktet forårsake skade.
Selv om programmene er sandboxed på iOS-plattformen, kan iOS-applikasjoner be om tilgang til visse filer eller eiendeler som er utenfor deres søknad sandkasse gjennom en rekke systemgrensesnitt.
Et eksempel på dette er musikkbiblioteket som er lagret på en iOS-enhet. Vet imidlertid at systemet rammer er ansvarlig for alle fil relatert virksomhet ved slike anledninger.
What Goes Hvor?
Selv om du kan gjøre stort sett alt du vil i programmets sandkasse Apple har gitt noen retningslinjer med hensyn til hva som skal lagres der. Det er viktig å vite om disse retningslinjene for flere grunner. Når en iOS-enhet er støttet opp av iTunes, er ikke alle filene i et program sandkasse inkludert i sikkerhetskopien.
tmp, for eksempel, bør bare brukes til midlertidig lagring av filer. Operativsystemet er gratis å tømme denne katalogen til enhver tid, for eksempel når enheten er lite diskplass. tmp katalog er ikke inkludert i backup.
Dokumenter katalogen er ment for brukerdata, mens bibliotekkatalogen brukes for søknad data som ikke er strengt knyttet til brukeren. Den Caches katalogen i Bibliotek-katalogen er en annen katalog som ikke er støttet opp av iTunes.
Også huske på at søknaden din ikke er ment å endre innholdet i søknaden bunt katalogen. Søknaden bunt katalogen er signert når programmet er installert. Ved å endre innholdet i søknaden bunt katalogen på noen måte, er den nevnte signatur endret, noe som betyr at operativsystemet tillater ikke at programmet skal starte igjen. Dette er et annet sikkerhetstiltak satt på plass av Apple for å beskytte forbrukerne.
Data Persistence alternativer
Det er flere strategier for lagring av applikasjonsdata på disken. I denne artikkelen tar vi en kort titt på fire vanlige tilnærminger på iOS:
brukerstandarder
eiendomslister
SQLite
kjernedata
De alternativene som er beskrevet i denne artikkelen skal ikke betraktes som utskiftbare. Hver strategi har sine fordeler så vel som sine ulemper. La oss begynne med å ta en titt på brukerstandarder system.
Bruker Defaults
Den brukerstandarder system er noe som iOS arvet fra OS X. Selv om det ble laget og designet for lagre brukerinnstillinger, kan den brukes til lagring av alle typer data, så lenge det er en eiendom listetype, NSString, NSNumber, NSDate, NSArray, NSDictionary, og NSData, eller noen av deres foranderlig varianter.
brukerstandarder database er noe mer enn en samling av eiendoms lister, en eiendom liste per søknad. Eiendommen listen lagres i en mappe kalt Preferences i Bibliotek-mappen programmets, som antyder eiendommen liste hensikt og funksjon.
En av grunnene til at utviklere som brukerstandarder system er fordi det er så enkelt å bruke . Ta en titt på koden fragment nedenfor for å se hva jeg mener
NSUserDefaults * userDefaults = [NSUserDefaults standardUserDefaults] [userDefaults setBool: JA Forkey: @ "Key1"];. [UserDefaults setInteger: 123 Forkey: @ "NØKKEL2" ] [userDefaults setObject: @ "Noen Object" Forkey: @ "TAST3"] [userDefaults boolForKey: @ "Key1"] [userDefaults integerForKey: @ "NØKKEL2"] [userDefaults objectForKey: @ "TAST3"]; [ ,,,0],userDefaults synkron];
Ved å ringe standardUserDefaults klassen metoden på NSUserDefaults, en referanse til den delte mislighold objekt blir returnert
I den siste linjen, vi kaller synkron på de delte mislighold protestere å skrive. eventuelle endringer til disk. Det er sjelden nødvendig å påberope synkronisere, fordi brukerstandarder systemet lagrer endringer når det er nødvendig. Men hvis du lagrer eller oppdaterer en innstilling ved hjelp av brukerstandarder system, det kan noen ganger være nyttig eller nødvendig å eksplisitt lagre endringene i disken.
Ved første øyekast ser den brukerstandarder systemet til å være noe mer enn en nøkkelverdi butikken ligger på et bestemt sted. Men den NSUserDefaults klassen, definert i stiftelsen rammeverket, er mer enn et grensesnitt for å administrere en nøkkelverdi butikken. Ta en titt på sin klasse referanse for mer informasjon
Før vi går videre, lime over kodebiten i søknaden delegere sin søknad:. DidFinishLaunchingWithOptions: metode og kjøre programmet på iOS Simulator. Åpne et nytt Finder-vindu og gå til bibliotek > Application Support > iPhone Simulator > 7.1 > Applikasjoner (bytt ut
"7.1" med den nyeste versjonen av iOS).
Finn programmappen som korresponderer med søknaden ved å inspisere de ulike, kryptisk navngitte mapper i Programmer-mappen. Den kryptisk heter mappen er faktisk programmet sandkasse katalogen. I søknaden sandkasse katalogen, åpne Innstillinger-mappen, som ligger i Bibliotek-mappen, og inspisere innholdet.
Du bør se en eiendom liste med navn identisk med programmets bunt identifikator. Dette er brukerstandarder butikken for søknaden din.
Hvis du ønsker å gjøre det enklere å få tilgang til sandkasse av en søknad i iOS Simulator, så anbefaler jeg på det sterkeste at du tar en titt på SimPholders. Det er et gratis verktøy som gjør arbeidet med iOS Simulator mye enklere.
Eiendom Lister
Vi har allerede dekket eiendomslister i denne serien. Som et spørsmål om faktum, kompet lageret for brukerstandarder database er en egenskap listen. Ved hjelp av eiendomslister er en praktisk strategi for å lagre og hente en gjenstand grafen. Eiendomslister har eksistert i aldre, er enkle å bruke, og de er derfor en flott mulighet for lagring av data i en iOS-applikasjon.
Som jeg nevnte tidligere, er det viktig å huske på at en eiendom liste kan bare lagre eiendomslistedata. Betyr dette at det ikke er mulig å lagre tilpassede modell objekter ved hjelp av eiendoms lister? Nei, det er mulig. Men custom modell objekter må arkiveres-en form for serialisering-før de kan lagres i en eiendom listen. Arkivering et objekt betyr ganske enkelt at objektet må konverteres til en datatype som kan lagres i en eiendom liste, for eksempel en NSData eksempel.
Arkivering Objekter
Husker du NSCoding protokoll definert i stiftelsen rammeverk? Den NSCoding protokollen definerer to metodene, initWithCoder: og encodeWithCoder :, som en klasse må iverksette for å tillate forekomster av klassen som skal kodes og dekodes
Koding og dekoding er de underliggende mekanismene for objekt arkivering og distribusjon.. Hvordan protestere arkiv arbeidene vil bli klart litt senere i denne serien. I denne leksjonen jeg bare vise deg hvordan du skriver arrays og ordbøker til disk ved hjelp av eiendoms lister.
Skrive til fil
Følgende kodebiten bør gi deg en idé om hvor lett det er å skrive en matrise eller ordbok for å disk. I teorien kan objektet grafen lagret i en eiendom liste være så komplisert eller så stort som du ønsker. Men husk at eiendomslistene ikke er ment til å lagre flere titalls eller hundrevis av megabyte med data, forsøker å bruke dem på den måten vil trolig føre til dårligere ytelse.
NSArray * frukt = @ [@ "Apple", @ "Mango", @ "Pineapple", @ "Plum", @ "Apricot"]; NSString * filePathFruits = [dokumenter stringByAppendingPathComponent: @ "fruits.plist"]; [frukt writeToFile: filePathFruits atomically: YES]; NSDictionary * miscDictionary = @ {@ "anArray": frukt, @ "AAntall": @ 12345, @ "aBoolean":YES}; NSString * filePathDictionary = [dokumenter stringByAppendingPathComponent: @ "misc-dictionary.plist"] [miscDictionary writeToFile: filePathDictionary atomically : YES]; NSArray * loadedFruits = [NSArray arrayWithContentsOfFile: filePathFruits]; NSLog (@ "Fruits Array >% @", loadedFruits); NSDictionary * loadedMiscDictionary = [NSDictionary dictionaryWithContentsOfFile: filePathDictionary]; NSLog (@ "Diverse ordbok >% @ ", loadedMiscDictionary);
La oss ta en titt på den ovennevnte kodebiten. Vi starter ved å lagre en referanse til en matrise bokstavelig i en variabel som heter frukt. Vi skaper filbanen for lagring av eiendommen listen som vi er i ferd med å gjøre. Filbanen er opprettet ved å føye til en streng til filen banen til Dokumenter-katalogen, som vi hentet tidligere i denne leksjonen. Strengen som vi føye vil være navnet på eiendommen list-inkludert dens forlengelse, Plist-at vi skal skape i et sekund
Skrive matrisen til disk er like enkelt som å ringe writeToFile. Atomically: på matrisen. Du kan ignorere atomically flagget for nå.
Som eksemplet viser, skriver en ordbok for å disk følger et lignende mønster. Eksempelet illustrerer også hvordan å lage arrays og ordbøker fra en eiendom liste, men dette er noe som vi allerede dekket tidligere i denne serien.
Kjør programmet i iOS Simulator og naviger til programmets Dokumenter katalog som vi så tidligere. I denne katalogen, bør du se de to eiendoms listene vi nettopp opprettet.
SQLite
Hvis søknaden er datadrevet og arbeider med store mengder data, så vil du kanskje å se inn SQLite. Hva er SQLite? Slagord på SQLite hjemmeside leser "Small. Fast. Pålitelig. Velg hvilken som helst tre.", Som oppsummerer det pent.
SQLite er et bibliotek som implementerer en lett innebygd relasjonsdatabase. Som navnet tilsier, er det basert på SQL-standarden ( Structured Query Language
) akkurat som MySQL og PostgreSQL.
Den største forskjellen med andre SQL databaser er at SQLite er bærbar, veldig lett, og at det er server i stedet for en egen prosess nås fra klientprogrammet. Med andre ord, det er innebygd i programmet, og derfor veldig fort.
SQLite nettsted hevder at det er den mest utbredte SQL database. Jeg vet ikke om det er fortsatt tilfelle, men det er absolutt et populært valg for klientsiden datalagring. Aperture og iPhoto, for eksempel, er avhengige av SQLite for noen av sine data lagring.
Fordelen SQLite har over arbeider direkte med objekter er at SQLite er størrelsesordener raskere, noe som skyldes i stor grad hvordan relasjonsdatabaser og objektorientert programmeringsspråk fundamentalt forskjellig.
For å bygge bro over gapet mellom SQLite og Objective-C, en rekke Objektrelasjons Kartlegging
(ORM) løsninger har blitt skapt over tid. ORM at Apple har skapt for iOS og OS X heter kjernedata
, som vi tar en titt på senere i denne leksjonen.
Flying Meat sin FMDB
Ved hjelp av SQLite på iOS innebærer arbeid med et C-basert bibliotek. Hvis du foretrekker et objektorientert løsning, så jeg anbefaler Gus Mueller (Flying Meat, Inc.) Objective-C wrapper for SQLite, FMDB.
Det gjør arbeidet med SQLite mye lettere hvis du foretrekker et objektorientert grensesnitt . Biblioteket støtter ARC ( Automatic Reference Counting
) ut av boksen, og er veldig performant. Jeg har brukt FMDB i det siste og har vært veldig fornøyd med sin API og bibliotekets robusthet og pålitelighet.
Kjerne data
Developers ny til Core data ofte feil kjernedata for en database mens det egentlig er et objekt relasjons kartlegging løsning skapt og vedlikeholdt av Apple. Matt Gallagher har skrevet et flott innlegg om forskjellene mellom kjernedata og en database. Kjernen data gir en relasjonsobjektorientert modell som kan serialisert i en XML, binær eller SQLite butikken. Kjernen data støtter til og med en in-memory butikken.
Hvorfor skal du bruke kjernedata i stedet for SQLite? Ved å stille dette spørsmålet, du feilaktig anta at kjernedata er en database. Fordelen med å bruke Core-data er at du arbeider med objekter i stedet for rå data, for eksempel rader i en SQLite database eller data som er lagret i en XML-fil. Selv om kjernedata hatt noen vanskelige år da den først ble lansert, har det vokst til et robust rammeverk med en rekke funksjoner, som for eksempel automatiske overføringer, sporing av endringer, forkastninger og integrert validering.
En annen flott funksjon at mange utviklere setter pris på er Core datamodellen redaktør bygget inn Xcode som lar utviklere modellere sin datamodell gjennom et grafisk grensesnitt.
Enten Kjerne data er den riktige løsningen for din søknad er avhengig av data som du har tenkt å administrere både når det gjelder kvantitet så vel som den underliggende modell. Hvis du har tenkt å håndtere svært store datasett, da kjernedata kan bli en forestilling flaskehals over tid. I så fall kan SQLite være en bedre løsning.
iCloud
Du har sikkert hørt om iCloud, og du kan lure på hvor iCloud passer inn i historien av data utholdenhet. iCloud er ikke en form for data utholdenhet som SQLite eller Core data er. I stedet er det en plattform eller en tjeneste for å gjøre brukerdata tilgjengelig på tvers av flere enheter og flere forekomster av et program eller til og med en familie av programmer.
omfatter iCloud plattformen flere tjenester eller komponenter. Komponenten som interesserer oss er iCloud Storage
, som omfatter tre typer lagring:
nøkkelverdi lagring
dokumentlagring
Kjerne datalagring.
Hvis du vil lese mer om iCloud Storage, jeg anbefaler å lese en serie om iCloud Storage som jeg skrev tidligere i år.
Konklusjon
Du skal nå ha en god idé av alternativene du har når det gjelder data utholdenhet når du utvikler for iOS-plattformen. Husk at ikke alle strategier som vi har dekket er like.
Denne serien er sakte kommer til en avslutning. I de neste to terminer, vil vi lage et annet program for å sette det vi har lært så langt i praksis. Den beste måten å lære på er ved å gjøre.