Programování pro iOS - 6. Ukládání dat - MujMAC.cz - Apple, Mac OS X, Apple iPod

Navigace:  » Úvodní stránka  » Rubriky  » Software  

8. září 2010, 00.00 | Je čas začít doplňovat další služby, které funkci aplikace dále zdokonalí. Začneme ukládáním dat.

Každá aplikace v iOS se musí postarat o průběžné ukládání rozpracovaných dat, v našem případě jde o pole předcházejících měření, a o jejich automatické načtení po ukončení a novém spuštění.

To proto, že aplikace v iOS může být ukončena doslova kdykoli: až do verze 3 vedlo "deaktivování" aplikace stisknutím tlačítka "Home" vždy nutně k jejímu ukončení. V iOS 4 je to poněkud složitější, aplikace za těchto okolností normálně není ukončena ale jen pozastavena; na věci to však nic zásadního nemění, protože systém stejně může pozastavenou aplikaci kdykoli násilně ukončit, pokud se ukáže, že je zapotřebí uvolnit paměť.

Kdy ukládat?

Nejjednodušší přístup – v iOS až do verze 3 mnohdy plně funkční – spočíval ve využití základních metod delegáta aplikace, případně jim ekvivalentních notifikací (co je to notifikace?), pokud by přímá vazba mezi aplikačním delegátem a objektem, s nímž pracujeme, nebyla vhodná:

• v rámci metody application:didFinishLaunchingWithOptions: nebo na základě notifikace UIApplicationDidFinishLaunchingNotification nebo – nejspíše – při inicializaci daného objektu data načíst z disku, pokud odpovídající soubor existuje;
• v rámci metody applicationWillTerminate: aplikačního delegáta nebo na základě notifikace UIApplicationWillTerminateNotification data uložit do souboru.

Tento přístup má ale dvě nevýhody.

Prvá z nich je novinkou v iOS 4 a lze ji obejít, avšak přidělá nám to další práci: jde o to, že v iOS 4 se obecně nelze spolehnout na to, že aplikace notifikaci o ukončení dostane. Speciálně, pokud je zde aplikace pozastavena v pozadí a je zapotřebí ji ukončit, notifikace UIApplicationWillTerminateNotification se již neposílá; aplikace je ukončena aniž by nejprve byla opět aktivována. Je samozřejmě možné data ukládat také při notifikaci UIApplicationDidEnterBackgroundNotification (a/nebo v metodě applicationDidEnterBackground:); zde ale opět situaci komplikuje to, že jde o novinku iOS 4, která v předchozích verzích nebyla k dispozici.

Druhá nevýhoda platí zcela obecně pro libovolnou aplikaci: nikdo není neomylný, a ačkoli by se to samozřejmě stávat nemělo, vždy je možné, že aplikace vinou nějaké chyby "spadne". V takovém případě samozřejmě žádnou notifikaci nedostane a data jsou ztracena.

Proto je obecně lepší data ukládat hned po změně.

U aplikací, jež pracují s rozsáhlými daty a v nichž jsou běžné časté úpravy, ovšem nelze ukládat po každé změně, protože by to uživatele neúnosně zdržovalo. Zde je řešením po každé změně naplánovat uložení dat např. za minutu; fakticky tedy budou zapsána na disk teprve minutu po poslední úpravě. To je ale složitější – mj. i proto, že je nutné data zapsat také v případě, že je náhodou aplikace ukončena zrovna v průběhu této minuty –, a proto se tím nyní nebudeme zabývat. Naše jednoduchá aplikace to ani nemá zapotřebí; my si můžeme dovolit snadno data ukládat hned po každém měření.

Kam ukládat?

Na rozdíl od Mac OS X, kde aplikace v podstatě má volný přístup v rámci uživatelské složky kamkoli bez omezení, iOS pro větší bezpečnost nabízí daleko limitovanější prostředí: každá aplikace má k dispozici jen vlastní složku, tzv. "sandbox", a nikam jinam zapisovat nesmí (ačkoli přístupová práva sama o sobě by jí v tom nebránila).

Programátor se tím naštěstí nemusí detailně zabývat, protože v knihovnách Foundation je k dispozici standardní služba NSSearchPathForDirectoriesInDomains, jejímž prostřednictvím získáme pro každou z možných složek odpovídající cestu (a to bez ohledu na prostředí, v němž naše aplikace běží – tyto cesty jsou např. zcela zásadně odlišné pro simulátor a pro iPhone). Funkce má tři argumenty; první určuje požadovanou složku, druhý je v iOS vždy NSUserDomainMask a třetí YES – ostatní možnosti mají smysl v Mac OS X, ale ne zde. Smysluplné hodnoty pro prvý argument v iOS jsou dvě:

• NSDocumentDirectory je dokumentová složka, do níž můžeme ukládat data, jež mají být zálohována a synchronizována s počítačem;
• NSCachesDirectory je dokumentová složka, do níž ukládáme data, která nemají být zálohována a synchronizována s počítačem.

My zde samozřejmě použijeme prvou z nich.

Funkce NSSearchPathForDirectoriesInDomains vrací pole; v iOS ale je toto pole (alespoň v současnosti) vždy jednoprvkové – možnost existence více alternativních složek je běžná v Mac OS X. Metoda, která nám vždy vrátí dokumentovou složku, by tedy mohla vypadat např. takto:

-(NSString*)dataFolderPath {
  return [NSSearchPathForDirectoriesInDomains(
    NSDocumentDirectory, NSUserDomainMask, YES) lastObject];
}

Jak ukládat?

Asi nejobecnější a nejflexibilnější možnost pro ukládání datových souborů v iOS je zajištěna prostřednictvím knihoven CoreData – ty zde nabízejí téměř stejné služby jako v Mac OS X, kde jsme se s touto knihovnou již zběžně setkali.

Používat ale knihoven CoreData pro ukládání jednoduchého pole by byl nesmysl; na to nalezneme v knihovně Foundation lepší služby. Vůbec nejjednodušší – a pro naši aplikaci zcela postačující – jsou základní metody writeToFile:atomically: a arrayWithContentsOfFile: (pokud bychom do slovníků ukládali něco "exotičtějšího", mohlo by být vhodnější sáhnout po archivaci pomocí třídy NSKeyedArchiver).

Je asi zřejmé, jak a kam by bylo v aplikaci možné přidat uložení dat a jejich načtení; my si ale ukážeme zajímavější řešení pomocí zástupného objektu (proxy), který data načítá i ukládá automaticky.

Zástupný objekt pro automatické načtení i uložení dat

Objective C a jeho plně dynamický objektový model nabízí řadu velmi hezkých možností. Jednou z nich je to, že můžeme sestavit třídu, jejíž instance se chová přesně stejně jako pole NSMutableArray; navíc ale zcela automaticky uloží svůj obsah na disk po jakékoli změně – a stejně automaticky se jej pokusí při prvém použití z disku načíst.

Ukážeme si nejprve kompletní kód – je celkem jednoduchý; pak si vysvětlíme, jak přesně funguje:

// OCSAutosavedMutableArray.h
#import <Foundation/Foundation.h>
@interface OCSAutosavedMutableArray:NSProxy {
  NSMutableArray *contents;
}
+(NSMutableArray*)array;
@end

Jak je vidět již z rozhraní, zástupný objekt bude obsahovat vnořené pole; pro inicializaci podporuje pro zjednodušení pouze metodu array (je ale zřejmé, jak bychom – pokud by to bylo zapotřebí – mohli implementovat i všechny ostatní). Implementace by pak mohla vypadat např. takto:

// OCSAutosavedMutableArray.m
#import "OCSAutosavedMutableArray.h"

@implementation OCSAutosavedMutableArray
+(NSMutableArray*)array {
  NSMutableArray *new=
    (NSMutableArray*)[[self alloc] autorelease];
  return new;
}
-(void)dealloc {
    [contents release];
    [super dealloc];
}
-(NSString*)contentsPath {
  return [[NSSearchPathForDirectoriesInDomains(
    NSDocumentDirectory, NSUserDomainMask, YES) lastObject]
    stringByAppendingPathComponent:@"SavedHistory.plist"];
}
-(NSMethodSignature*)methodSignatureForSelector:(SEL)sel {
  return
    [NSMutableArray instanceMethodSignatureForSelector:sel];
}
-(void)forwardInvocation:(NSInvocation*)inv {
  if (!contents &&
    !(contents=[[NSMutableArray
      arrayWithContentsOfFile:[self contentsPath]] retain]))
    contents=[[NSMutableArray alloc] init];
  [inv invokeWithTarget:contents];
  if (inv.selector==@selector(addObject:))
    [contents writeToFile:[self contentsPath] atomically:NO];
}
@end

Smysl pomocné metody contentsPath je zřejmý. Metoda array je triviální; jediné, co snad není na prvý pohled vidět, je důvod, proč nepoužíváme init – prostě proto, že (a) standardní třída NSProxy tuto metodu nemá, a (b) nebylo zapotřebí, abychom ji sami implementovali. Metoda dealloc je zcela standardní součást správy paměti.

Zbývá tedy dvojice metod methodSignatureForSelector: a forwardInvocation:; jejich prostřednictvím je implementováno zcela standardní přesměrování zpráv, které je základem všech zástupných objektů.

Navíc zde je pouze

• kód před voláním služby invokeWithTarget: – ten celkem zřejmým a triviálním způsobem zajistí, že pokud vložené pole objektů dosud neexistuje, pokusíme se jej nejprve načíst z disku; teprve pokud se to nepodaří, vytvoříme pole prázdné;
• kód za ním, který zjistí, zda došlo ke změně obsahu pole – a pokud ano, zapíše je na disk (zde jsme si malinko usnadnili práci, protože víme, že pro změnu používáme pouze zprávu addObject:; pokud by zástupný objekt měl být zcela obecný, museli bychom do podmínky uložit selektory všech pěti primitivních metod třídy NSMutableArray).

Tím jsme takřka hotovi; zbývá pouze použít zástupný objekt namísto pole. Jeho vytvoření samozřejmě musíme nyní přemístit do inicializačního kódu (jinak by ze zřejmých důvodů nefungovaly např. dotazy typu "if (self.history.count==0)" v metodě showHistory). Mohli bychom použít standardní metodu init; v řídicím objektu rámce je ale možná pohodlnější metoda viewDidLoad, která se vždy provede poté, co je z objektové sítě načten sám rámec:

// MainViewController.m
...
#import "OCSAutosavedMutableArray.h"
...
-(void)viewDidLoad {
  [super viewDidLoad];
  self.history=[OCSAutosavedMutableArray array];
}
...

Z metody rangeButtonTapped jsme samozřejmě vypustili příkaz "if (!self.history) self.history=[NSMutableArray array]", ale kdybychom na to náhodou zapomněli, nic by se nestalo.

Zčásti jsme se tím samozřejmě připravili o výhody inicializace na vyžádání. Pokud bychom ji chtěli dodržet i nadále, stálo by to malilinko více práce – museli bychom si přístupovou metodu pro získání atributu history implementovat sami (a nenechat to na direktivě @synthesize), a v jejím kódu objekt OCSAutosavedMutableArray vytvořit, pokud ještě neexistoval.

V příštím dílu využijeme flexibility kódu, který jsme právě napsali, pro korektní uvolnění paměti, když si to systém vyžádá – a pak se už pustíme do práce s uživatelskými předvolbami.