ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra telekomunikační techniky Vývoj mobilních aplikací pro OS Windows Phone Development of mobile applications for Windows Phone bakalářská práce Studijní program: Komunikace, multimédia a elektronika Studijní obor: Síťové a informační technologie Vedoucí práce: Ing. Stanislav Vítek, Ph.D. Tomáš Kápl Praha 2012
Čestné prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací. Datum: 20. 5. 2012.. podpis bakalanta
Anotace: Tato bakalářská práce se zabývá vývojem mobilních aplikací pro operační systém Windows Phone. Popisuje specifika platformy a obsahuje ukázku vytvořené aplikace. Klíčová slova: Microsoft, mobilní aplikace, Silverlight, Visual C#, vývoj, Windows Phone, XAML Summary: The final project is about developing mobile phone applications for Windows Phone OS. The specific parts of this system are described in this work. A sample application was made as a part of this thesis and it is also attached. Index terms: developing, Microsoft, mobile application, Silverlight, Visual C#, Windows Phone, XAML
Obsah Obsah... 1 Úvod... 2 Historie mobilních operačních systémů společnosti Microsoft... 3 Windows Mobile... 3 Windows Phone... 4 Specifika platformy Windows Phone... 4 Vyvíjíme pro Windows Phone... 8 Od stažení nástrojů až po vytvoření aplikace... 8 Pivot vs. Panorama... 11 Aplikační lišta... 11 Mapová komponenta... 12 Poloha... 13 Dlaždice... 15 Push notifikace... 18 Notifikace typu Toast... 19 Background Agents... 20 Zkušební verze aplikace... 21 Publikování aplikace... 22 Mobilní aplikace využívající webové API... 25 Závěr... 30 Použité zdroje... 31 Strana 1
Úvod Tato práce by měla přiblížit vývoj mobilních aplikací pro operační systém Windows Phone společnosti Microsoft. Pomoci by měla především vývojářům, kteří chtějí zjistit specifika a možnosti vývoje pro tento relativně nový operační systém. V této práci se budu zaměřovat pouze na technologii Silverlight a jazyk C#. V práci je popsán vznik a krátká historie tohoto systému. Následuje kapitola zaměřená na samotný vývoj, kde je podrobně popsáno získání veškerého programového vybavení a jeho základní použití. Zbytek kapitoly je poté věnován popisu komponent a specifik systému. V poslední kapitole jsem poté popsal vznik a možnosti mobilní aplikace využívající webové rozhraní společnosti Google. Strana 2
Historie mobilních operačních systémů společnosti Microsoft Windows Mobile Microsoft hrál na poli chytrých mobilních telefonů (tedy telefonů s operačním systémem) významnou roli už od začátku roku 2000, kdy došlo k představení operačního systému Pocket PC. Původně se jednalo o systém pro zařízení typu PDA, nicméně vývoj pokročil a požadavky uživatelů se zvyšovaly. Ze systému se postupně stal Windows Mobile a dostal se i do mobilních telefonů. Tento operační systém však byl velmi otevřený a vývojáři měli až neskutečné možnosti úprav. Toho využívali především výrobci zařízení a systém si přizpůsobovali svým potřebám a vkusu. To se negativně projevilo na stabilitě a rychlosti systému a zároveň to komplikovalo situaci vývojářům, neboť bylo možné Windows Mobile provozovat téměř na jakémkoliv hardwarovém základu. Situace byla pro Microsoft dlouhodobě neudržitelná a tak došlo k rozhodnutí, že vznikne nová verze systému, označovaná jako Windows Mobile 7, která vyřeší podobné neduhy a zachytí nástup nové konkurence (v tu dobu se jednalo především o Apple ios na zařízení Apple iphone, ale zájem uživatelů mířil i k Androidu společnosti Google). Aby se rozdíl s konkurencí nezdál tak výrazný, tak se zároveň pracovalo na verzi systému Windows Mobile 6.5, která měla být na nových zařízeních a zároveň mělo být možné aktualizovat systém na tuto verzi v hardwarově lépe vybavených telefonech s Windows Mobile 6.1. Tento úmysl Microsoft veřejně prohlásil na konferenci Mobile World Congress ve španělské Barceloně v roce 2009 a ještě v tom samém roce se systém do zařízení dostal. Jak ukazuje graf na obrázku č. 1, tak Microsoft v tu dobu už výrazně ztrácel tržní podíl. Tržní podíl systému Windows Mobile 45,0% 40,0% 35,0% 30,0% 25,0% 20,0% 15,0% 10,0% 5,0% 0,0% 2004 2005 2006 2007 2008 2009 2010 2011 Tržní podíl 12,6% 17% 37% 42% 27% 15% 7% 3% Obrázek č. 1 Tržní podíl systému Windows Mobile. Zdroj: [1][2] Strana 3
Windows Phone Microsoft si sám uvědomil, že ztratil dominantní postavení na trhu, jeho systém nedostačoval konkurenci a další vývoj by pravděpodobně problémy nevyřešil. Sáhl tedy k neobvyklému kroku a vývoj Windows Mobile 7 ukončil a začal vytvářet nový operační systém nazvaný Windows Phone 7. Krok to byl neobvyklý hlavně v tom, že aplikace pro Windows Phone nejsou zpětně kompatibilní s Windows Mobile a naopak. Tím tedy jediná výhoda proti konkurenci (miliony funkčních aplikací) zmizela. Microsoft kromě této výhody ztratil i svou pozici na trhu, neboť dlouhou dobu neměl uživatelům co nabídnout. Windows Phone byl poprvé představen veřejnosti opět na konferenci Mobile World Congress. Konkrétně v roce 2010, tedy přesně rok po oznámení společnosti, že připravuje Windows Mobile 7. Co se týče nového systému, tak opět (stejně jako Windows Mobile) stojí na jádře systému Windows CE (nicméně novější verzi), který je určen pro zařízení postavené na architektuře ARM. Už v dubnu roku 2010 na konferenci MIX10 určené vývojářům, představil softwarový gigant nástroje pro vývojáře. Samotný prodej telefonů začal až 21. října 2010 a to, pro americkou společnost netradičně, pouze v Evropě a Austrálii. V tu dobu dostupných 10 zařízení od 4 výrobců (HTC, Dell, Samsung a LG) se začalo v USA prodávat až 8. listopadu 2010. Zařízení s tímto systémem v tu dobu nabízelo 60 operátorů ve 30 státech světa. Od té doby systém dostal dvě důležité aktualizace. První z nich byla označena jako NoDo a přinesla podporu technologie CDMA (využívaná především v Americe), rychlejší spouštění aplikací a větší propojení s Facebookem na úrovni systému. Tato verze nesoucí označení 7.0.7390 byla také přípravou pro další a velmi důležitou aktualizaci. Tou byla aktualizace systému s označením Mango a ačkoliv tato verze byla označena 7.10.7720, tak došlo k přejmenování systému z Windows Phone 7 na Windows Phone 7.5 (ale ve vývojářských nástrojích je označována jako Windows Phone 7.1). Její představení se uskutečnilo tradičně na Mobile World Congressu, tentokrát v roce 2011, a do všech telefonů se aktualizace dostala v říjnu téhož roku. Zároveň se tím tento operační systém mnohem více přiblížil konkurenci. Aktualizace Mango totiž přinesla nové jádro internetového prohlížeče Internetu Exploreru (konkrétně se jedná o stejné jádro, které využívá Internet Explorer 9 pro OS Windows), propojení se sociální sítí Twitter, upraven byl multitasking a dalších více než 500 novinek. V blízké době po vydání této práce (konec května 2012) by měla být vydána aktualizace nazvaná Tango (často se jí také říká Windows Phone 7.5 Refresh), která by měla přinést podporu pro výkonnostně slabší zařízení s operační pamětí 256 MB, nižším taktem procesoru a menší velikostí úložiště. Také se má objevit ikona signalizující zjišťování polohy a vylepšení klienta pro posílání multimediálních zpráv (MMS). [3] Specifika platformy Windows Phone Microsoft svůj operační systém nabízí k dispozici všem výrobcům, nicméně licence má mnohá omezení. Jedním z nich je hardware, který může výrobce použít. Microsoft tato Strana 4
omezení nazval jako Chassis (anglický výraz pro podvozek, šasi) a minimální požadavky jsou následující: Displej zařízení musí být dotykový, podporovat alespoň 4 dotyky zároveň a mít rozlišení WVGA (480x800 px). Procesor musí být architektury ARM v7 a podporovány jsou pouze čipy Snapdragon QSD8X50, MSM7X30 a MSM8X55. Grafický čip musí podporovat standard DirectX9 Úložiště o velikosti nejméně 4 GB a zároveň alespoň 256 MB operační paměti (RAM) Akcelerometr, senzor osvětlení, senzor přiblížení, A-GPS čip, FM rádio Tlačítka: zpět, Start, hledání, zapnutí / uspání, ovládání hlasitosti a pokud je k dispozici fotoaparát, tak je nutné přidat dvoupolohové tlačítko pro něj. Jedná se o už upravený seznam pro telefony, které se budou vyrábět a prodávat se systémem ve verzi označované Tango (či Windows Phone 7.5 Refresh). Dříve v seznamu byl povinně alespoň 5MPix fotoaparát, WiFi a Bluetooth. Pro snížení cen zařízení již však v seznamu nejsou tyto technologie zastoupeny. A co se technologie Bluetooth týče, tak je její využití vůči konkurenčním mobilním operačním systémům velmi omezené. Microsoft do systému zahrnul jen 5 profilů a mezi nimi není například profil umožňující bezdrátový přenos souborů. Takže tato technologie je v současné době určená maximálně pro přenos zvuku či přenos kontaktů (tuto vlastnost však umožňuje pouze modelová řada Lumia od finského výrobce Nokia). Microsoft si dal také práci s uživatelským rozhraním, protože dobře věděl, že se jedná o klíčový bod, který ho může odlišit od konkurence. Že tato strategie může fungovat ukázala společnost Apple s vydáním mobilního telefonu iphone, který fakticky zapříčinil zánik Windows Mobile. Redmonská společnost proto neponechala nic náhodě a důsledně zkoumala a testovala různé varianty. I proto je výchozím systémovým nastavením černá barva pozadí a světlý text. Microsoft totiž provedl několik měření, při kterých zjistil, že displeje typu OLED (dnes nejpoužívanější typ ve střední a vyšší třídě mobilních zařízení) mají spotřebu menší o více než polovinu oproti displejům typu LCD. Tato vlastnost však platí pouze ve chvíli, kdy se na displeji vyskytuje především černá barva. Pokud se ale zobrazí barva bílá, tak má displej typu OLED trojnásobnou spotřebu oproti typu LCD. [4] I proto Microsoft vytvořil rozhraní nazývané METRO. Toto prostředí je graficky velmi strohé a sází spíše na typografii, jednoduché tvary a přechodové animace. Cílem bylo vytvořit systém graficky ucelený, jednoduchý a dát vývojářům možnost využít stejné možnosti při návrhu vlastních aplikací. A to i začínajícím programátorům, kteří si nemohou dovolit drahého grafika, který by vzhled aplikace vytvořil. Například hlavní systémová obrazovka je složena z dlaždic (Live Tile v originále, podle českého překladu živé okénko, ale tento termín v této práci nebudu používat), které mají čtvercový tvar a kromě dvou systémových dlaždic (pro kalendář a fotografie) nelze vytvořit jinou. O tom, jak vývojář Strana 5
dokáže s čtvercem pracovat je jen na něm. Může do něj vypsat text, zobrazit pouze ikonu či udělat kombinaci více prvků. Velký důraz dala společnost také na propojení systému se sociálními sítěmi. Uživatel tak nemusí nic instalovat a má funkční propojení s Facebookem, Twitterem, LinkedIn či Windows Live. Propojení je na úrovni systému a tak dochází k automatickému provázání kontaktů ze všech těchto sítí či sjednocení notifikací. Bezproblémové je i sdílení fotografií na daná místa či integrace Facebook chatu a Windows Live Messengeru do zpráv. Je tedy možné posílat zprávy zdarma přes internet na daných sítích, pokud je kontakt na druhé straně online. Pokud není, tak se stačí přepnout na SMS/MMS a pokračovat v rámci jedné konverzace. Vše bylo navrženo především pro pohodlí uživatele. Internetový prohlížeč je od aktualizace Mango změněn. Je poháněn stejným jádrem, jako prohlížeč Internet Explorer 9 na klasických počítačích. To by mělo zaručit shodné vykreslování obsahu. E-mailový klient je v základu připraven na napojení na nejoblíbenější služby jako je například Hotmail společnosti Microsoft, Gmail od společnosti Google či Yahoo! Mail od stejnojmenné společnosti. V některých telefonech určených pro český trh nalezneme i předpřipravené profily pro mailové řešení portálů Seznam.cz či Centrum.cz. Nechybí ani podpora řešení Exchange a Office 365 společnosti Microsoft. Každé zařízení má hardwarové tlačítko pro vyhledávání. To je pevně svázáno s vyhledávačem Bing a ani uživatel, ani vývojář, to nemůže změnit. Co nezmůže vývojář, zmůže výrobce zařízení a tak i zde došlo ve světě k několika výjimkám jednu z nich dostala i Česká republika. Na telefonech Nokia Lumia je možné změnit Bing za vyhledávač Seznam. V zařízeních s operačním systémem Windows Phone není možné přistupovat k souborům. Pro vývojáře je jediný přístup k multimediálnímu obsahu (hudba, videa a obrázky včetně fotografií) umožněn pouze ve formě knihoven, kdy pracujete s kolekcí dat, nikoliv přímo se souborem. Obsah knihoven je možno synchronizovat přes aplikaci Zune (k dispozici je pouze pro operační systém Windows a Mac OS stáhnout lze na www.zune.net), případně sdílet přes e-mail či cloudové úložiště (typu SkyDrive či Dropbox). Ze zvukových standardů jsou podporovány WAV, MP3, WMA, AMR, AAC/MP4/M4A/M4B a 3GP/3G2, u videa zase WMV, AVI, MP4/M4V, 3GP/3G2 a MOV (QuickTime). Pokud si uživatel chce do telefonu nahrát z počítače multimediální obsah v jiném formátu, tak aplikace Zune v počítači zajistí konverzi do podporovaného formátu i rozlišení. Pokud by si uživatel chtěl změnit například vyzváněcí melodii, tak hudební soubor musí být kratší než 40 sekund a velikost nesmí přesáhnout 1MB. Systém je rozdělen na několik takzvaných Hubů. Vlastní hub mají kontakty, obrázky, hudba+videa a také hry. Hry mohou být napojeny na herní systém Xbox Live známý z herní konzole společnosti Microsoft nazvané Xbox 360. Xbox Live ve hrách přináší možnost porovnávání s přáteli a sdílení pokroku ve hrách, v ojedinělých případech je možno tuto službu využít i pro hru více hráčů přes internet. Strana 6
Posledním hubem je Office hub. Jedná se o mobilní verzi kancelářského balíku Microsoft Office. Konkrétně jsou v systému zastoupeny aplikace Word, Excel, PowerPoint a OneNote. Tyto aplikace mohou využívat služeb Sharepoint serveru či cloudového řešení SkyDrive. Uživatel tak může mít aktuální verze dokumentů na všech svých zařízeních připojených do online úložiště, případně využít webového rozhraní k přístupu odkudkoliv. Pokud by uživatel chtěl využívat funkcionalitu, kterou systém nenabízí, může stáhnout další aplikace. To je možné pouze přes vestavěnou aplikaci Marketplace. V Marketplace je možné aplikace vyhledávat, hodnotit a stahovat. V případě placených aplikací je možné aplikaci rovnou zakoupit případně, pokud to vývojář umožnil, tak stáhnout její zkušební verzi. Omezení zkušební verze je plně v kompetencích vývojáře, ale často je v omezení časového rázu (doba, po kterou aplikace bude plně funkční), případně je do aplikace přidána reklama. Jak bylo již dříve popsáno, systém je možno aktualizovat. Na dostupnou aktualizaci může upozornit přímo zařízení, ale samotná aktualizace je možná jen při zařízení spojeném s počítačem přes nainstalovanou aplikaci Zune. Před samotným nahráním nové verze systému do telefonu dojde k záloze všech dat v telefonu do počítače a tuto zálohu je možné později kompletně obnovit. Lze se tak vrátit ke starší verzi systému v případě, že se v nové objeví závažný problém. Strana 7
Vyvíjíme pro Windows Phone Od stažení nástrojů až po vytvoření aplikace Microsoft má osvědčené technologie pro vývoj a to se promítlo i při návrhu mobilního operačního systému Windows Phone. Vývojář má k dispozici stejné vývojové prostředí, které používá při vývoji aplikací pro počítače s OS Windows, může využívat stejné technologie a dokonce i stejné jazyky. Takže co je pro vývoj aplikací potřeba? Základním předpokladem je prostředí, ve kterém budeme aplikace vytvářet. Pro tento účel je k dispozici pouze Visual Studio 2010. Vzhledem k tomu, že tato aplikace je k dispozici pouze v rodině operačních systémů Windows, tak není možné vytvářet aplikace pro Windows Phone na konkurenčních platformách. Vůbec tím nejdůležitějším pro vývoj ale je Windows Phone SDK. To do Visual Studia přidává rozšíření umožňující vývoj a testování mobilních aplikací. Navíc, pokud Visual Studio nemáte nainstalované, tak vám SDK nainstaluje bezplatnou edici Visual Studio 2010 Express for Windows Phone, kterou můžete využít i pro vytváření aplikací, za které vám uživatelé budou platit. Abychom mohli toho rozšíření nainstalovat, tak náš hardware musí splňovat následující parametry: Operační systém našeho počítače musí být Windows Vista se Service Packem 2 nebo Windows 7 (podporovány jsou všechny edice kromě edice Starter a to pro architektury x86 i x64) Mít alespoň 3 GB RAM (operační paměti) Na pevném disku počítače musejí být nejméně 4 GB volného místa Emulátor zařízení Windows Phone vyžaduje grafické karty s podporou Microsoft DirectX 10 nebo grafickou kartu s podporou DirectX 11 a ovladačem Windows Display Driver Model (WDDM) 1.1, Microsoft Direct3D verze 10 DDI a vyšší SDK také není možné používat v rámci virtuálního stroje, na Windows XP (a starších edicích tohoto operačního systému) či na operačním systému Windows Server. [5] Když už známe omezení, můžeme začít s procesem, kterým si musí projít každý začínající vývojář. Jako první je nutné se zaregistrovat na webu AppHub, který se nachází na adrese http://create.msdn.com. Pokud uživatel má Windows Live ID z dřívější doby, registrace není nutná a může použít svůj původní účet. Pro instalaci samotného SDK není registrace potřeba, ale hodí se nám později, až budeme chtít naše aplikace odeslat do Marketplace a dostat je tak k uživatelům či otestovat na reálném zařízení. Registrace vývojářského účtu však něco stojí. Aktuální cena (v době psaní tohoto textu) za možnost publikování aplikací činí 99 amerických dolarů za rok. Studenti splňující podmínky programu DreamSpark však mají možnost publikovat aplikace bezplatně a to se týká i placených aplikací. Jejich účet je také omezen dobou jednoho roku pokud poté student neprokáže, že studuje střední nebo vysokou školu, bude si muset účet zaplatit za poplatek. Placené účty jsou dvojího Strana 8
typu osobní a podnikové. Název přímo napovídá pro koho je který určen a cena poplatku je u obou stejná. Na úvodní straně AppHubu také najdeme odkaz pro stažení Windows Phone SDK. V době psaní této práce je poslední verze SDK nazvaná Windows Phone SDK 7.1.1 Update a jak poslední slovo značí, jedná se jen o aktualizaci. Nejprve tak musíme stáhnout a nainstalovat Windows Phone SDK 7.1 (ke stažení je k na adrese http://go.microsoft.com/fwlink/?linkid=226403) a až poté Windows Phone SDK 7.1.1 Update (to lze stáhnout na http://go.microsoft.com/fwlink/?linkid=242824). Po instalaci se nám v nabídce Start objeví kromě Visual Studia i další nástroje. Například Microsoft Blend 4, ve kterém je možné vytvářet vzhled naší aplikaci. Neméně důležité nástroje nalezneme v nabídce Start ve složce Windows Phone SDK 7.1. Jsou zde tři zástupci aplikací. Pomocí Windows Phone Developer Registration můžeme odemknout naše zařízení pro testování aplikací, které vytvoříme. Pro tento účel je však již nutné mít vývojářský účet na AppHubu. Dále se zde nachází utilita Application Deployment, která nám umožní do telefonu odeslat a nainstalovat naší aplikaci jak již bylo dříve popsáno, v telefonu není možné pracovat se soubory a tak je toto jediná cesta (kromě instalace z Marketplace), jak do telefonu dostat naši aplikaci. Poslední aplikací je Windows Phone Emulator. Jak už z názvu plyne, jedná se o emulátor zařízení a i v něm můžeme testovat naše aplikace pokud tak chceme učinit, musíme opět použít utilitu nazvanou Application Deployment. Tím bychom měli nainstalováno vše potřebné pro vývoj. Je proto čas si trochu popsat v čem můžeme vyvíjet. Microsoft nám dává k dispozici dvě technologie technologii Silverlight a technologii XNA. XNA je určeno hlavně pro vytváření her nebo aplikací s 3D grafikou. Technologie Silverlight je vhodná pro jednoduché aplikace a pouze touto technologií se budeme zabývat v rámci této práce. U výběru programovacích jazyků nám dal Microsoft také volbu. Můžeme využít buď C# a nebo jazyk VB.NET. Oba mají naprosto stejné možnosti a žádný jazyk není v rámci vývoje nijak omezován, přesto většina vývojářů používá jazyk C#. [6] I z tohoto důvodu budou veškeré ukázky kódu napsány pouze v tomto jazyce. Už víme, co potřebujeme k vytváření aplikací a tak si můžeme rovnou jednu aplikaci zkusit vytvořit. Spustíme tedy Visual Studio, v nabídce File vybereme možnost New a klikneme na položku Project (případně využijeme klávesovou zkratku Ctrl+Shift+N). Z okna, které se nám objeví na obrazovce, nejprve vybereme v levém sloupci jazyk, který budeme používat. V našem případě to bude Visual C#. Jelikož chceme využít technologii Silverlight, tak musíme vybrat položku Silverlight for Windows Phone. Následně si musíme vybrat typ zobrazení dat, která bude aplikace využívat. Jednotlivé možnosti budou popsány dále, ale pro tuto ukázku si zvolíme Windows Phone Application. Ve spodní části okna můžeme zvolit název aplikace a projektu, případně umístění na pevném disku počítače. Po potvrzení (tlačítkem OK) bude vytvořen nový projekt a před námi se zobrazí pracovní Strana 9
prostředí Visual Studia. To obsahuje v levé polovině obrazovky zařízení podobné stroji s Windows Phone a v pravé půlce vidíme kód, který jazyku C# není vůbec podobný. Tento kód vypadá podobně jako XML, nicméně se nazývá XAML (vyslovováno ZAML) a slouží k popisu vzhledu aplikace. Syntaxe je také velmi podobná prvkům HTML a pokud nechcete tyto komponenty psát ručně, můžete je do aplikace přidávat z (běžně) vlevo umístěného toolboxu. Vlastnosti poté můžete nastavovat přes okno Properties (česky vlastnosti). Pokud se vám toto okno nezobrazuje, tak si ho zapněte v nabídce View, kde je nazvané jako Properties Window (případně stejně dobře poslouží kombinace klávesových zkratek Ctrl+W, P). Naším úkolem nyní není napsat nějakou oslnivou aplikaci, ale ukázat základní používání Visual Studia. Šablona, kterou jsme použili pro tento projekt, obsahuje několik textů a není to jen prázdná stránka, takže si můžeme projekt zkompilovat a spustit a uvidíme nějaký výsledek, nikoliv jen černou obrazovku. Pokud máte k dispozici odemčené zařízení s operačním systémem Windows Phone, připojte jej k počítači a spusťte synchronizační aplikaci Zune (v základním nastavení se spouští sama po připojení zařízení k počítači). Obrázek č. 2 Výběr zařízení pro testování Ve Visual Studiu si zvolte možnost Windows Phone Device (viz obrázek č. 2) a klikněte na zelenou šipku vedle (či stiskněte klávesu F5). U svého zařízení zkontrolujte, že nemá zamčenou obrazovku (pokud vidíte úvodní obrazovku s dlaždicemi, tak je vše v pořádku) a během chvíle by se vám měla v telefonu zobrazit aplikace, kterou jste viděli na obrazovce počítače. Stiskem klávesy zpět můžete aplikaci ukončit. Pokud zařízení se systémem Windows Phone k dispozici nemáte, nezoufejte. Právě pro vás je v rámci Windows Phone SDK obsažen emulátor. Z nabídky ve Visual Studiu vyberte možnost Windows Phone Emulator (od Windows Phone SDK 7.1.1 Update jsou k dispozici dvě možnosti Windows Phone Emulator 512 MB a Windows Phone Emulator 256 MB; v tomto případě můžete klidně zvolit Windows Phone Emulator 512 MB) a pokračujte kliknutím na zelenou šipku. Dojde ke spuštění emulátoru (pouze pokud nebyl spuštěn dříve), načtení obrazu operačního systému a následnému zavedení vaší aplikace. Takto je možné vaše aplikace testovat i na reálných zařízeních rozdílných hardwarových parametrů. Zároveň si ve Visual Studiu můžete přidat break pointy (místa, kde se vykonávání kódu přeruší) a sledovat tak, co se uvnitř vaší aplikace děje a jakou hodnotu Strana 10
mají proměnné. Pokud by kdekoliv v aplikaci došlo k chybě, běh aplikace se přeruší a Visual Studio zobrazí příslušnou chybu s informací o výjimce (exception), kterou byla způsobena. Vývojář poté může aplikaci z Visual Studia ukončit a chybu napravit. Pivot vs. Panorama V předchozí části jsme si vytvořili aplikaci, která měla jen jednu obrazovku. Pokud však máme více dat, která chceme zobrazit, je dobré se zamyslet nad tím, jak je budeme vizualizovat. Máme k dispozici vytvořené dvě šablony, které se však navzájem moc neliší. Jedna se nazývá Pivot a ta druhá Panorama. Jaké jsou však výhody a nevýhody těchto šablon? Obě využívají systém záložek. U typu Pivot jsou záložky zobrazeny vedle sebe, takže (pokud není název aktuální záložky příliš dlouhý) můžeme vidět následující položky. Pro přechod mezi záložkami můžeme přímo kliknout na samotný text záložky nebo tažením prstu po obrazovce přejít na následující či předchozí (podle směru pohybu) položku. U šablony typu Panorama vidíme pouze aktuální položku a část následující je zobrazena na pravém okraji obrazovky. Ne vždy tam ale musí být vidět, protože jedna záložka typu Panorama může být širší než je velikost displeje. Můžeme tak naše data nechat plynout mimo displej. Využití je vhodné například ve chvíli, kdy chceme zobrazit více položek vedle sebe (může se jednat třeba o seznam obrázků - fotogalerie) a jejich zobrazení ve svislém seznamu by nebylo vhodné. Zjednodušeně lze tedy říci, že Pivot je vhodný pro vertikální použití, zatímco Panorama může vytvořit efekt větší obrazovky a hodí se tak pro horizontální zobrazení dat. Aplikační lišta Aplikační lišta (neboli ApplicationBar) je místo, kam bychom měli soustředit funkční prvky a tlačítka. Tato lišta se v aplikaci zobrazí vždy v dolní části obrazovky při zobrazení na výšku, případně u pravé hrany displeje, pokud je orientace obrazovky na šířku. Aplikační lišta může obsahovat pouze tlačítka a to dvou typů. Jednak se může jednat o textový odkaz nebo může být tlačítko interpretováno ikonou a krátkým popisem. Podle toho se můžeme rozhodnout, jaká část lišty bude viditelná. Může být zobrazen jen úzký proužek (reprezentovaný třemi tečkami u pravého okraje obrazovky) nebo se mohou zobrazovat ikony bez popisků. Popisky a další tlačítka se zobrazí po kliknutí na tři tečky (případně je možné lištu za tyto tečky vytáhnout do obrazovky ). Lištu je nutno přidat v XAML kódu a každý soubor MainPage.xaml vygenerovaný Visual Studiem (kromě šablony typu Panorama) již potřebný kód obsahuje. Stačí odkomentovat následující kus kódu na konci souboru a aplikační lišta se zobrazí. <phone:phoneapplicationpage.applicationbar> <shell:applicationbar IsVisible="True" IsMenuEnabled="True"> <shell:applicationbariconbutton IconUri="/Images/appbar_button1.png" Text="Button 1"/> Strana 11
<shell:applicationbariconbutton IconUri="/Images/appbar_button2.png" Text="Button 2"/> <shell:applicationbar.menuitems> <shell:applicationbarmenuitem Text="MenuItem 1"/> <shell:applicationbarmenuitem Text="MenuItem 2"/> </shell:applicationbar.menuitems> </shell:applicationbar> </phone:phoneapplicationpage.applicationbar> Tlačítkům poté stačí přidat event handlery a ty obsloužit v kódu a aplikační lišta bude plně funkční. Pokud používáme ikony, nesmíme zapomenout grafiku přidat do projektu a nastavit, aby se soubory při kompilaci přibalily do výsledného balíku. Mapová komponenta Pokud se spokojíme s mapovými podklady Bing Maps od společnosti Microsoft, tak použití mapové komponenty v naší aplikaci je velmi jednoduché. Stačí přidat v XAML kódu jen jeden řádek do naší aplikace. <my:map /> Po vložení tohoto řádku se nám vykreslí mapa. Nicméně by bylo vhodné přidat nějaké parametry a název. Abychom neporušovali podmínky použití Bing mapy, tak musíme provést registraci naší aplikace na webu Bing Maps Account Center (http://go.microsoft.com/fwlink/?linkid=198151), kde získáme licenční kód pro použití této mapy. Tím odstraníme vodoznak, který se bez tohoto kódu běžně zobrazuje. V parametrech mapové komponenty můžeme nastavit spoustu užitečných vlastností. Jmenujme například viditelnost ovládacích prvků pro přiblížení a oddálení, typ mapového podkladu (mapa, satelitní pohled, ), základní přiblížení či nastavení středu mapy. Naše mapová komponenta tedy může vypadat podobně jako zde: <my:map Height="646" HorizontalAlignment="Left" Margin="0,-22,0,0" Name="mapa" VerticalAlignment="Top" Width="468" ZoomBarVisibility="Visible" CredentialsProvider="NasLicencniKodZWebuMicrosoftu" Mode="Road" Center="50.073702,14.43711" ZoomLevel="5" /> V tomto kódu máme mapovou komponentu pojmenovanou mapa s rozměry 468x646. Střed mapy se nachází na souřadnicích 50.073702, 14.43711 a mapa je přiblížena na pátou úroveň. Zároveň je zvoleno, aby mapovým podkladem byla obecná mapa. Kromě zarovnání a určení pozice komponenty máme rovněž nastavenou viditelnost prvků pro ovládání přiblížení a oddálení. Strana 12
Poloha Pokud chceme zjistit aktuální umístění zařízení (souřadnice), tak musíme použít službu zvanou Location. Nejprve tedy musíme použít direktivu using: using System.Device.Location; Poté je zapotřebí vytvořit objekt, kterým budeme do Location služby přistupovat. Objekt je typu GeoCoordinateWatcher a v našem případě mu dáme jméno watcher. Taktéž je nutné upravit záhlaví třídy, aby zůstala v paměti po celou dobu, co je daná stránka aplikace zobrazena. public partial class MainPage : PhoneApplicationPage { GeoCoordinateWatcher watcher; Nyní máme připraveno téměř vše podstatné, abychom mohli začít s čtením polohy. To se provádí metodou Start volanou na objekt typu GeoCoordinateWatcher. Tuto metodu je nutno volat až po načtení stránky. Než však tuto metodu zavoláme, bylo by vhodné udělat prvotní nastavení. V našem případě ho uděláme v event handleru patřícímu tlačítku pro spuštění našeho watchera. // Event handler pro klik na tlačítko pro zahájení čtení polohy private void startlocationbutton_click(object sender, RoutedEventArgs e) { // Proměnná watcher byla již dříve deklarovaná jako typ GeoCoordinateWatcher. if (watcher == null) { watcher = new GeoCoordinateWatcher(GeoPositionAccuracy.High); // chceme vysokou přesnost watcher.movementthreshold = 20; // pomocí MovementThreshold můžeme omezit nepřesnosti a malé změny polohy Předchozím kódem jsme nastavili, že chceme vysokou přesnost informace (bude použita GPS namísto kombinace dat z BTS, WiFi či IP adresy) a zároveň se budou ignorovat změny pozice menší než je nastavená hodnota MovementThreshold. Nyní je ještě potřeba připravit event handlery, které se budou volat při změně stavu objektu (například se dostaneme do místa, kde není signál GPS) a při změně polohy zařízení (poloha zařízení se změní o hodnotu větší než je hodnota MovementThreshold). To zajistí následující kód. watcher.statuschanged += new EventHandler<GeoPositionStatusChangedEventArgs>(watcher_StatusChanged); watcher.positionchanged += new EventHandler<GeoPositionChangedEventArgs<GeoCoordinate>>(watcher_Positio nchanged); } Po tomto nastavení všeho potřebného můžeme zavolat metodu Start a získávat souřadnice o poloze zařízení. Tato data jsou předávána asynchronně. Strana 13
watcher.start(); } // Zde ukončíme event handler tlačítka pro zahájení čtení polohy Nesmíme však zapomenout vytvořit metody event handlerů, které obslouží změnu stavu objektu nebo polohy. Jako první vytvoříme event handler pro událost StatusChanged. Pomocí příkazu switch pokryjeme všechny možné výsledky a na jejich základě budeme reagovat. // Event handler pro událost GeoCoordinateWatcher.StatusChanged. void watcher_statuschanged(object sender, GeoPositionStatusChangedEventArgs e) { switch (e.status) { case GeoPositionStatus.Disabled: // Služba Location je vypnuta či není podporována. // Můžeme zkontrolovat, zda uživatel zakázal zjišťování polohy. if (watcher.permission == GeoPositionPermission.Denied) { // Uživatel zakázal zjišťování polohy zařízení. statustextblock.text = "Zjištění polohy je zakázáno."; } else { statustextblock.text = "Zařízení nepodporuje zjišťování polohy."; } break; case GeoPositionStatus.Initializing: // Dochází ke spuštění zjišťování polohy. // Proto je vhodné deaktivovat tlačítko. startlocationbutton.isenabled = false; break; case GeoPositionStatus.NoData: // Ačkoliv Location služba běží, tak nedostáváme data. // Měli bychom informovat uživatele. statustextblock.text = "Data o poloze nejsou k dispozici."; stoplocationbutton.isenabled = true; break; case GeoPositionStatus.Ready: // Location služba pracuje a získáváme data. // Zobrazíme současnou polohu a aktivujeme tlačítko pro ukončení čtení dat. statustextblock.text = "Data o poloze jsou k dispozici."; stoplocationbutton.isenabled = true; break; } } Strana 14
Nyní bychom měli vytvořit i event handler pro změnu polohy, neboť ten patří k tomu nejdůležitějšímu, pokud chceme zjistit polohu zařízení. Souřadnice se nacházejí ve vlastnosti Position objektu GeoPositionChangedEventArgs<T>. Jak takový event handler může vypadat naznačuje následující kód, kde jsou hodnoty vypisovány do (již vytvořených) TextBlocků. void watcher_positionchanged(object sender, GeoPositionChangedEventArgs<GeoCoordinate> e) { latitudetextblock.text = e.position.location.latitude.tostring("0.000"); longitudetextblock.text = e.position.location.longitude.tostring("0.000"); } Neměli bychom zapomenout přestat číst informace o poloze ve chvíli, kdy už nebudou potřeba. Výrazně tím můžeme prodloužit dobu výdrže zařízení při napájení z akumulátoru. V následující ukázce je metoda Stop volána v event handleru tlačítka. private void stoplocationbutton_click(object sender, RoutedEventArgs e) { watcher.stop(); } Dlaždice Dlaždice (Tile) je zástupcem aplikace na pohotovostní obrazovce. Tyto dlaždice mohou být dvou typů Application Tile a Secondary Tile. Rozdíly si popíšeme v bodech: Application Tile (neboli dlaždice aplikace): Je zástupcem samotné aplikace. Pokud uživatel chce mít tuto dlaždici na úvodní obrazovce, musí dlouze kliknout na název aplikace v seznamu nainstalovaných aplikací a poté zvolit možnost připnout na úvodní obrazovku. Dlaždice aplikace poté bude přidána na poslední místo na pohotovostní obrazovce. Dlaždici nelze odstranit. Může být maximálně vyjmuta z úvodní (pohotovostní) obrazovky. Pokud se informace určené ke zobrazení na dlaždici mění v rámci aplikace, tak se tak děje i v době, kdy dlaždice není připnuta na hlavní obrazovce, aby bylo možné v případě připnutí zobrazit aktuální data. Data zobrazovaná na dlaždici lze aktualizovat a upravovat pomocí třídy ShellTile, push notifikacemi nebo pomocí třídy ShellTileSchedule. Secondary Tiles (sekundární dlaždice) Jedná se o dlaždice, které mohou být vytvořeny z běžící aplikace. Aplikace zavolá metodu Create s parametry Uri a ShellTileData a na úvodní obrazovce se objeví nová Strana 15
dlaždice. Protože však dojde k přepnutí na tuto obrazovku, tak není možné vytvářet více než jednu dlaždici zároveň. Postupně je však možno přidat libovolné množství dlaždic a to i z jedné aplikace. Výhodou těchto dlaždic je, že mohou vést na určitou obrazovku aplikace. Pokud tedy budeme psát aplikaci nějakého zpravodajského portálu, můžeme vytvořit sekundární dlaždici každé kategorii. Pokud uživatel bude mít připnutou dlaždici se sportovní tématikou, tak se dostane po kliknutí na dlaždici rovnou do části naší aplikace, která se sportu věnuje. Tato dlaždice může být odstraněna třemi způsoby. Uživatel si může dlaždici odstranit sám, případně odinstaluje naší aplikaci. Poslední možností je zavolání metody Delete, která se postará o odstranění dlaždice. O aktualizaci údajů zobrazených na dlaždici se opět starají třídy ShellTile a ShellTileSchedule či push notifikace. Vlastnosti dlaždic Od vydání systémové aktualizace s kódovým označením Mango mají dlaždice dvě strany přední (front) a zadní (back). Pokud máme nějaký obsah přiřazen zadní dlaždici, dochází automaticky k překlápění z přední na zadní a poté zpět. Pokud však zadní strana neobsahuje data, k překlopení nedojde a naše aplikace bude prezentována jen přední stranou dlaždice. Stejně tak, pokud budeme data aktualizovat (například přes třídu ShellTile či push notifikací) a nedojde ke změně všech proměnných, tak zbývající proměnné si ponechají předchozí hodnotu. Co se týče samotných vlastností, které se mohou zobrazovat, máme jich k dispozici hned 6. Za pomoci těchto šesti můžeme definovat vzhled dlaždice a zobrazená data na ní. Obrázky č. 3 a 4 zobrazují umístění prvků a jejich popis. Obrázek č. 3 Přední strana dlaždice. Zdroj: [8] Title je textový řetězec s názvem aplikace. Jedná se o jeden řádek textu a neměl by být další, než je šířka dlaždice. Vedle sebe se vejde zhruba 15 znaků. Pokud by text byl delší, dojde k jeho oříznutí. BackgroundImage je obrázek, který se zobrazuje na přední straně dlaždice. Je doporučeno, aby tento obrázek byl použit u všech aplikací. Strana 16
Count je celočíselná hodnota od 1 do 99. Pokud by hodnota byla 0, kruh s hodnotou se nevykreslí. Obrázek č. 4 Zadní strana dlaždice. Zdroj: [8] BackTitle textový řetězec zobrazený na zadní straně dlaždice. Platí pro něj stejná omezení jako pro Title. BackBackgroundImage je obrázek, který se zobrazuje na zadní straně. BackContent je textový řetězec, který bude vykreslován na zadní straně dlaždice. Může mít více řádků. Na dlaždici se dá zobrazit přibližně 40 znaků. Pokud bude text delší (resp. se nevejde na dlaždici), dojde k jeho oříznutí. BackgroundImage a BackBackgroundImage mají jistá pravidla a omezení. Například pokud vytváříme sekundární dlaždici, tak oba obrázky musejí být načteny z lokálního úložiště, tedy z paměti telefonu. Pokud budeme chtít obrázek později změnit a načíst například obrázek z internetu, tak po splnění podmínek je to možné. Seznam veškerých podmínek a omezení je následující [8]: Obrázky mohou být ve formátu.jpg nebo.png. Pokud bude obrázek ve formátu.png a bude obsahovat průhlednost, průhledná místa budou vyplněna barvou tématu, které uživatel používá. Rozměry dlaždice jsou 173x173 pixely. Pokud má náš obrázek jiné rozměry, bude na tyto rozměry přizpůsoben. Pokud budeme načítat obrázky z webového serveru, nesmí se jednat o protokol https. Obrázky z cizího zdroje jsou také omezeny velikostí (80KB) a časem stahování (30 sekund). Pokud dojde k překročení, nedojde ke stažení obrázku. Pokud nebude z nějakého důvodu možno aktualizovat BackgroundImage nebo BackBackgroundImage, nedojde k aktualizaci ani dalších údajů na dlaždici (v případě, že aktualizujeme více věcí najednou). Strana 17
Push notifikace Push notifikace je způsob, jak může vývojář aktualizovat data ve své aplikaci (či informovat uživatele). Tato notifikace využívá internetové připojení a o doručování notifikací do zařízení se stará Microsoft Push Notification Service. Na obrázku číslo 5 (s anglickými popisky) je znázorněno, jak probíhá komunikace mezi naší aplikací, Microsoft Push Notification Service a službou běžící v rámci internetu. Obrázek č. 5 Princip notifikací. Zdroj: [9] Po spuštění naší aplikace dojde ke kontrole Push client service (služby běžící v zařízení na obrázku označeno číslem 1). Tato služba komunikuje s Microsoft Push Notification Service (dále již jen jako MPNS, situace označena číslem 2) a výsledkem je předání unikátní URI aplikaci (3). Na tuto adresu poté zasíláme samotné notifikace, takže je nutné URI předat naší webové službě (4). Adresa vede na MPNS a stará se tak o samotné doručení. V případě nutnosti zaslání notifikace tak musíme kontaktovat server MPNS (5), který se postará o doručení zprávy do zařízení (6). Podle formátu zprávy rozlišujeme tři typy notifikací. Může se jednat o samotná data (takzvaná Raw Notification), případně o aktualizaci živé dlaždice (Tile Notification) a v neposlední řadě informační řádek zobrazen přímo na displeji (Toast Notification). Pokud MPNS obdrží požadavek o doručení notifikace, tak tuto informaci potvrdí v kódu odpovědi (response code). Toto potvrzení se však týká přijetí požadavku. MPNS se pokusí při nejbližší příležitosti o doručení, ale ani to se nedá zaručit. O (ne)úspěšném doručení samotné zprávy se již nedozvíme. Pokud tedy provozujeme webovou službu, ze které Strana 18
budeme data odesílat, můžeme uživateli pouze zobrazit informaci o odeslání notifikace. Více informací nezískáme a můžeme tedy jen doufat, že zpráva dorazila. Push notifikace a jejich doručování mají své limity [9]: Komunikace mezi naší webovou službou a MPNS probíhá přes HTTPS. Pokud náš web není autorizován, tak můžeme poslat maximálně 500 push notifikací za den. Naše aplikace také může mít registrovanou pouze jedinou URI pro komunikaci a to i v případě, že zasíláme více typů notifikací. Pokud bychom i přesto chtěli získat další adresu pro zaslání notifikace, objeví se výjimka InvalidOperationException(PushNotificationChannelQuotaExceeded). Využívat push notifikace může pouze 30 aplikací v zařízení. I proto bychom měli předem zajistit ošetření na výjimku InvalidOperationException(PushNotificationChannelQuotaExceeded). Pokud chceme používat Toast Notification, tak uživatel musí mít možnost tyto notifikace vypnout. Součástí notifikace by neměly být soukromé údaje. Pokud velikost hlavičky notifikace překročí 1 KB a obsah notifikace 3 KB, dojde k vyvolání výjimky typu WebException se stavem WebExceptionStatus.ProtocolError. Push notifikace nefungují, pokud používáme proxy. Notifikace typu Toast Tile notifikace jsme si v podstatě popsali v předchozí části. Nyní si proto popíšeme další možnost jak vizuálně zobrazit notifikaci a to pomocí Toast Notification. Jak je ukázáno na obrázku, tak se jedná o barevný pruh v horní části obrazovky, který je zobrazen přibližně 10 sekund. Poté zmizí sám nebo ho uživatel zahozením doprava může zrušit. Pokud na pruh uživatel klikne, dojde ke spuštění naší aplikace. Obrázek č. 6 Ukázka notifikace typu Toast. Zdroj: [9] Strana 19
Opět můžeme nastavit několik parametrů: Title Název zobrazený tučně hned za ikonou aplikace. Content Text samotné zprávy. Pokud bude delší než se vejde na displej, dojde k uříznutí textu. Parameter Nejedná se o text, který by byl zobrazen. Přesto dojde k jeho předání naší aplikaci, pokud uživatel na notifikaci klikne můžeme tak notifikací upravit data v aplikaci či otevřít specifickou obrazovku v rámci aplikace. Background Agents Pokud naše aplikace není spuštěna a zobrazena na displeji, tak její kód neběží a není vykonáván. Pokud však potřebujeme, aby naše aplikace pracovala i v době, kdy není aktivně používána, máme jen několik možností k využití. Buď můžeme využít Push notifikace, které jsme popsali dříve (nevýhodou je nutnost připojení k internetu a omezená velikost přenášených dat) nebo můžeme využít takzvané Background Agenty. Opět zda narážíme na omezení Background Agent není podporován na zařízeních s 256 MB operační paměti. [10] Rozlišujeme dva typy Background Agentů. Prvním z nich je PeriodicTask. Typické použití je opakované spouštění časově nenáročného kódu například stažení teploty z internetového serveru. Druhým typem je ResourceIntensiveTask. Je vhodný na náročné operace či datově náročné činnosti. Využití tak tedy najde v době, kdy uživatel zařízení nepoužívá (a to je třeba připojeno k WiFi síti a zároveň je dobíjena baterie). Takže pokud naše aplikace potřebuje synchronizovat větší množství dat a využít aktuálně nepoužívané zařízení, toto je možnost, jak toho docílit. Naše aplikace může mít pouze jeden Background Agent, ale ten může být zaregistrován jako PeriodicTask, ResourceIntensiveTask nebo obojí. Pokud však budeme implementovat obě varianty, jen jedna z nich může běžet v jeden čas. Dalšími omezeními jsou [10]: Nejsou podporována veškerá systémová rozhraní. Například tak nelze přistupovat k fotoaparátu, webovému prohlížeči či přehrávání hudby na pozadí. Nelze využít více než 6 MB paměti. Pokud bychom toto překročili, dojde k automatickému ukončení běhu agenta. Agent může běžet maximálně dva týdny. Pokud tedy z naší aplikace čas běhu neprodloužíme, nebude dále agent využíván. Uživatel tak tedy musí mít důvod aplikaci spustit alespoň jednou během dvou týdnů. Pokud agent bude dvakrát ukončen nebo vyhodí výjimku, nebude spouštěn minimálně do dalšího spuštění naší aplikace. Strana 20
Toto jsou omezení obecná, nyní se pojďme podívat na omezení jednotlivých typů. PeriodicTask má následující omezení: Tento typ agenta je spouštěn každých 30 minut. Tento čas se však může klidně posunout o 10 minut vzhledem k vytížení zařízení. Běh agenta je kolem 25 vteřin. Pokud telefon přejde do stavu úspory baterie, může být pozastaveno spouštění agentů. V závislosti na hardwarové vybavenosti telefonu je stanoven limit registrovaných agentů v systému. Nejnižší možný počet je 6 agentů. Omezení agenta typu ResourceIntensiveTask jsou poté následující: Délka vykonávání kódu není větší než 10 minut. Zařízení musí být napájeno z externího zdroje energie (například z elektrické sítě). Musí být k dispozici připojení k internetu buď přes WiFi nebo z počítače. Baterie musí být alespoň na 90% maximální kapacity. Telefon nesmí mít vypnutý displej a zároveň nesmí probíhat hovor. Zkušební verze aplikace Jak již bylo dříve napsáno, tak uživatel má jedinou možnost, jak naší aplikaci do telefonu dostat stažením (či zakoupením) z Windows Phone Marketplace. Problém však nastává, pokud vytváříme placenou aplikaci. Pokud uživatele dostatečně nezaujme popis či obrázky aplikace, tak si naší aplikaci nezakoupí. Přitom by často stačilo, kdyby si aplikaci mohl vyzkoušet. I z tohoto důvodu se programátorům umožňuje vytvořit zkušební verzi aplikace. Pro pohodlí programátorů však nemusíme vytvářet nový projekt a poté vytvářet další verzi naší aplikace. Stačí upravit kód naší současné aplikace. V kódu je potřeba zjistit, zda uživatel má aplikaci koupenou a podle toho se přizpůsobit. Nejčastěji používaná omezení jsou časového rázu, kdy uživatel má k dispozici plně funkční aplikaci po určitou dobu, poté je nucen aplikaci zaplatit, pokud jí chce dále používat. Populární jsou i řešení, kdy je aplikace plně funkční a po určitém počtu kliknutí zobrazí výzvu ke koupení plné aplikace. Jestliže jsme se rozhodli naší aplikaci zpoplatnit, tak bychom nad trial verzí, jak je označována, měli přemýšlet. Nejproduktivnější český vývojář pro Windows Phone, Robert Varga, ve své prezentaci uvádí, že u jeho aplikací si v průměru z 10 zkušebních verzí stane jedna placená. [11] Strana 21
Publikování aplikace Pokud máme naší aplikaci hotovou a chceme se o ni podělit se světem, tak musíme udělat několik podstatných kroků, než se aplikace dostane k uživateli. Jedna z věcí, které musíme zkontrolovat, jsou informace o použitém jazyce. V Solution Exploreru Visual Studia tedy dvakrát klikneme na složku Properties v našem projektu. Na zobrazené obrazovce klikneme na tlačítko Assembly Information, kde vyplníme požadované údaje a hlavně v poslední volbě zvolíme jazyk naší aplikace. Pokud vytváříme aplikaci s více jazyky, zvolíme jazyk nejpoužívanější naší cílovou skupinou. Tato volba ovlivní popis aplikace ve chvíli, kdy jí budeme chtít publikovat. Obrázek č. 7 Okno Assembly Information. Dalším krokem je volba využívaných funkcí zařízení. V Solution Exploreru tedy najdeme soubor WMAppManifest.xml (nachází se ve složce Properties) a otevřeme ho. Nalezneme zde informace o naší aplikaci tak, jak se zobrazí v seznamu aplikací či výchozí informace zobrazené na dlaždici. V párovém tagu Capabilities poté máme seznam dostupných systémových rozhraní a tak zakomentujeme ty, které v naší aplikaci nepoužíváme. Strana 22
Obrázek č. 8 Ukázka správně zakomentovaných částí kódu. Dále je vhodné změnit grafické prvky použité v aplikaci. Veškerou grafiku, kterou budeme měnit, najdeme mezi soubory našeho projektu. Soubor SplashScreenImage.jpg je zobrazen při spuštění aplikace po dobu, než dojde k vykreslení aplikace. Má rozměry 480x800 pixelů. Dalšími obrázky jsou ApplicationIcon.png a Background.png tyto obrázky mají rozměry 62x62 pixely, resp. 173x173 pixely a slouží jako ikony (resp. větší slouží jako dlaždice). U těchto obrázků můžeme využít průhlednost bude však nahrazena barvou uživatelova vzhledu systému. Aplikaci musíme zkompilovat v režimu Release. Pokud to neučiníme, nebude možné aplikaci publikovat. Pokud si chcete být jisti, že aplikace projde certifikací a má veškeré náležitosti pro publikování, vyzkoušejte Marketplace Test Kit. Ten naleznete ve Visual Studiu v nabídce Project jako Open Marketplace Test Kit a umožňuje provádět automatické, monitorované a manuální testy aplikace. Pokud jsme splnili předchozí body, můžeme konečně naši aplikaci publikovat. To se provádí přes AppHub na adrese http://create.msdn.com. Registraci a typy účtů jsme zmínili v předchozím textu této práce, proto budeme předpokládat, že jsme řádnými Strana 23
uživateli a máme stále platné předplatné. Přejdeme tedy na položku my dashboard (dalo by se přeložit jako nástěnka), kde v pravé části obrazovky klikne na tlačítko submit a new app. Obrázek č. 9 Odkaz submit a new app se nachází v pravé části AppHubu. V prvním kroku vyplníme jméno naší aplikace a přidáme.xap soubor s aplikací. Ten se nachází v místě našeho projektu. Konkrétně ho najdeme ve složce Bin\Release. Zvolíme číslo verze aplikace, které se bude zobrazovat v prostředí Windows Phone Marketplace a můžeme přejít k dalšímu kroku. Tím je vyplnění popisu aplikace ve všech jazycích, které poskytuje. Pokud máme jazyk v aplikaci použit jen jeden, je zde možno vyplnit pouze jazyk zvolený v Assembly Information. Kromě popisu zde musíme přidat obrázky, které budou naši aplikaci prezentovat. Jedná se o tři ikony ve formátu PNG o rozměrech 99x99, 173x173 a 200x200 pixelů. U těchto ikon nemusíme vůbec řešit průhlednost. Dále je potřeba přidat obrázky z aplikace ty lze vytvořit v emulátoru systému. Ve zbývajících krocích zvolíme trhy, na které chceme naši aplikaci uvolnit a její cenu. Pokud máme implementovanou zkušební verzi aplikace, tak jí zde můžeme rovnou povolit. Posledním krokem před odesláním aplikace je volba publikace aplikace. Můžeme si vybrat, zda bude aplikace hned po schválení publikována, či publikaci provedeme manuálně sami. Po dokončení tohoto kroku je naše aplikace odeslána společnosti Microsoft ke kontrole a podepsání. Pokud na naší aplikaci nebude nalezen nějaký problém, tak v průměru po týdnu dostaneme zprávu, že naše aplikace prošla certifikací, což je nezbytný krok, aby si naši aplikaci lidé mohli stahovat či kupovat. Strana 24
Mobilní aplikace využívající webové API Součástí zadání této práce bylo vytvořit aplikaci využívající veřejně dostupné webové API (programovatelné rozhraní). Rozhodl jsem se tedy vytvořit aplikaci, která ukáže, jak jednoduše můžeme vytvořit vzhled aplikace a využít data o poloze zařízení. Aplikace tedy má zjistit polohu zařízení (souřadnice), dotázat se webového API na adresu místa, kde se nacházíme a po zpracování odpovědi text s adresou zobrazit. Pro ukázku jednoduchosti práce s dalšími komponentami jsem do aplikace přidal například mapovou komponentu či signalizaci práce na pozadí. Jako první je nutné vytvořit nový projekt. To se učiní ve Visual Studiu 2010 v nabídce File - > New a zvolením položky Project. Pro náš účel bohatě stačí jedna obrazovka, proto jsem zvolil projekt typu Windows Phone Application z nabídky Silverlight for Windows Phone (jazyk jsem, stejně jako v celé této práci, nechal Visual C#). Projekt jsem nazval KdeJsem a potvrdil stiskem tlačítka OK. Obrázek č. 10 Založení projekt a výběr vhodné šablony. Každého, a tedy i nás, poté čeká nutnost volby verze Windows Phone, pro který chceme psát. Zde není důvod volit jinak než variantu Windows Phone OS 7.1, tedy verzi systému nazvanou Mango. Strana 25
Obrázek č. 11 Výběr cílové verze systému. Po zvolení verze systému se nám otevře nově vytvořený projekt a před námi je otevřen soubor MainPage.xaml. V tomto souboru si připravíme celý vzhled aplikace. U původních prvků (například název aplikace MY APPLICATION či popisek page name) můžeme udělat změny nebo je klidně odstranit. V mém případě jsem prvky ponechal včetně stylizování, jen jsem změnil zobrazovaný text a název položek. Šablona dále obsahuje část v komentáři nazvanou jako ContentPanel. Do této části bychom měli přidat prvky, které budeme v aplikaci využívat. V mém případě se jedná o 5 komponent typu TextBlock, jednu mapovou komponentu a pro uživatelskou přehlednost jsem přidal do projektu i ProgressBar jedná se o ukazatel načítání, kterým zobrazím práci aplikace na pozadí, aby uživatel věděl, že aplikace pracuje. Tyto prvky jsem přidal do mřížky, které jsem definoval 6 řádků a nastavil výškové omezení jejich velikosti. U mapové komponenty chybí vlastnost CredentialsProvider. Pokud tato vlastnost nebude vyplněna platným kódem získaným registrací aplikace na webu Bing Maps (více o registraci je zmíněno v předchozím textu), bude se ve výsledné aplikaci zobrazovat vodoznak (jak můžete vidět na obrázcích výsledné aplikace dále). Protože bych chtěl kvůli mapové aplikaci používat tlačítka, rozhodl jsem se odkomentovat kód k obsluze aplikační lišty (ApplicationBar u konce kódu). Jelikož pro tlačítka upravující přiblížení mapy jsem chtěl použít ikony, musel jsem je přidat do projektu. V pravé části obrazovky se nachází Solution Explorer, do kterého jsem přidal dva obrázky a ve vlastnostech tlačítka s ikonou poté uvedl cestu na obrázky. Je důležité ve vlastnostech souboru zvolit, že se musí obrázek přidat při kompilaci do výsledného instalačního balíčku. Strana 26
Obrázek č. 12 Výsledné rozhraní napsané na pár řádcích kódu. Zdůraznil bych ještě nutnost každý prvek pojmenovat, abychom s ním poté mohli pracovat. Tím bychom měli hotov vzhled aplikace a můžeme se pustit do pravého programování, do tvorby kódu, který něco dělá. To budeme dělat v souboru MainPage.xaml.cs, který najdeme v Solution Exploreru. Nad již vytvořený konstruktor si vytvoříme proměnné, které budeme využívat. Konkrétně budeme potřebovat přistupovat k poloze, takže budeme potřebovat objekt typu GeoCoordinateWatcher a dále budeme muset někam uložit naše souřadnice. Tyto proměnné nám v celé třídě budou stačit a tak můžeme použít kód o získávání polohy, který je popsán v předchozí části této práce. Musíme ho lehce upravit, protože zde nemá spouštěcí a pozastavovací tlačítka. Místo toho spouštěcí metodu zavoláme přímo z konstruktoru, abychom měli výsledky co nejrychleji k dispozici a mohli je zobrazit uživateli. Nesmíme zároveň zapomenout v metodě určené pro obsluhu změny pozice uložit nové souřadnice. Zde jsem udělal jednu změnu kvůli pozdějšímu použití souřadnic v adrese webového API potřebujeme mít jednotný styl na všech zařízeních. V České republice se totiž používá desetinná čárka, zatímco například ve Spojených Státech Amerických se používá desetinná tečka. A desetinnou tečku taktéž využívá webové rozhraní Googlu, Strana 27
které jsem si vybral. Proto jsem si uložil hodnoty ještě v invariantní kultuře. Zároveň mohu data rovnou zobrazit a tak změním hodnotu Text příslušných textových bloků. Jelikož zjištění polohy je na zařízeních Windows Phone velmi rychlé, tak volám metodu obsluhující práci s webovým API hned po vykreslení všech komponent na obrazovku, jak je deklarováno v konstruktoru. Ve zmíněné metodě vytvořím objekt typu WebClient, kterému předám adresu API včetně vložených souřadnic ve správném formátu. Zvolené webové programovatelné rozhraní společnosti Google se jmenuje The Google Geocoding API a my využíváme takzvaný zpětný geocoding. Popis API se nachází na https://developers.google.com/maps/documentation/geocoding/#reversegeocoding a v odpovědi nám vrací kolekci s adresou v několika různých podobách. WebClient na zařízeních Windows Phone funguje asynchronně, tím pádem musíme připravit event handler pro obsloužení dokončeného stahování odpovědi. V event handleru poté je potřeba zpracovat odpověď. V mé aplikaci jsem si zvolil formát dat XML a proto pro parsování používám XDocument. Výslednou adresu poté vypíši a zavolám metodu pro vykreslení polohy na mapě. Zároveň je dobré si povšimnout, že odpověď od webového serveru může být neúplná nebo došlo k přerušení stahování. I s tím je potřeba počítat. Před odesláním dotazu API serveru také zapínám viditelnost lišty průběhu a až po zpracování odpovědi tuto vlastnost měním zpět. Nemůžeme vykreslit bod do mapy přímo, musíme nejprve vytvořit vrstvu nad mapovým podkladem a až poté můžeme do této vrstvy přidat špendlík s naší polohou. Provádím zde i změnu velikosti bodu, aby nezabíral tolik místa a byla vidět mapa pod ním. Rovnou je dobré zmínit, že zde nemám ošetřeno znovu vykreslení či aktualizaci polohy. To je z toho důvodu, že při změně polohy dojde jen ke změně hodnot dvou textových polí a nedojde například ke změně popisu fyzické adresy. Ta se totiž bude zjišťovat jen po spuštění aplikace. Poslední řádky kódu jsou obsluhou event handlerů tlačítek v aplikační liště. Ty zajišťují změnu přiblížení a změnu mapového podkladu. Strana 28
Obrázky č. 13 a 14 Výsledná podoba aplikace. Obrázky číslo 13 a 14 jsou pořízeny z finální verze aplikace. Jak již bylo zmíněno, nad mapou se zobrazuje vodoznak, neboť jsme nezadali vygenerovaný kód k mapové komponentě. Strana 29