Po deseti minutách se pouze přeruší spojení aplikace s internetem. Na serveru Meeba však stále budete online a pokud vám někdo napíše, dojde vám push notifikace. Po znovuotevření aplikace během chvíle bude navázáno spojení a můžete vesele chatovat dál.

Informace jsme s laskavým svolením autora doplnili do článku ;-)

Aplikace může reagovat celkem na 6 stavů a tyto stavy jsou:

applicationWillResignActive

applicationDidEnterBackground

applicationWillEnterForeground

applicationDidBecomeActive

applicationWillTerminate

applicationDidReceiveMemoryWarning

Nyní se pokusím tyto stavy popsat blíže.

applicationWillResignActive – tento stav v překladu znamená, že aplikace bude v budoucnu (otázka několika málo milisekund) rezignovat na post aktivní aplikace (tedy aplikace v popředí) toto se děje například při příjmu hovoru v době používání aplikace, ale zároveň se tato metoda tedy tento stav vyvolá i před přechodem aplikace do pozadí tedy je potřeba s těmito změnamy počítat. Tato metoda je vhodná také pro to aby například právě při příchozím hovoru pozastavila veškerou činnost, kterou provadí a počkala až na ukončení hovoru.

applicationDidEnterBackground – tento stav indikuje, že aplikace vešla do pozadí, vývojáři by tuto metodu měli využít k pozastavení všech procesů, které nutně nemusí běžet na pozadí a měli by vyčistit paměť od nevyužívaných dat a dalších procesů například by měli ukončit platnost časovačů, vymazat z paměti načtené obrázky, které nebudou nutně potřeba a nebo ukončit spojení se servery pokud to pro běh aplikace není kritické aby spojení dokončovala i na pozadí. V podstatě tato metoda když je v aplikaci vyvolána by měla sloužit k úplnému pozastavení aplikace pokud některá její část není požadována aby běžela na pozadí.

applicationWillEnterForeground – tento stav je opakem stavu prvního kdy aplikace bude rezignovat na aktivní stav. Tento stav aplikace jednoduše znamená, že uspaná aplikace během několika následujících milisekund bude obnovena z pozadí a zobrazí se na popředí (aplikace vstoupí do popředí), tuto metodu by vývojáři měli využít k obnovení všech procesů, které byly neaktivní v době kdy aplikace byla na pozadí, mělo by dojít k obnovení spojení se servery, znovunastavení časovačů, načtení obrázků a dat do paměti a další potřebné procesy se mohou obnovit těsně před tím, než uživatel znovu uvidí načtenou aplikaci.

applicationDidBecomeActive – tento stav indikuje to, že aplikace se po obnovení do popředí stala právě aktivní, toto je metoda, která se dá využít k dodatečným úpravám uživatelského rozhraní nebo obnovení UI do původního stavu apod. tato metoda se vlastně děje ve chvíli kdy aplikaci už uživatel na displeji vidí, tedy je potřeba z rozvahou určovat co se děje v metodě této a v metodě předchozí. Jsou volány po sobě s rozdílem několika málo milisekund.

applicationWillTerminate – tento stav se děje několik milisekund před ukončením aplikace, tedy před skutečným ukončením aplikace. Buď ručně z multitaskingu, nebo při vypínání přístroje. Tato metoda by měla být využita k uložení rozpracovaných dat a k ukončení všech činností a odstranění dat, které již nebudou potřeba.

applicationDidReceiveMemoryWarning – a toto je stav, o kterém se tu diskutuje hodně, že v případě nutnosti iOS odstraní z paměti aplikaci, pokud zbytečně využívá systémových prostředků. Nevím konkrétně co dělá iOS s aplikacemi v pozadí, ale pokud potřebuje po aplikaci aby uvolnila prostředky jiným procesům vyzve jí varováním paměti aby uvolnila prostředky, které má v držení. Tedy se v aplikaci vyvolá tato metoda a to by vývojáři měli implementovat tak aby se aplikace vzdala paměti, kterou má v držení, uložila rozpracované a vymazala nepotřebná data z paměti a jinak adekvátně uvolnila pamět. Je pravda, že hodně vývojářů, třeba začínajících na takovéto věci nemyslí nebo jim nerozumí a pak se může dít, že jejich aplikace ohrožuje výdrž baterie a/nebo zbytečně konzumuje systémové prostředky i v pozadí. Nevím jak se iOS zachová když aplikace po obdržení memory warningu neudělá nic a dále konzumuje systémové prostředky jako předtím.

Těchto pár stavů a tomu přidružených metod je v pozadí celého „multitaskingu“ v iOS… je to skvělý systém pokud vývojáři neignorují to, že je potřeba zodpovědně přistupovat k tomu co aplikace natropí na přístrojích jejich uživatelů pokud jsou minimalizovány nebo dostanou varování od systému a další…

Doufám, že tento stručný popis pomůže porozumět tomu jak se aplikace podílí na tom aby vše hladce fungovalo. Takže je skoro možné říci, že je to chybou nesprávného používání uživatelem což lze chápat jako – používáte-li aplikace povětšinou zdarma od amatérských vývojářů ve velkém množství tak vám iOS zařízení poběží hůř, než když používáte ve velkém množství zdarma i placené aplikace od zkušených či profesionálních vývojářů. Tím nechci říct, že nejsou v obou kruzích vyjímky. Docela dost divně a náročně se chová třeba foursquare a přitom by se dalo již očekávat, že se jedná o velice zdatné vývojáře, kteří memory a battery managementu dají mnoho času, opak je ale pravdou. Největším problémem 4SQ je komunikace se servery, která často vázne a je přehlcena. To jen jako ukázka toho, že i známé aplikace mají problémy což nic nemění na tom, že 4SQ je super služba.

Mějte se Jablíčkově!! :)