Zajímavá úvaha se objevila na stránkách TidBITs. Pochopitelně se jedná o jednu z nejčastějších výtek k iPhone OS, zejména při uvedení iPadu, ve kterém Apple nedovoluje multitasking, což byla jedna z největších chyb, která byl vyčítána Mac OS od verze Systému 5. Pochopitelně za tím stojů zdůvodnění, že běh aplikací na pozadí může výrazně snížit výkon a výdrž baterií. V iPhone 3.0 přidal Apple push notifikaci, která vyřeší některé - avšak v žádném případě všechny - problémy těch, kteří potřebují multitasking.
Avšak pro většinu případu, požadavek na multitasking usnul při vypuštění iPhone OS 3.0 a jeho push notifikací. Ne že by touha po multitaskingu usnula, ale spíše se debata ustálila.
Oznámení iPadu však vše změnilo, protože obsahuje rychlé CPU (ačkoliv jak moc rychlé není dosud zřejmé), 10 hodin provozu na baterie při srovnání s 5 - 10 hodinami iPhone a rozlišení 1024x768 má mnohem více místa než rozlišení 480x320 u iPhone. Delší výdrž baterií může snížit obavy Apple o běh více aplikací najednou. Větší plocha také zvyšuje možnost běhu více aplikací bok po boku.
A hlavně, zatímco iPhone je zaměřen na krátké a rychlé úlohy, iPad je zamýšlen pro zásadnější úlohy, které zahrnují použití více aplikací, tak jak jsme zvyklí u běžného počítače. Je jednoduché si představit iPad pro čtení textu v mobilním Safari, překopírovat text do dokumentu v Pages a poslat kolegovi dokument emailem. Ačkoliv tento specifický úkol je možné provést se současným iPhone OS, ukazuje že je potřeba více cesta jak mezi sebou budou aplikace v iPadu spolupracovat.
Pokud Apple opravdu plánuje v budoucnosti přijít s dokonce většími zařízeními na bázi iPhone, multitasking bude klíčem. Je těžké si představit že u Maca s obrovskou obrazovkou můžete běhat jen s jednou aplikaci najednou.
Co ale opravdu míníme tím, když říkáme že iPhone OS by měl podporovat multitasking? Pokud definujeme podrobněji to co potřebujeme, může být jednodušší přesvědčit Apple k jeho podpoře v iPhone OS 4.0 a výše.
Push Notification
Je nejjednodušší formou multitaskingu, kterou Apple zpřístupnil vývojářům V zásadě se aplikace registruje u push notification služby, která běží na systémové úrovni. Když taková událost přijde, iPhone OS ji prezentuje jako by přišla z aplikace.
Notifikace (upozornění) je primární věcí, kterou lidé od multitaskingu potřebují. Jeden program, který je schopen upozornit uživatele na událost i když vlastní aplikace není aktivní. Na Macu se zamyslete nad iCalem - potřebujete vědět o zprávu o schůzce, bez závislosti na tom, jakou aplikaci právě používáte, to je však možné pouze tehdy, pokud další proces dává pozor na pozadí a je schopen přerušit běh aplikace na popředí.
Problém s push notifikací je v tom, že všechny odpovídají na externí změnu ve službách jako AIM či Twitter a nikoliv změnám stavu v aplikacích na pozadí. To je samozřejmě možné i u iPhone OS, u kalendáře či budíku, který evidentně umí naplánovat interní notifikace pro určité časy. Ale Apple tuto možnost neotevřel pro vývojáře.
Aktualizace stavu na pozadí
Další cestou jakou přemýšlíme o multitaskingu je aktualizace stavu v na pozadí. To je také možné i u iPhone OS, ale pouze pro aplikace od Apple. Jestliže jste stáhli novou poštu do Mailu, nastavili Kontakty a Kalendář pro podporu Push, nové emailové zprávy změní kontakty a kalendář automaticky. To je důvodem, proč nemusíte obnovovat Kontakty a Kalendář kvůli aktualizaci změn. U Mailu musí stále kontrolovat nové zprávy (nebo počkat na časovač, dokud se nespustí kontrola) u účtů, které nepodporují push.
Zatímco aplikace Apple si našli cestu, jak běhat i na pozadí, Apple tuto možnost neotevřel pro vývojáře. Twitter aplikace a RSS čtečky mohou využít čas na pozadí ke své aktualizaci.
Je třeba rozlišit pravidelné aktualizace pro aplikace jako Twitter nebo RSS a neustálý běh na pozadí. Je jedno, pokud Twitter klient nebo RSS čtečka načítá obsah každou vteřinu, protože při každém obnovení může zobrazit také staré zprávy, avšak messaging aplikace může zcela vypustit klíčovou informaci, pokud přišla ve špatnou dobu (a server neudržuje stav s klientem). To je důvod proč chat aplikace nebo GPS aplikace mohou potřebovat, aby běhaly po celou dobu, protože plánovaný běh by nebyl dostatečně rychlý nebo kompletní.
Je zřejmé že to je věc, kterou by Apple mohl udělat, protože je k dispozici pro pár aplikací Apple.
Komunikace mezi aplikacemi
Na Macovi jsme zvyklí, že aplikace se mohou mezi sebou vyměňovat dat. Klepnutí na URL v Mailu otevře Firefox, Firefox pošle zprávu Growl, že dorazil stahovaný soubor. iTunes ovladač zobrazuje aktuální přehrávanou skladbu či Finder, který říká aplikace aby otevřela dokument.
Pár těchto schopností má také iPhone, jak třeba otevření URL z emailové zprávy v Safari, vytvoření emailové zprávy s fotografie či zobrazení adresy na Mapě. Ale to jsou opět aplikace Apple. Jedním z mála příkladů z opačné strany je Boxcar, který může otevřít několik Twitter aplikací jako odpověď na Tweet zprávu. Ale Boxcar je velmi omezený, může sice otevřít aplikaci na Twitteru, ale nemůže ovládat tuto aplikaci, jako třeba zobrazit příslušný příspěvek.
Důvodem je, že hlavním kanálem pro komunikaci mezi aplikacemi je URL a šířka tohoto kanálu závisí na tom, jak robustní je funkce, která zpracovává URL v aplikaci a jak moc je využívána vývojářem aplikace. Ale její vliv je omezený: informace se musí dostat celá do URL a je pouze jednosměrná - cílová aplikace nemůže poslat žádnou informaci zpět. Navíc v současném iPhone OS jsou sobory soukromým vlastnictvím každé aplikace, takže žádná aplikace nemůže poslat odkaz na soubor jiné aplikace.
Asi je možné si představit budoucí verzi iPhone OS, kde se rozšíří práce s URL o možnost pracovat se soubory ve sdíleném prostředí a možná vrátit další URL zpět aplikaci, která začala komunikaci. Taková komunikace bez nutnosti aby obě aplikace byly aktivní by zcela jistě nesnižovala výdrž baterie a výkon. Uživatel by pak také nemusel přeskakovat mezi aplikacemi manuálně jako dosud. Je to však stále nepohodlná cesta pro komunikaci, narozdíl od Apple Event systému vestavěného do Mac OS, který umožňuje aplikacím komunikovat mezi sebou.
Apple Events mohou fungovat pouze pokud cílová aplikace běží, takže je těžké si takový systém představit u iPhone OS, který je výrazně omezen co se týče CPU a RAM. Těžko si lze něco takového představit v blízké budoucnosti.
Samozřejmě, další cestou je přenášet data pomocí kopírovat a vložit, což poslední novinka v iPhone OS. To sice vyřeší mnoho problému, ale je to zcela manuální práce uživatele, narozdíl od přístupu pomocí URL nebo Apple Eventů na Macovi.
Rychlé přepínání úloh s uloženým stavem
První záchvěv multitaskingu v Mac OS přišel s aplikací Switcher (z roku 1985) Andy Hertzfelda, aplikace která téměř umožnila spouštět dvě aplikace najednou, ačkoliv ve skutečnosti umožnila přepnout aplikace bez vypnutí jedné a zapnutí druhé aplikace. Switcher se pak dostal do MultiFinderu v Systému 5 před tím, než Systém 7 jej učinil standardní částí operačního systému.
U iPhone OS jsme se vrátili zpět. iPhone OS nutí uživatele aby ukončili aplikaci (stisknutím tlačítka Home) před spuštěním další (klepnutím na ikonu v domovské obrazovce). Je to ze dvou hlavních důvodů: konzistence uživatelského rozhraní a eliminace velkých potřeb RAM a CPU nezbytných pro udržení dvou aktivních aplikací najednou. Naštěstí je ukončení a spuštění aplikace rychlé, což je důvod proč se Apple dostal s tímto způsobem tak daleko.
Nicméně je stále frustrující být přinucen jít na domovskou obrazovku (hlavně pro ty, které mají mnoho aplikací). Apple si je toho vědom a proto zavedl zkratky - dvojitým klepnutím na tlačítko Home - které pak umožňuje nastavit první obrazovku, vyhledávací obrazovku, favority, aplikaci pro fotoaparát či iPod aplikaci. A dokonce možnost že systému umožní umístit čtyři ikony aplikací na všechny domovské obrazovky.
Nabízejí se dvě změny, které jsou nezbytné pro rychlé přepínání úloh. Zaprvé, iPhone OS potřebuje rychlejší způsob přepínání mezi uživatelem vybranými nebo posledními spouštěnými aplikacemi. Za druhé, jak iPhone OS tak individuální aplikace potřebují pracovat více aby byly schopny uložit poslední stav, takže při každém spuštění nemusí pokračovat od začátku. Není to nemožné, jsou aplikace které to umí (např. TidBITS News App). Možná by iPhone OS mohl "zmrazit" stav aplikace automaticky, pokud by si to vývojář přál, bez nutnosti provádět práci navíc.
Ani jedno řešení nevyžaduje aby aplikace byly aktivní najednou a tak je možné že se Apple zamyslí nad jejich implementací v budoucích verzích iPhone OS.
Souběžné spouštění
Zde je hlavní kámen úrazu - skutečné souběžné spouštění aplikací. Ale i zde jsou dva možné scénáře: aplikace jako iPod, která potřebuje běžet na pozadí, ale která nepotřebuje žádné (nebo téměř žádné) viditelné místo v rozhraní a budoucí možnost více aplikací běžících bok po boku na iPadu
Pochopitelně první scénář je v iPhone OS možný, protože to iPod aplikace dělá, takže by to mělo být možné i pro jiné aplikace.
A tady se vracíme zpět k tvrzení Apple, že povolení aplikací na pozadí může snížit výkon a výdrž baterie. Pokud máte spuštěnou aplikace souběžně s iPod aplikací, nesníží to životnost baterie příliš, protože jsou využívány všechny dostupné CPU cykly, pokud by hra vyčerpala baterii během hodiny, s iPod aplikací na pozadí by to nebyl příliš velký rozdíl. (Tady původní autor článku zřejmě předpokládá, že by se uživatel choval rozumně a neinstaloval si nadbytečné množství aplikací na pozadí. Obávám se, že je to špatný předpoklad. Vzpomeňme jen na doplňky pro klasický Mac OS, které si hromada lidí instalovala a neuvěřitelně tak zpomalovala svůj počítač.)
Vážnější problém nastává okolo výkonu. Řekněme že jste pasažérem auta a chcete hrát hru, poslouchat iPod na pozadí a používat GPS aplikaci pro sledování cesty a rychlosti a vše najednou společně v době kdy vám Mail aplikace přijímá poštu. V tomto případě musí procesor CPU rozdělit práci mezi všechny aplikace, výkon hry se tak může dostat pod akceptovatelnou úroveň. Řešení jak rozdělit procesorový čas mezi úlohy na pozadí a úlohu na popředí je černou magií ve všech operačních systémech. A to je právě důvod proč Apple zvolil řešení jaké zvolil. Díky němu je práce s aplikací tak rychlá, že vypadá přirozeně. Pokud zavedeme zpoždění a pauzy, iluze spadne.
Díky tomu, jedinou cestou kterou se Apple může vydat je, že nějakým způsobem omezí množství cyklů, které aplikace může provádět na pozadí a aplikace může přijmout pouze příležitostné cykly, zatímco se dějí jiné věci. Není to nedosažitelné, ale vypadá na to na těžký problém, který Apple hned tak nevyřeší.
Ještě náročnějším problémem je omezení paměti. Apple nezveřejnil kolik paměti má každé iPhone OS zařízení a je docela dobře možné, že nemá dost paměti pro více souběžných aplikací. Vyřešení rozložení výkonu CPU mezi aplikace je sice obtížné, ale řešitelné. Spoléhání na virtuální paměť (zejména pokud se používají relativně pomalé flash paměti) místo na fyzickou paměť, bude mít za následek jedině drastický úbytek výkonu.
Druhá možnost souběžného běhu aplikací je více spekulativní, ale mnohem snadněji se na ni odpovídá. Obrazovka iPadu je dostatečně velká aby umožnila zobrazení dvou (nebo čtyřech) aplikací z iPhone najednou. Dokonce i aplikace pro iPad, pokud budou vytvořeny nezávisle na rozlišení, se mohou přepnout do velikosti iPhone a sdílet část obrazovky. Je jedno rozumné předpokládat, že obě by mohly běhat vedle sebe a aktivní ve stejném čase. Pokud je procesor iPadu dostatečně rychlý a je zde dostatek paměti, možná má i dost zdrojů aby to udělal.
Ačkoliv běh více aplikací vedle sebe na iPadu vypadá jako velký stres, bylo by to obrovské plus pro uživatele, kteří chtějí na iPadu dělat práci, na kterou jinak používají maca. Zejména úloh, které vyžadují vizuální přístup k datům ve více aplikacích.
Hlavní výhodou tohoto scénáře je, že druhá aplikace nezabírá celý prostor rozhraní a nemusí být nezbytně nutné aby jedna pokračovala v práci, zatímco druhá je aktivní. Kalendář může být zamrzlý, zatímco uživatel píše email a aktivován pouze pokud jej uživatel přepne do dalšího měsíce. V tom případě zase zamrzne emailová aplikace, dokud na ni uživatel neklepne.
Závěrem
Podívejme se tedy, jak jsme rozpitvali otázku ohledně multitaskingu iPhone. Některé části jsou již k dispozici v aplikacích Apple, některé jsou velmi spekulativní.
- Push Notifikace - Je již k dispozici, a ačkoliv je možné že ji Apple lehce pozmění v budoucnu, dělá co je potřeba pro oznamování externích změn a lidi jej mají obecně rádi. Interní oznamování změn je v současnosti vyhrazeno pouze pro aplikace Apple, ale nevypadá to, že by bylo příliš obtížné jej implementovat i pro jiné aplikace.
- Aktualizace stavu na pozadí - Apple tuto formu multitaskingu rezervoval pouze pro svých pár aplikací, ale opět není důvod aby nebyla otevřena i jiným vývojářům, avšak s několika omezeními kvůli zneužívání, které by mělo vliv na výkon či výdrž baterie.
- Mezi-aplikační komunikace - některé formy komunikace jsou k dispozici již nyní (např. URL, kopírovat a vložit), ale jsou omezené. Apple by měl být schopen vylepšit URL komunikace bez větších problémů, ale asi nelze očekávat Apple Event systém jako u Mac OS X - rozhodně ne velmi brzy.
- Přepínání úloh s uloženým stavem - iPhone OS by potřeboval některé změny v rozhraní aby to bylo možné, ale většina zodpovědnosti leží na aplikacích samotných aby byly schopny uložit svůj stav a obnovit jej tak rychle jak je možné. Během té doby by stálo za to agitovat u Apple pro zkratky pro přepínání aplikací nebo podporu zmražení stavu na úrovni OS.
- Souběžné spouštění, aplikace na pozadí - Ačkoliv to již existuje, minimálně s iPod aplikací a některými dalšími, těžko lze od Apple očekávat, že to bude obecná záležitost. To aby aplikace na popředí odpovídala co nejrychleji uživateli je klíčovou funkcí iPhone a Apple ji nebude chtít nijak ohrozit. Můžete o to žádat jak chcete, ale bude to trvat hodně dlouho (nebo mnohem silnější zařízení) než to uvidíme
- Souběžné spouštění, aplikace vedle sebe - Ačkoliv to dosud není k dispozici, je možné že se to stane nejbližší prioritou Apple v dalších vydáních operačního systému. Stojí za to o to žádat, ale pravděpodobně se to objeví spíše v kontextu přepínání aplikací dokud to nezvládne hardware.
Jako vždy, nejlepší (a jedinou) cestou jak poslat zpětnou vazbu Apple je pomocí stránky Product feedback. iPad zde samozřejmě dosud není, ale tytéž možnosti lze požadovat po iPhone či iPodu touch
