Programování pro iOS 1. díl - Rozdíly mezi "i" a "Mac" - MujMAC.cz - Apple, Mac OS X, Apple iPod

4. srpna 2010, 00.00 | Začneme od základů. Seznámíme se s nejpodstatnějšími rozdíly mezi vývojovým prostředím Mac OS X a iOS. Příště se pustíme do sestavování jednoduché aplikace ilustrující jednotlivé postupy.

Nedávno jsme spustili v našem seriálu o programování v Kakau samostatnou větev věnovanou aplikacím pro kapesní uzavřená zařízení Apple (iPhone, iPod Touch a iPad) řízená operačním systémem iOS (dříve známým jako OS X nebo iPhone OS). Začali jsme ukázkou kódu, který fungoval stejně dobře na Macu i na iPhone. Dnes se už soustředíme na specifika iOS.

Co je stejné

Sám iOS se od Mac OS X příliš neliší. Je to stejný operační systém, nabízející stejné služby, stejné funkční prvky, procesy, systémové funkce a aplikační knihovny. Prostředí iOSu je ovšem zjednodušené a mnohé z "luxusních" služeb Mac OS X zde nenajdeme. Všechny základní a podstatné prvky zde ale jsou a jsou stejné.

Totéž proto platí i pro základní principy aplikačního programování: v obou architekturách je aplikace objektovou sítí vzájemně spolupracujích objektů, implementovaných v témže jazyce, v Objective C – jeho základy jsme probrali v prvních dílech našeho seriálu. Kromě standardního "programu" mohou být také předem připravené objekty sestavené pomocí aplikace Interface Builder a jako hotová objektová síť načteny z disku při spuštění aplikace – i to je v obou prostředích stejné. Aplikace Interface Builder i aplikace Xcode, v níž projekty spravujeme, jsou zcela stejné. Stejně tak je aplikace ve skutečnosti složkou, obsahující vlastní kód i všechny potřebné pomocné soubory, od objektových sítí NIB až po standardní informační soubor Info.plist, který informuje systém o všech podstatných atributech aplikace.

Jen na okraj. Budoucí verze Xcode aplikaci Interface Builder zruší a sama přebere její funkčnost. Je otázka, zda to je dobře nebo špatně. Až bude Xcode 4 "oficiálně venku" a nejen v předběžných náhledech, samozřejmě se mu budeme věnovat podrobněji.

Vraťme se ale k programování. Vedle základní struktury aplikací, programovacího jazyka a vývojového prostředí je dalším ze základních prvků paleta služeb standardních knihoven. S těmi to už není tak jednoduché:

• knihovna základních systémových služeb Foundation Kit je k dispozici téměř ve stejné podobě v iOSu i v Mac OS X;

• aplikační knihovna je sice navržena na základě obdobných koncepcí, ale v detailech se liší zásadně, a proto se i jinak jmenuje – UIKit v iOS, AppKit v Mac OS X – a podíváme se na ni později;

• další pomocné knihovny jsou kus od kusu různé. Obecně ale v iOSu spíše scházejí nebo jsou jejich služby omezené. Někdy jsou v iOS naopak knihovny, s nimiž se nesetkáme v Mac OS X (např. neobyčejně nevhodně pojmenovaná knihovna GameKit, s níž jsme se už setkali, a která slouží pro komunikaci mezi aplikacemi s použitím Bluetooth), ale to jsou skutečně spíše výjimky.

Co je jinak

Zatímco Mac OS X podporuje v podstatě libovolný programovací jazyk – přímo v něm nalezneme vedle Objective C také velmi omezenou podporu Javy, takřka neomezenou podporu Ruby či Pythonu a není problém doplnit cokoli dalšího – iOS je omezen jen na Objective C (a samozřejmě, jako jeho podmnožinu, na standardní C). Využití jiných vývojových prostředí a jazyků je limitováno technicky a především licenčně. V iOS je k dispozici také JavaScript, ale to je samostatná kapitola s poměrně specifickým a omezeným využitím.

Zatímco Mac OS X je otevřený operační systém, s nímž si můžete dělat cokoli (až na jistá omezení na úrovni licenční ochrany před zneužitím kódu chráněného copyrightem a na dost diskutabilní DRM), s iOS je tomu naopak. V iOS podle licenčního ujednání nesmíte dělat nic jiného, než to málo, co Apple explicitně povolil – a toho opravdu moc není. Navíc je součástí systému i řada technických omezení, jež se snaží to, co nesmíme, podepřít tím, že to skutečně dělat nejde.

Naštěstí existuje jailbreak, který odstraní technická omezení. Stran licenčního omezení vizte např. zde. Přesto však jde o omezení velmi nepříjemné a svazující.

S uzavřeností systému okrajově souvisí dost komplikovaná instalace aplikací na vlastní zařízení. K tomu se ale ještě vrátíme.

Vraťme se k běžnému aplikačnímu programování. Zmínili jsme, že programovací jazyk Objective C a základní služby objektového systému Foundation Kit jsou k dispozici v iOS téměř v téže podobě jako v Mac OS X. Drobná omezení zde tedy jsou a nejpodstatnější z nich jsou tato:

• Objective C pro iOS až do verze 3 včetně nepodporuje bloky (od verze 4 dále již jsou k dispozici, ovšem zpětné kompatibility s iOS 3 se ještě poměrně dlouho nezbavíme);

• Objective C a Foundation pro iOS vůbec nepodporují garbage collector – ve všech verzích musíte používat explicitní správu paměti (v prvých dílech jsme jí říkali "poloautomatický garbage collector");

• Foundation pro iOS vůbec nepodporuje objektové vazby (bindings) – ve všech verzích musíte používat zastaralé a poměrně nepohodlné mechanizmy komunikace mezi modelem a objekty uživatelského rozhraní, založené na datových zdrojích, mechanizmu akce/cíl apod.

Je třeba mít na paměti také to, že iOS nepodporuje virtuální paměť (ačkoli samozřejmě virtualizace adres je k dispozici). Musíte proto s pamětí šetřit daleko víc, než v Mac OS X. Liší se také aplikační knihovny a instalace softwaru na cílové zařízení.

AppKit vs UIKit

Aplikační knihovnu AppKit samozřejmě dávno důvěrně znáte. Knihovna UIKit, jež ji nahrazuje v iOS, je samozřejmě funkčně ekvivalentní a zajišťuje odpovídající služby – interakci aplikace s operačním systémem, zpracování událostí a řízení běhu aplikace, třídy pro implementaci standardních prvků grafického uživatelského rozhraní apod. Je také navržena s týmž – či v některých detailech možná větším – důrazem na čistou a korektní strukturu MVC jako AppKit.

Zároveň jsou zde ale poměrně zásadní rozdíly, dané především tím, že iOS – jakkoli velmi dobře běhá na iPadu, který se zaměřením řadí spíše mezi notebooky – je principiálně určen pro kapesní zařízení, a základní principy práce a ovládání aplikací se proto nutně od plnohodnotného prostředí Mac OS X poněkud liší.

Zásadně odlišné jsou samozřejmě prvky grafického uživatelského rozhraní a do značné míry se liší i základní grafický objektový model. Ten je sice v obou případech založen na spolupráci oken (NSWindow v Mac OS X, UIWindow v iOSu) a rámců (NSView v Mac OS X, UIView v iOS); jejich postavení je ale v iOS poměrně dost odlišné od toho, na něž jsme zvyklí v Mac OS X. Specifická pro iOS je i struktura řídicích objektů – ty zde mají mírně odlišné postavení (připomeňme znovu, že iOS nezná objektové vazby /bindings/), a jejich struktura je mnohem rigidnější a v daleko užší vazbě ke struktuře grafického uživatelského rozhraní.

Zatímco v Mac OS X pro nás byly základními událostmi, řídícími běh aplikace, události generované nabídkou, myší a klávesnicí, v iOS je primárním zdrojem událostí doteková obrazovka. Uvidíme ale, že princip zpracování událostí je týž. Objekty uživatelského rozhraní vyšší úrovně typicky využívají mechanizmy delegace a akce/cíl, na nízké úrovni implementujeme odpovídající služby ve vlastních rámcích (podtřídách standardní třídy UIView), velmi podobně, jako tomu bylo v Mac OS X. Finálně pak aplikační objekt UIApplication sice odpovídá staré známé NSApplication, ovšem jeho konkrétní služby se liší v řadě technických podrobností.

V následujících dílech seriálu si na konkrétním příkladu jednoduché aplikace ukážeme, jak tyto služby v iOS vypadají a jak jich využívat. Budeme je tedy moci dobře srovnat s tím, co již známe z AppKitu.

Instalace a distribuce

Ačkoli již v Mac OS X jsme si zvykli rozlišovat ladicí a finální build, v iOS je mezi nimi rozdíl naprosto zásadní. Sestavujeme zde totiž aplikace pro odlišnou architekturu a pro odlišný stroj, než je ten, na němž vyvíjíme.

Prvým krokem obvykle bývá odladění aplikace v emulátoru. Výhodou je to, že se obejdeme bez konkrétního hardware a je to mnohem rychlejší. Nevýhod je ale také řada.

Pak je načase vyzkoušet aplikaci v cílovém zařízení. Zde opět narážíme na uzavřenost systému. Apple neumožňuje instalovat a spustit v iOS žádný kód, který není digitálně podepsán speciálním certifikátem (ponecháme-li samozřejmě opět stranou jailbreak). Takový certifikát dokáže vytvořit pouze Apple na explicitní vyžádání a jinak není možné jej získat.

Předtím, než vůbec vyzkoušíte první vlastní aplikaci na iPhone, tedy musíte být registrovanými vývojáři. Registrovat se takto může každý, ale není to zdarma. Cena je 99 USD. Na základě této registrace Apple umožní přístup k webovým stránkám, jejichž prostřednictvím je možné potřebné certifikáty vygenerovat a instalovat do Xcode. Pak je teprve možné sestavit aplikaci, která bude pracovat na iPhone či iPadu.

Certifikáty jsou v zásadě tří typů:

• vývojářský certifikát je striktně vázán na konkrétní zařízení – při požadavku na jeho vygenerování zasíláte Apple sériová čísla všech přístrojů, pro něž má platit. Na nich pak aplikace, která byla s jeho pomocí sestavena, poběží a jinde ne. Tento certifikát lze využít při vlastním testování i pro betatestery. Platí pouze čtvrt roku a pak si je nutné požádat jeho prodloužení;

• firemní certifikát umožňuje velké firmě vývoj a distribuci in-house aplikací; v praxi se s touto variantou nejspíš nesetkáte;

• produkční certifikát slouží pro distribuci aplikace prostřednictvím AppStore.

Produkční certifikát přitom neznamená, že aplikaci můžeme "uploadovat na AppStore": namísto toho ji posíláme Apple, která ji prozkoumá, a pak ji buď na AppStore uloží, nebo také ne – problémy s tím, co Apple "pouští" a co ne (a jak dlouho jim to trvá) jsou všeobecně známé.