Programování pro iOS - 20. Co nového v iOSu - MujMAC.cz - Apple, Mac OS X, Apple iPod

15. prosince 2010, 00.00 | Už dávno jsme se v redakci domluvili, že jakmile bude iOS 4 veřejně k dispozici pro celou řadu zařízení Apple, podíváme se na jeho novinky z pohledu programátora.

Povídáním o gesture recognizerech jsme se poprvé v této části našeho programátorského seriálu dostali k poměrně zásadnímu API, které je dostupné jen v některé z novějších verzí systému (ačkoli zrovna recognizery jsou k dispozici už od 3.2, a psát aplikace, podporující iOS 3.1, už pomalu, až na konkrétní výjimky, přestává mít smysl).

Za "novinky" budeme pro tentokrát považovat to, co nebylo k dispozici v iOS 3.1 nebo starších. Budeme se také zabývat jen významnými samostatnými bloky služeb; drobná rozšíření – např. to, že od verze 3.2 je k dispozici třída UIBezierPath, že už od této verze lze obsah rámců ukládat do PDF apod. – si popisovat nebudeme.

Gesture recognizery

Jen pro úplnost se zmíníme o gesture recognizerech – těmi jsme se samozřejmě detailně zabývali v minulých dílech našeho seriálu a víme, k čemu slouží; víme také, že jsou novinkou verze 3.2.

Nové služby GUI pro iPad

Vzhledem k tomu, že iOS 3.2 byl první verzí podporující iPad s jeho velkou obrazovkou, není divu, že zde nalezneme několik nových prvků grafického uživatelského rozhraní, zaměřených právě na ni; na iPhone – byť i s novější verzí operačního systému – tyto služby buď nejsou použitelné vůbec, nebo jen velmi omezeně:

• Plovoucí okna, tzv. "pop-overs": ačkoli po technické stránce bylo vždy možné sestavit "okénko", které "se vznáší" nad pozadím obrazovky, nepřekrývá je celé, a obsahuje nějaký samostatný prvek GUI – typickým příkladem zde může být třeba seznam zpráv v aplikaci Mail, je-li iPad držen vertikálně –, bylo to vždy také poměrně náročné. Zatímco na iPhone je podobných případů málo, na iPadu jsou zcela běžné. Není proto divu, že iOS 3.2 přinesl velmi pohodlnou a standardní podporu pro takovéto prvky.

• Řídicí objekt pro dva samostatné objekty, tzv. "split view". Zde musíme malinko předběhnout: v následujících dílech našeho seriálu se budeme podrobně věnovat řídicím objektům rámců (tedy práci s třídou UIViewController a jejími dědici); kromě jiného uvidíme, že z řady dobrých důvodů normálně v podstatě není možné umístit rámce, řízené dvěma různými řídicími objekty, na obrazovku zároveň vedle sebe – vždy musí být právě jeden UIViewController aktuální, a jeho rámce musí překrýt celou obrazovku. Řešením této situace je třída UISplitViewController – ta je speciálně uzpůsobena k tomu, aby v ní bylo možné zobrazit rámce, řízené dvěma různými řídicími objekty, zároveň vedle sebe – a aby vše korektně fungovalo.

Na obě novinky se také podíváme v našem seriálu podrobně, a to hned po popisu řídicích objektů rámců.

Vstupní rámce

Speciální podporu nalezneme v iOSu pro rámce, jež obsahují nějaké specifické vstupní prvky – jejich typickým a archetypálním příkladem samozřejmě je klávesnice, která se automaticky zobrazí kdykoli je objekt, požadující vstup textu, právě aktivní (tj. je právě "prvým responderem").

Zatímco až do verze 3.1 byla klávesnice jediným takovýmto rámcem a navíc jsme do jejího použití systému nemohli moc "mluvit", od verze 3.2 nahoru můžeme definovat vstupní rámce libovolně, a můžeme je také libovolně přiřazovat prvkům GUI.

Za zběžnou zmínku zde možná stojí také to, že klávesnici samotnou můžeme rozšiřovat o vlastní ovladače ("accessory").

Práce s textem

Mnohem bohatší možnosti máme od verze 3.1 výše pro práci s textem: k dispozici jsou služby (bohužel neobjektového) frameworku CoreText; navíc mohou aplikace obsahovat a používat vlastní písma.

Sdílení souborů

Firma Apple kromě jiného pochopila také to, že naprosté vzájemné odstínění všech aplikací a faktická nemožnost spolupráce mezi nimi jsou neudržitelné; od verze 3.2 nahoru je proto k dispozici podpora pro sdílení souborů mezi aplikacemi a také mezi aplikací v zařízení s iOS a stolním počítačem:

• Programátor má k dispozici třídu UIDocumentInteractionController, která umožňuje libovolný soubor předat jiné aplikaci (navíc je možné jej otevřít ve standardním okně náhledu – tuto službu ale od iOS 4 nabízí v lepší podobě nový framework QuickLook –, a v iOS 4.2 dokonce třeba i vytisknout). Ačkoli služby této třídy jsou velmi omezené – např. nelze vůbec předem zjistit, zda bude možné nějak se souborem pracovat: prostě se to musí zkusit, a buď to půjde (takže uživatel uvidí nabídku možností), nebo ne –, oproti situaci ve verzi 3.1 a starších jde o velký pokrok.

• Aplikace může prostřednictvím položky CFBundleDocumentTypes v souboru Info.plist deklarovat typy souborů, s nimiž dokáže pracovat. Kdykoli pak někdo použije služby třídy UIDocumentInteractionController, dostane automaticky právě seznam aplikací, jež takto deklarovaly "zájem" o soubory patřičného typu, a soubor lze předat kterékoli z nich.

• Konečně pak prostým vložením klíče UIFileSharingEnabled do souboru Info.plist zajistíme, že uživatel bude mít z aplikace iTunes přístup do složky Documents naší aplikace, a bude moci do ní ukládat nebo z ní načítat jednotlivé soubory. I tato služba je nepříjemně omezena: už sám fakt, že přístup probíhá prostřednictvím aplikace iTunes a nikoli prostřednictvím Finderu, je naprosto absurdní; kromě toho nelze skoro vůbec pracovat se složkami.

Multitasking

Multitasking jako takový samozřejmě iOS plně podporuje hned od první verze. Bohužel, vždy bylo – a dosud je, i v nejnovější 4.2 – jeho praktické využití v aplikacích, které píše kdokoli jiný než sama firma Apple, podrobeno řadě limitů a omezení.

Až do verze 3 jedním z nejzásadnějších bylo to, že 3rd party aplikace musela v podstatě povinně běžet na popředí: přesně řečeno, jakmile aplikace opustila obrazovku a přesunula se na pozadí, dostala k dispozici jen velmi krátký čas pro případné uložení změn – a pak byla násilně ukončena. Když s ní chtěl uživatel znovu pracovat, musela být znovu spuštěna od začátku.

Dokonce i u Apple ale pochopili, že takhle to opravdu nejde, a v iOS 4 s velkou pompou "zavedli multitasking"; v zásadě to znamená, že

• jakmile aplikace opustí obrazovku a přesune se na pozadí, dostane k dispozici jen velmi krátký čas pro případné uložení změn – a pak je násilně suspendována: neběží tedy a nemůže vůbec nic dělat, ale není ukončena, a její nová aktivace je daleko rychlejší než případné nové spuštění. Přesto ale je rozdíl oproti iOS 3 z praktického hlediska celkem zanedbatelný;

• doba běhu na pozadí může být pomocí specifického API mírně (ale ne moc) prodloužena;

• v některých specifických situacích si suspendovaná aplikace může vyžádat, aby byla na pozadí automaticky "buzena" pro zpracování nějaké jasně definované události – např. zpracování změny polohy u navigačních aplikací, nebo pro možnost přehrávání audia.

Aplikace může ukládat do systému požadavky na takovéto "probuzení" i programově; jde o tzv. lokální notifikace. Je zde ale háček: dříve, než je lokální notifikace předána aplikaci, uživatel to musí explicitně potvrdit pomocí speciálního okénka. Není tedy dost dobře možné např. implementovat plnohodnotný budík apod.

Bloky a GCD

Od verze 4 nahoru je také možné při programování v iOSu využívat bloků – to je natolik významné, že to stojí za samostatný odstaveček. My jsme si bloky popsali v našem seriálu už poměrně dávno.

Také je od této verze nahoru k dispozici technologie Grand Central Dispatch: dosud jsme se na ni podrobně nedívali, ale jde o velmi pohodlné API pro práci se zároveň běžícími úseky kódu ("multithreading").

Píšeme-li už o novinkách, přinášejících pohodlí programátorům, můžeme se zmínit o tom, že od verze iOS 4.2 nahoru je velmi pohodlné ověření, zda je některá z nových tříd či funkcí k dispozici nebo ne – tzv. "weak linking". V podstatě libovolný framework můžeme (přímo v Xcode) označit jako "weak"; v takovém případě jsou všechny jeho symboly k dispozici i ve starších systémech, kde fakticky neexistovaly – ale jejich hodnotou je 0. V praxi to znamená, že pokud pracujeme s některou s nových tříd, nemusíme již zkoušet, zda "NSClassFromString(jméno-třídy)" vrátí třídu nebo ne; můžeme ji použít rovnou, protože libovolná zpráva zaslaná třídě – např. class nebo alloc nebo sharedXxxx – vrátí nil.

Přístup k dalším prvkům systému

Dalšími novinkami verze 4 jsou služby, zpřístupňující aplikacím

• údaje uložené v kalendáři prostřednictvím frameworku EventKit;

• údaje souvisící s telefonováním prostřednictvím frameworku CoreTelephony (ale stále není možné – a mimo jailbreak asi nikdy nebude – hovory programově bez přímé asistence uživatele přijímat, odmítat nebo zahajovat);

• fotografie a videa, uložená v aplikaci Photos, prostřednictvím frameworku AssetsLibrary;

• standardní náhledy prostřednictvím již výše zmíněného frameworku QuickLook;

• údaje z pohybových čidel prostřednictvím frameworku CoreMotion;

• inzerci Apple prostřednictvím frameworku iAd – s trochou zjednodušení v podstatě do aplikace umístíme jen místo pro inzerát; Apple si je vyplní čím chce, a pak nám za to pošle peníze;

• od iOSu 4.1 nahoru nabízí Apple přístup k vlastní herní sociální síti Game Center – jež obsahuje služby pro vzájemné vyhledávání hráčů, sdílení skóre apod. – prostřednictvím služeb knihovny GameKit;

• od verze 4.2 nahoru máme k dispozici přístup k zařízením MIDI prostřednictvím frameworku CoreMIDI.

Nové výkonné knihovny

Vedle nových frameworků pro přístup k různým systémovým prvkům přinesl iOS 4 také řadu nových knihoven, nabízejících řadu často potřebných služeb. Sem patří

• framework Accelerate, který obsahuje optimalisovaný kód pro rozsáhlé numerické výpočty s využitím hardwarové podpory na tom kterém zařízení;

• frameworky CoreVideo, CoreMedia, ImageIO a AVFoundation, jež nabízejí bohaté multimediální služby pro práci se zvukem, grafikou a videem.

Tisk

Možnost tisku je asi hlavní novinkou iOS 4.2 (spolu s možností streamování AirPlay, která nám ani za samostatný odstavec nestojí).

Moment... a jak že je to s tím kreslením čar?

Na konci minulého dílu jsme si řekli, že využití recognizeru UIPanGestureRecognizer pro kreslení přináší jednu drobnou nevýhodu – a slíbili jsme si, že si dnes ukážeme, jak se jí vyhnout.

Problém je v tom, že tento recognizer je určen pro "posunování" obsahu okna nebo objektů v něm; není proto zapotřebí (ba ani žádoucí), aby přesně identifikoval místo, v němž gesto začalo – a odlišil je od místa, v němž bylo interpretováno jako tažení. To druhé je samozřejmě o několik pixelů dál; pokud jste si vyzkoušeli implementaci podle minulého dílu, viděli jste, že když se pokusíte táhnout čáru přesně z nějakého bodu, je tam na začátku vynechané místo – přesně ten krok, který recognizer potřebuje k tomu, aby mohl říci "toto je tažení". Ve chvíli, kdy recognizer pošle akci ve stavu UIGestureRecognizerStateBegan, je už prst o něco dále!

Existuje několik možností, jak problém řešit; asi nejjednodušší zároveň ukáže, že je možné vzájemně kombinovat recognizery s "klasickými" metodami – mohlo by to vypadat asi nějak takto:

...
-(void)touchesBegan:(NSSet*)touches withEvent:(UIEvent*)evt {
    start=[[touches anyObject] locationInView:self.view];
}
-(void)dragged:(UIPanGestureRecognizer*)pgr {
    /*if (pgr.state==UIGestureRecognizerStateBegan)
        start=[pgr locationInView:self.view];
    else*/ if (pgr.state==UIGestureRecognizerStateChanged) {
        current=[pgr locationInView:self.view];
    ... vše při starém ...
}

V této variantě metoda touchesBegan:withEvent: zaznamená přesný začátek tahu – a dále již se o jeho interpretaci stará recognizer.