REKLAMA Jeżeli jesteś zainteresowany/a reklamą swoich produktów w naszym magazynie

Transkrypt

1

2 REKLAMA Jeżeli jesteś zainteresowany/a reklamą swoich produktów w naszym magazynie Jeżeli jesteś zainteresowany/a wypromowaniem swojej marki wśród specjalistów IT Jeżeli szukasz klientów lub pracowników Zareklamuj się u nas! Posiadamy bazę 90 tysięcy specjalistów z różnych działów IT! W celu uzyskania oferty reklamowej skontaktuj się z nami: sdjpl@sdjournal.pl tel

3 4 Zastosowanie SCRUM w wytwarzaniu aplikacji mobilnych Karol Mioduszewski Stwierdzenie, że aplikacje mobilne to przyszłość, na stałe wpisało się we wszystkie oceny i analizy rynku IT. Podobnie jak ogólnie powtarzana prognoza dotyczącą Chin, które mają zostać pierwszą gospodarką świata. W obu tych przypadkach sama świadomość nie wystarczy, ani żeby odnieść sukces, ani utrzymać się na powierzchni. Idzie nowe, a od nas zależy czy w porę podejmiemy wyzwanie. W samym USA liczba użytkowników smartfonów wzrosła z 60.2 mln do 93.4 w przeciągu 3 lat ( ). Przy tym trendzie prognozuje się, że w roku 2015 będzie ich około mln, co w porównaniu do roku 2011 daje ponad 50% wzrost! 10 WINDOWS PHONE 8 ODKODOWANY Michał Bakalarczyk Dla osób, które chcą rozpocząć programowanie na platformę Windows Phone 8 już same wymagania dotyczące środowiska pracy mogą stanowić sporą barierę, a to dopiero początek wyzwań. Podpowiadamy, jak sobie z nimi radzić i stworzyć prostą aplikację Firefox OS - czy przełamie duopol ios i Android? Piotr Wirkus Zdalne aplikacje mobilne rozwiązanie problemu wieloplatformowości? Marcin Strażyński, Jacek Chmielewski Różnorodność mobilnych systemów operacyjnych i urządzeń powoduje, że każdy twórca aplikacji mobilnych staje przed dylematem na jakie platformy przygotować aplikację aby dotrzeć do jak największej grupy użytkowników, a jednocześnie nie rozbić budżetu. Na szczęście wybór między wieloma aplikacjami natywnymi, a uniwersalną aplikacją webową to nie jedyna opcja! 27 Aplikacje mobilne przyszłość dla programistów Kamil Brzeziński 28 Grafika 3D na urządzeniach przenośnych z systemem Android Jacek Matulewski Celem artykułu jest łagodne wprowadzenie do tematu projektowania gier dla systemu Android korzystających z grafiki trójwymiarowej OpenGL ES. 37 Nie sztuka wyprodukować,ale sztuka sprzedać MICHAŁ JANKOWSKI Tworzenie aplikacji mobilnych przestało już być zajęciem zarezerwowanym tylko dla wybranych. 39 User Experience - sztuka przewidywania jak myśli użytkownik Marek Kulesza Obecnie, gdy na rynek trafiają setki nowych aplikacji dziennie, warto pamiętać, że każdy produkt musi być użyteczny, rozwiązując faktyczny problem użytkowników. 44 Konkursy dźwignią rozwoju dla start-upów Małgorzata Korowaj Przełomowy pomysł, koncepcja wejścia na rynek, przemyślana misja i wizja rozwoju, badania konkurencji, ciekawe opakowanie i ogromny zapał w towarzystwie funduszy, które wystarczą na wprowadzenie idei w życie mogłyby stanowić idealną kompozycję składników dla każdego start-up a. 46 Kariera po szczeblach TechCampu Ponad 300 pasjonatów nowych technologii, 4 profesjonalistów na scenie i gorąca debata z udziałem krakowskim uczelni na koniec. Wszystko to w barowej atmosferze krakowskiego Lizard Kingu. Tak wyglądał 11 odcinek TechCampu: Kariera w IT bezpłatnych spotkań Akademii Unity, których patronem medialnym jest SDJ. 48 Hello, Android. Programowanie na platformę Google dla urządzeń mobilnych Ed Burnette Swego czasu firma Apple wyprodukowała serię telewizyjnych reklam, na których widzimy sylwetki ludzkie tańczące obłędnie w rytm muzyki generowanej przez ipoda. Miesięcznik Software Developer s Journal jest wydawany przez NPRACA Sp. z o.o. Redakcja: sdjpl@sdjournal.pl Kierownik produkcji: Andrzej Kuca Adres korespondencyjny: NPRACA Spółka z o.o. ul. 3 Maja 46, Nowogard, Polska Oddział w Warszawie: ul. Postępu 17 D, Warszawa, Polska Redakcja dokłada wszelkich starań, by publikowane w piśmie informacje i programy były poprawne, jednakże nie bierze odpowiedzialności za efekty wykorzystania ich; nie gwarantuje także poprawnego działania programów shareware, freeware i public domain. Wszystkie znaki firmowe zawarte w piśmie są własności odpowiednich firm. Zostały użyte wyłącznie w celach informacyjnych. Osoby zainteresowane wspópracą prosimy o kontakt: sdjpl@sdjournal.pl Skład i łamanie: Digital Concept admin@digitalconcept.pl Facebook:

4 Zastosowanie SCRUM w wytwarzaniu aplikacji mobilnych Stwierdzenie, że aplikacje mobilne to przyszłość, na stałe wpisało się we wszystkie oceny i analizy rynku IT. Podobnie jak ogólnie powtarzana prognoza dotyczącą Chin, które mają zostać pierwszą gospodarką świata. W obu tych przypadkach sama świadomość nie wystarczy, ani żeby odnieść sukces, ani utrzymać się na powierzchni. Idzie nowe, a od nas zależy czy w porę podejmiemy wyzwanie. W samym USA liczba użytkowników smartfonów wzrosła z 60.2 mln do 93.4 w przeciągu 3 lat ( ). Przy tym trendzie prognozuje się, że w roku 2015 będzie ich około mln, co w porównaniu do roku 2011 daje ponad 50% wzrost! Dowiesz się: Dlaczego SCRUM sprawdza się lepiej przy wytwarzaniu aplikacji mobilnych niż metodyki tradycyjne. Jak SCRUM sprawdza się w praktyce na przykładzie projektu. Jak pogodzić krótkie sprinty z zapewnieniem jakości dostarczanej aplikacji. Jakie narzędzia są pomocne w projektach tego typu. Dostępność to główna cecha aplikacji mobilnych. Każdy użytkownik tabletu, smartfona czy innego urządzenia opartego o mobilny OS, w każdym momencie ma dostęp do setek tysięcy (niedługo milionów) aplikacji. Kanały dystrybucji są zmonopolizowane przez gigantów z Cupertino i Mountain View, ale same sklepy rządzą się niemal zasadami idealnej konkurencji. Dlatego też jak najniższy współczynnik Time To Market (TTM) jest fundamentem sukcesu na rynku aplikacji mobilnych. To improve is to change; to be perfect is to change often W. Churchill W modelu kaskadowym (ang. waterfall) najpierw potrzeby klienta spisywane są w postaci wymagań, na podstawie których wykonuje się szacowanie kosztów oraz czasu niezbędnego do ich zaimplementowania. Następnie bazując na powyższych informacjach, przygotowuje się bardziej szczegółowy plan i po jego zaakceptowaniu możemy rozpoczynać prace związane z implementacją. Model ten jest genialny w swojej prostocie dopóki w toku prowadzonych prac nie pojawi się nieuniknione ZMIA- NA. Jeśli powstaje na początku projektu, jest wtedy duża szansa, że nie niesie za sobą poważnych konsekwencji. Z naszego doświadczenia wynika, że w dużej liczbie realizowanych projektów żądania zmian (ang. change request) Powinieneś wiedzieć: Czym są metodyki zwinnego wytwarzania oprogramowania. Jakie są podstawowe elementy procesu wytwórczego oprogramowania. pojawiają się pod koniec prac. Mają wówczas ogromny wpływ na pozostałe funkcjonalności sytemu, które również trzeba modyfikować, a wcześniej wykonane testy powtarzać lub pisać nowe odzwierciedlające zmienioną specyfikację. Obecnie utrzymywanie powiązań między artefaktami w systemie jest dużo łatwiejsze. Dzięki wsparciu narzędzi klasy ALM wiele czynności udaje się zautomatyzować, jednakże badanie analizy wpływu zmian wymaga czasem sporej wiedzy i nakładu pracy. Zmiana jest również nieodzowną składową projektów IT dotyczących aplikacji mobilnych. Wielość urządzeń, częstość zmian w OS, dynamika rozwoju możliwości urządzeń, bezpośredni feedback od klientów powodują szereg planowanych i nieplanowanych zmian, a każda z nich musi zostać umiejętnie zarządzona. Rewolucyjne podejście do zmian może zostać również przejęte z rynku gier komputerowych, gdzie obecnie bardzo popularnym modelem wdrożenia jest tzw. early access, w którym klienci końcowi płacą za dostęp do wczesnych buildów aplikacji. W zamian dostają oni możliwość współtworzenia finalnego wydania aplikacji. Zapotrzebowanie klienta końcowego i jego sugestie są bezpośrednim motorem rozwoju aplikacji. Przy takim podejściu modele kaskadowe są praktycznie bezużyteczne. Innym minusem klasycznego podejścia do wytwarzania oprogramowania, bezpośrednio powiązanym z powstawaniem żądań zmian na późnym etapie procesu wytwórczego, jest niewielkie zaangażowanie ze strony klienta/odbiorcy w proces wytwarzania. 4 3/2013

5 SCRUM W WYTWARZANIU APLIKACJI MOBILNYCH Nie uczestniczy on w procesie poza zbieraniem wymagań w początkowej fazie projektu oraz na jego końcu, gdy otrzymuje gotowy produkt do testów akceptacyjnych. W trakcie trwania tego ostatniego, szybko okazuje się, że oczekiwania klienta co do funkcjonowania systemu są zupełnie inne niż interpretacja wymagań ze strony zespołu projektowego. Pojawiają się problemy, żądania zmian, dyskusje, opóźnienia w projekcie, szukanie winnych. Lekarstwem na uniknięcie podobnych dolegliwości w projektach może być proces zwinnego wytwarzania oprogramowania Agile. Pod tym pojęciem kryją się metodyki wytwarzania oprogramowania oparte na programowaniu iteracyjnym (model przyrostowy). Generalnie metodyka nastawiona jest na osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania. Zespół jest wielofunkcyjny oraz samoorganizujący i nie stosuje się w nim hierarchii korporacyjnej. Dokonywane są bardzo częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji jak i oprogramowania) przy bardzo dużym udziale klienta, a po każdej iteracji dostarczane jest działające rozwiązanie. Dzięki powyższym cechom Agile znacząco wpływa na obniżenie współczynnika TTM. Innym, bardzo ważnym czynnikiem wpływającym na sukces danej aplikacji jest możliwość używania jej na wielu systemach operacyjnych. Stąd też coraz bardziej popularne stają się platformy umożliwiające pisanie rozwiązań na wiele systemów operacyjnych jednocześnie. Case study - Cel projektu, założenia, platforma i wybrana metodyka Celem projektu było zaprojektowanie, stworzenie, przetestowanie i wdrożenie aplikacji wspierającej sprzedaż dużej międzynarodowej organizacji z branży logistycznej. Główne wymagania funkcjonalne obejmowały możliwość komunikacji za pośrednictwem sieci GSM, z serwerem SQL oraz systemem klasy ERP, a także realizowanie sprzedaży w trybie zarówno offline jak i online. Platformą wybraną do tworzenia aplikacji mobilnej została Antenna, która po raz drugi z rzędu została uznana przez firmę Gartner za Lidera w rocznych ocenach platform do tworzenia aplikacji mobilnych. Antenna umożliwia pisanie aplikacji mobilnych na kilka systemów operacyjnych jednocześnie. W naszym przypadku, z uwagi na specyfikę klienta był to Windows Mobile 6.5 (klient dysponował dużą liczbą urządzeń z właśnie tym systemem operacyjnym) oraz w późniejszej perspektywie - Android. Dlatego też bardzo ważnym założeniem projektu była płynna możliwość przejścia z używanych Rysunek 1. Sprint urządzeń z systemem Windows Mobile na urządzenia z systemem Android, bez konieczności dokonywania zmian w oprogramowaniu lub tworzenia go od podstaw. Spośród dostępnych metodyk zwinnego prowadzenia projektów wybrany został SCRUM. Cały projekt został podzielony na dziewięć sprintów, przy czym trwały one maksymalnie do czterech tygodni. Przed rozpoczęciem projektu istniały wymagania spisane w postaci dokumentów, jednakże poziom ich szczegółowości był na tyle ogólny, że można uznać, że ich nie było, np.: system musi posiadać możliwość monitorowania. Na początku pracy nad produktem, przy bardzo dużym zaangażowaniu zespołu klienta, została spisana lista wymagań użytkownika w formie historyjek (ang. User Stories). Następnie właściciel produktu (ang. Product Owner) nadał im priorytet i ustalił wraz z zespołem cele pierwszego sprintu oraz zdefiniował rejestr wymagań (ang. Product Backlog), czas realizacji, pracochłonność wraz z listą zadań (ang. Sprint Backlog), złożoność oraz ryzyka dla poszczególnych zadań. Po tych ustaleniach następowała realizacja przebiegu. Organizowane były codzienne spotkania (ang. Daily Scrum), podczas których omawiane były zadania realizowane dnia poprzedniego, napotkane problemy, jak również zadania, które miały być realizowane w dniu spotkania. Na pierwszym rysunku został zilustrowany przebieg przykładowego Sprintu, należy zwrócić uwagę, że trwa on relatywnie długo (30 dni). Nad poprawną interpretacją wymagań cały czas czuwał Product Owner, lecz nie ingerował on w sposób w jaki zadania były implementowane. Członkowie zespołu sami dokonywali wyboru zadań, które chcą realizować. Jedyną wytyczną była ich kolejność realizacyjna wynikająca bezpośrednio z priorytetu zadania korelująca z priorytetem User Stories. Przebiegi kończyły się prezentacją wyników pracy zespołu dla klienta w postaci Sprint Review, w których uczestniczyli (nie zawsze osobiście, również przez dostępne 5

6 formy komunikacji) wszyscy zainteresowani projektem. Podczas przeglądu każdy uczestnik spotkania mógł zabrać głos i wyrazić swoją opinię o produkcie. Pozwoliło to bardzo szybko zidentyfikować potrzeby dokonania zmian, tak aby produkt końcowy spełniał wszystkie założenia. Dzięki temu można było skupić się na dostarczaniu kolejnych coraz bardziej dopracowanych funkcjonalności systemu. Tradycyjny scrum board lub kanban board może zostać odtworzony w narzędziu (Rally, JIRA Grasshopper, SpiraTeam). W naszym przypadku członkowie zespołu projektowego byli agile owymi konserwatystami. Rysunek 2. SCRUM Board Narzędzia Głównym narzędziem w naszym projekcie była tablica scrum (ang. scrum task board). Przykładowy scrum board został zobrazowany na rysunku 2, tablica w projekcie miała identyczne kolumny. Większość członków zespołu pracowała w jednym pomieszczeniu, więc posiadanie takiej żywej tablicy było bardzo uzasadnione. Dzięki scrum boardowi oraz karteczkom samoprzylepnym łatwiej było planować pracę, identyfikować problemy i dynamicznie żonglować zadaniami, a sam wygląd tablicy motywował dodatkowo do pracy. Wytwarzanie i testy zostały wsparte kilkoma niezbędnymi narzędziami, które umożliwiły raportowanie i dokumentację postępów prac. Filarami tego środowiska były Inflectra SpiraTeam w połączeniu z Microsoft Team Foundation Server (wchodzi w skład pakietu Microsoft Visual Studio). W SpiraTeam utrzymywane były wymagania oraz powiązane z nimi manualne przypadki testowe, z których można budować scenariusze. Wykonywane były testy manualne i automatyczne, a wszelkie rozbieżności z wyniku testu raportowane były w postaci różnych typów incydentów. Moduł incydentów SpiraTeam został zintegrowany z odpowiadającym modułem MS TFS. Ta dosyć prosta integracja (darmowy plugin dostarczony przez Inflectrę) dała zespołowi wiele korzyści. Programiści nadal pracowali w znanym im środowisku plat- Rysunek 3. Sikuli 6 3/2013

7 SCRUM W WYTWARZANIU APLIKACJI MOBILNYCH formy Visual Studio, a prace związane z zapewnieniem jakości realizowane były w narzędziu bardziej skoncentrowanym na QA. Wymiana informacji w czasie rzeczywistym, umożliwia szybką reakcję, a rozszerzone możliwości śledzenia (incydent -> przebieg testowy -> wymaganie) dają lepszy pogląd na to jaka jest geneza i wpływ na bieżący sprint. Jednym z założeń pracy w takiej metodyce może być tworzenie testów automatycznych jeszcze przed powstaniem kodu tzw. TDD (ang. Test Driven Development). Wprowadzenie TDD narzuca duże uporządkowanie zarówno w testach jak i samym kodzie. Testy winny być proste oraz przez cały czas powinny utrzymywać powiązanie z kodem w celu szybkiej identyfikacji i refaktoringu. SCRUM, jak i inne metodyki zwinne, przewiduje bardzo dużą liczbę zmian w trakcie trwania całego projektu, jak i w poszczególnych sprintach. Są one nawet pożądane, a ich brak może być niepokojący, ponieważ prawdopodobnie oznacza brak zaangażowania, czy to ze strony klienta, czy zespołu. To z kolei może prowadzić do powstania niekompletnego lub działającego niezgodnie z oczekiwaniami produktu końcowego. W takim podejściu za każdym razem, gdy wprowadzana jest zmiana, konieczne jest powtórzenie wszystkich testów od samego początku. Tak, aby zweryfikować, że wprowadzone modyfikacje działają zgodnie z założeniem i czy nie została przy tej okazji zaimplementowana pomyłka, mogąca mieć wpływ na działanie pozostałych funkcjonalności. W wielu projektach stosuje się również testy jednostkowe jako pierwszą linię weryfikacji poprawności zaimplementowanego kodu. Z uwagi na zastosowaną platformę, posiadającą swój własny język programowania, takie podejście nie do końca było możliwe do zrealizowania. Założenia zostały zmodyfikowane i wdrożone zostało rozwiązanie polegające na napisaniu w pierwszej kolejności testów automatycznych GUI do już istniejącego kodu, pokrywających User Stories, oraz stworzenie z nich stale aktualizowanej bazy, możliwej do uruchomienia w dowolnym momencie. Automatyzacja natywnych aplikacji mobilnych nie należy do najłatwiejszych, a dodatkowo narzucony przez klienta system Windows Mobile 6.5 nie jest wspierany przez wiele narzędzi do automatyzacji. Do celów zautomatyzowania testów użyliśmy narzędzia open-source Sikuli Script (rysunek 3) w połączeniu z MyMobiler (rysunek 4). Sikuli jest narzędziem opierającym się na rozpoznawaniu elementów GUI. Działa na zasadzie wykonywania zrzutów ekranów, a następnie rozpoznawaniu ich podczas odtwarzania. Jest w stanie zapamiętywać wprowadzone dane z klawiatury w czasie nagrywania. Niestety również to narzędzie nie działa bezpośrednio na urządzeniu mobilnym. Aby je wykorzystać w praktyce niezbędny był MyMobiler. Aplikacja ta służy do wyświetlania i kontrolowania tego, co dzieje się na urządzeniu mobilnym bezpośrednio na monitorze komputera za pośrednictwem połączenia USB lub WiFi. MyMobiler działa zarówno z Windows Mobile jak i z Android em. Dodatkowe funkcje, które bardzo przydały się podczas prac w projekcie, to możliwość wykonywania zrzutów ekranów, nagrywania wideo oraz możliwość kopiowania/wycinania/wklejania tekstu pomiędzy urządzeniem a PC. Taki zestaw narzędziowy zapewnił nam możliwość powtarzania podstawowych scenariuszy testów funkcjonalnych automatycznie, w dowolnym momencie, bez konieczności wykonywania wszystkich testów ręcznie. Pomogło to zaoszczędzić czas, który mógł być wykorzystany przy realizacji innych aktywności. Niestety samo narzędzie Sikuli nie zapewnia możliwości budowania skomplikowanych logicznie testów. Dlatego też często operowaliśmy na przygotowanym wcześniej i nagranym w narzędziu zestawie danych, a ich zwalnianie do ponownego użycia odbywało się za pośrednictwem skryptu bazodanowego. Narzędzie posiada przejrzysty interfejs, dzięki któremu dostosowanie automatu do powstałych zmian było dość proste, ale wymagało czasu. Z uwagi na wspomniane wcześniej ograniczenia, część testów wymagających większej ilości akcji i zależności pomiędzy danymi, wykonywana była ręcznie. Ostatecznie Rysunek 4. MyMobiler 7

8 jednak był to proces mniej czasochłonny niż wykonywanie wszystkich testów manualnie. Testowanie W SCRUM nie ma dedykowanego zespołu testowego - testują wszyscy jego członkowie. Nie istnieje również przekazywanie oprogramowania do testów w jakimś konkretnym, ustalonym punkcie w czasie. Testy wykonywane są w sposób ciągły. W naszym projekcie nagięliśmy w pewnym stopniu tę zasadę i część zespołu zajmowała się w większym zakresie zadaniami związanymi z zapewnianiem jakości. Taka interpretacja SCRUM została podyktowana przez cechy indywidualne członków zespołu. Jednakże nie doprowadziliśmy do powstania efektu tzw. mini waterfalli, gdzie w sprintach tak naprawdę wykonuje się zadania zgodnie z podejściem kaskadowym. Oprócz wspomnianych wcześniej testów automatycznych, wykonywane były testy eksploracyjne, które miały na celu znalezienie ewentualnych nieprawidłowości. Czyli specyficzne sytuacje, nie zdarzające się w przyjętym procesie biznesowym, a mogące pojawić się w rzeczywistości, gdy użytkownik będzie chciał zrealizować coś na skróty lub wykona jakąś operację przez przypadek. Znalezione incydenty były weryfikowane i potwierdzane, a następnie w razie potrzeby, zgłaszane w systemie SpiraTeam, skąd trafiały automatycznie do MS TFS oraz na scrum board. W przypadku zidentyfikowania defektu, którego naprawa nie zajmowała dużo czasu, był on naprawiany natychmiast. Poprawka była testowana zaraz po naprawie, a w razie potrzeby uruchamiane były testy automatyczne, weryfikujące czy implementacja poprawki nie ma wpływu na pozostałe funkcjonalności. W swojej codziennej pracy członkowie zespołu skupiali się przede wszystkim na poprawianiu znalezionych bugów. W następnej kolejności przeprowadzany był code review wraz z krótkim demo funkcjonowania stworzonego kodu w praktyce. Ostatnim z codziennych zadań było tworzenie nowego kodu. Źródła Rysunek 5. GC Heap Viewer 8 3/2013

9 SCRUM W WYTWARZANIU APLIKACJI MOBILNYCH Takie podejście miało szereg plusów. Dzięki code review i sesji demo, cały zespół mógł zajrzeć do wnętrza aplikacji oraz poznać nowo tworzone funkcjonalności, wychwycić ewentualne błędy lub nieprawidłową interpretację wymagań. Natomiast zastosowanie automatyzacji testów pozwoliło zaoszczędzić czas na sprawdzanie podstawowych funkcjonalności systemu i skupić się na bardziej wyszukanych testach eksploracyjnych. Ciekawostką wartą wspomnienia jest sytuacja, na jaką natknęliśmy się podczas testowania aplikacji na systemie Windows Mobile 6.5. System na pewnym etapie projektu zachowywał się dość niestabilnie. Niestabilność ta polegała na tym, że aplikacja wyłączała się po jakimś czasie użytkowania, nie pozostawiając w logach żadnych informacji. Do zidentyfikowania przyczyny problemu użyliśmy narzędzi PowerToys.NET Compact Framework 3.5, a w szczególności Remote Performance Monitor and GC Heap Viewer (rysunek 5). GC Heap Viewer pobiera w czasie rzeczywistym dane z liczników, m.in. aktywności Garbage Collectora z działającej aplikacji NETCF. GC Heap Viewer pozwala podglądać zarządzany stos w czasie działania aplikacji i wyświetlać referencje oraz porównywać wiele zrzutów w celu znalezienia wycieku pamięci. Przyczyną okazał się wyciek pamięci spowodowany nieprawidłowym zamykaniem pewnych elementów aplikacji, co w trakcie użytkowania powodowało liniowy przyrost zużycia pamięci urządzenia, a efektem końcowym był tak zwany crash. Kiedy możemy zakończyć testowanie w sprincie, a kiedy w całym projekcie? Jeśli chodzi o SCRUM jest to bardzo trudne pytanie, na które musieliśmy sobie odpowiedzieć. Wnioski jakie nam się nasunęły są dosyć łatwe do odgadnięcia, niestety dość trudne do przyswojenia dla sponsora projektu. Testy muszą trwać od samego początku przedsięwzięcia jakim jest zaprojektowanie i wdrożenie aplikacji mobilnej, do samego końca okresu zakontraktowanego utrzymania. Podsumowanie W naszym przypadku SCRUM okazał się strzałem w dziesiątkę. Członkowie zespołu mieli wcześniej doświadczenia przy tworzeniu podobnych systemów w modelu kaskadowym, w którym produkt dostarczany był do wglądu na końcu procesu wytwórczego. Jak łatwo się domyślić, prawie zawsze spotykało się to z obiekcjami zamawiającego. Koniec projektu kojarzył się z gorączkową pracą po godzinach. SCRUM oraz inne metodyki zwinne mają bardzo istotną cechę w porównaniu z tradycyjnymi metodami. Jednym z ich filarów jest człowiek-specjalista, który posiada wiedzę jak zrealizować trudne zadania. Drugim filarem jest drużyna, która sama napędza się do działania i skutecznie przeciwdziała problemom. Trzecim filarem jest Scrum Master, który czuwa by drużyna pracowała efektywnie i stara się usunąć wszystkie bariery utrudniające wykonanie zadań, a także trzyma w ryzach czas pracy poszczególnych członków zespołu (w ekstremalnych przypadkach po przepracowanych 8 godzinach Scrum Master wyłącza monitory z kontaktu). Metodyki zwinne opierają się na interakcjach międzyludzkich nie tylko w relacji Scrum Master i drużyna, ale także dzięki relatywnie krótkim sprintom, w relacjach dostawca zamawiający. Każdy sprint wiąże się z dostawą, co daje klientowi pogląd jak wyglądać będzie aplikacja, a także daje mu poczucie, że ma kontrolę nad tym za co płaci. Wliczając aplikacje nie utrzymywane, w dniu oddania tego artykułu w amerykańskim itunes jest łącznie aplikacji ( aplikacji jest aktywnych). Autor zdaje sobie sprawę, że gros tej liczby to małe aplikacyjki, które często napisane są przez amatorów. Gust i zapotrzebowanie użytkowników zmieniają się, ponieważ wiadomo, że apetyt rośnie w miarę jedzenia. Często powtarzane zdanie There s an app for that, za jakiś czas może nie odzwierciedlać stanu bieżącego. Użytkownicy będą oczekiwali narzędzi spełniających wiele skomplikowanych zadań, o jakości i funkcjonalnościach takich samych jak aplikacje pudełkowe/biznesowe na desktopy. Zdaniem autora metodyki zwinne są jedynym słusznym rozwiązaniem dla zarządzania wytwarzaniem aplikacji dla środowisk mobilnych. Presja czasu, duża konkurencja, nieustający rozwój urządzeń i systemów mobilnych wymusza, aby każde wykonane zadanie przybliżało nas do celu jakim jest wydanie najlepszej aplikacji mobilnej. Karol Mioduszewski Test Manager w Soflab Technology W dziedzinie testowania oprogramowania doświadczenie zdobywał w szerokim zakresie ról: od Testera Oprogramowania, poprzez Analityka Testowego, Inżyniera Testów Wydajnościowych i Automatycznych, do Test Managera. Posiada bogatą i praktyczną wiedzę odnośnie zarządzania zespołami projektowymi, prowadzenia projektów IT oraz procesów testowych. Zdobywał ją na przestrzeni lat w wielu firmach i organizacjach międzynarodowych. Kompetencje merytoryczne w obszarze testów zdecydował się poszerzać w firmie Soflab Technology. 9

10 WINDOWS PHONE 8 ODKODOWANY Dla osób, które chcą rozpocząć programowanie na platformę Windows Phone 8 już same wymagania dotyczące środowiska pracy mogą stanowić sporą barierę, a to dopiero początek wyzwań. Podpowiadamy, jak sobie z nimi radzić i stworzyć prostą aplikację. DOWIESZ SIĘ Poznasz cykl życia aplikacji Window Phone Dowiesz się jak tworzyć aplikacje Windows Phone z wieloma widokami Dowiesz się jak tworzyć aplikacje Windows Phone z wykorzystaniem baz danych POWINIENEŚ WIEDZIEĆ Jak tworzyć interfejs w języku XAML Podstawowe informacje o bazach danych Technologię Linq Prześledźmy najpierw konieczne warunki. W przypadku WP8 Wymaganym środowiskiem jest 64 bitowy Windows 8 oraz Visual Studio w wersji minimum 2012 z doinstalowanym rozszerzeniem Windows Phone 8 SDK. Dodatkowo, ponieważ emulator WP8 jest uruchamiany jako maszyna wirtualna Hyper-V, system Windows musi być w wersji PRO, a sam komputer powinien wspierać wirtualizację oraz technologię SLAT. Mając już skonfigurowane środowisko, możemy rozpocząć programowanie. Zajmiemy się prostą aplikacją umożliwiającą przeglądanie i wyszukiwanie na liście produktów oraz podglądanie szczegółów wybranego produktu. Za bazę produktów posłuży nam lista wybranych telefonów pracujących na środowisku WP8. Dane na temat produktów będą przetrzymywane w bazie danych na telefonie. Wybór szablonu projektu Po zainstalowaniu Windows Phone 8 SDK mamy dostępnych kilka szablonów aplikacji, od których możemy zacząć pisanie kodu. Warto przejrzeć poszczególne szablony i zobaczyć jak rozwiązane są tam pewne typowe problemy (Rysunek 1). Ponieważ pierwszym widokiem dla użytkownika będzie lista wszystkich dostępnych telefonów dostępnych w aplikacji, wybieramy szablon Windows Phone Databound App: Aplikacja założona z tego szablonu zawiera dwa widoki. Listę elementów oraz widok szczegółów. Otwierając plik MainPage.xaml zobaczymy, po lewej stronie, wygenerowany widok który zmienia się wraz ze zmianami kodu strony xaml. Za dostarczenie danych dla widoku designer-a odpowiada atrybut z Listingu 1. Zawiera on przykładowe dane używane przez designer do generowania widoku. Warto aktualizować ten z przykładowymi danymi, jeśli zmieniamy format wyświetlanych Rysunek 1. Wybór szablonu projektu Listing 1. Definiowanie przykładowych danych dla widoku designera (XAML) d:datacontext="{d:designdata SampleData/MainViewModelSampleData.xaml" 10 3/2013

11 WINDOWS PHONE 8 danych. Pozwoli to, bez konieczności uruchamiania kodu, widzieć jak wyglądać będzie strona na telefonie. Cykl życia aplikacji WP8 Warto być świadomym w jaki przebiega cykl życia aplikacji w środowisku Windows Phone 8. Poniższy diagram obrazuje poszczególne stany w jakich może się znaleźć aplikacja. Po uruchomieniu aplikacji może ona zostać zamknięta przez użytkownika (Rysunek 2), ale może również zostać deaktywowana. Powodów deaktywacji jest wiele np. przełączenie się użytkownika do innej aplikacji lub rozmowa przychodząca. Dla każdego ze stanów dostępne są odpowiednie metody w obiekcie App, które umożliwiają wykonanie kodu podczas kolejnych zdarzeń: Rysunek 2. Cykl życia aplikacji Application_Launching Application_Closing Application_Activated Application_Deactivated Obiekt biznesowy Klasa, która została wygenerowana z szablonu projektu, nie odpowiada potrzebom biznesowym naszej aplikacji. W związku z tym, dodajemy do projektu nową klasę Rysunek 3. Formatka wyświetlania informacji na widoku listowym Listing 2. Definicja kontrolki LongListSelector (XAML) <phone:longlistselector x:name= MainLongListSelector" ItemsSource= {Binding Items > <phone:longlistselector.itemtemplate> <DataTemplate> <StackPanel Orientation= Horizontal > <Image Source= {Binding PhotoContent, Converter={StaticResource ImageConverter x:name= ProductPhoto Height= 100 HorizontalAlignment= Left > </Image> <StackPanel> <TextBlock Text= {Binding Title /> <TextBlock Text= {Binding FullName /> </StackPanel> </StackPanel> </DataTemplate> </phone:longlistselector.itemtemplate> </phone:longlistselector> Listing 3. Przykładowa implementacja interfejsu IValueConverter (C#) public class ImageConverter : IValueConverter { static readonly string NO_PHOTO = /Assets/NoPhoto.png ; public object Convert(object value, Type targettype, object parameter, System.Globalization. CultureInfo culture) { var uri = new Uri(NO_PHOTO, UriKind.Relative); BitmapImage image = new BitmapImage(uri); return image; 11

12 ProductDescription zawierającą podstawowe informacje o telefonie takie jak ID, nazwa skrócona i pełna, opis, wielkość wyświetlacza czy ilość RAM-u. Jako kontener dla danych wyświetlanych na widoku listowym użyjemy dostępnej już w szablonie klasy MainViewModel. Wystarczy zmienić w metodzie LoadData tej klasy wypełnianie listy domyślnymi obiektami typu ItemViewModel na obiekty utworzonej wcześniej klasy ProductDescription. Ponieważ wyświetlanie wszystkich tych informacji na stronie głównej może spowodować, że aplikacja będzie nieczytelna więc na stronie widoku listowego dla każdego telefonu wyświetlimy dane w następującej formie: Klikniecie na którykolwiek element spowoduje przejście do szczegółów telefonu (Rysunek 3) gdzie dostępne będą dodatkowe informacje. Jak widać powyżej częścią opisu telefonu będzie również zdjęcie ale na chwilę obecną załóżmy, że jedno zdjęcie będzie wspólne dla wszystkich telefonów. W późniejszym czasie zdefiniujemy osobne zdjęcia dla każdego z telefonów. Do wyświetlania danych listowych użyjemy kontrolki LongListSelector dostępnej w SDK WP8. Definiując wygląd listowy użyjemy techniki wiązania kontrolek do właściwości źródła danych dla aktualnego widoku. Widok MainPage ma ustawioną właściwość DataContext na klasę MainViewModel więc możemy się dowoływać do właściwości tej klasy. Poniższy listing pokazuje definicję kontrolki LongListSelector: (Listing 2). W elemencie LongListSelector definiujemy, że ItemSource powinno być powiązane do właściwości Items z kontekstu strony. Z kolei w elemencie DataTemplate de- Listing 4. Przykład stylowania kontrolek predefiniowanymi stylami (XAML) <TextBlock Text= {Binding FullName Style= {StaticResource PhoneTextSubtleStyle Foreground= {StaticResource PhoneAccentBrush /> Listing 5. Definicja pola wyszukiwania (XAML) <TextBox x:name= Search KeyDown= Search_KeyDown /> Listing 6. Implementacja zdarzenia naciśnięcia klawisza w kontrolce wyszukiwania (C#) private void Search_KeyDown(object sender, System.Windows.Input.KeyEventArgs e) { if (e.key == Key.Enter) { var txt = sender as TextBox; if (txt!= null) { App.ViewModel.Filter=txt.Text; Listing 7. Zmodyfikowana kontrolka LongListSelector (XAML) <phone:longlistselector x:name= MainLongListSelector ItemsSource= {Binding FilteredItems > Listing 8. Atrybuty dla właściwości ID (C#) [Column(IsPrimaryKey = true, IsDbGenerated = true)] Listing 9. Klasa kontekstu (C#) public class ProductsDataContext:DataContext { public Table<ProductDescription> Produts; public ProductsDataContext(string connectionstring) : base(connectionstring) { Listing 10. Tworzenie bazy danych z kodu (C#) public ProductsDataContext DBContext { get; private set; public void EnsureData() { if(dbcontext==null) DBContext = new ProductsDataContext( isostore:/productdb.sdf ); if (!DBContext.DatabaseExists()) DBContext.CreateDatabase(); 12 3/2013

13 WINDOWS PHONE 8 finiujemy szablon dla poszczególnych elementów na liście. Np. kontroli TextBlock mają powiązane właściwości Text. Dla kontrolki Image (odpowiedzialnej za wyświetlanie obrazów) oprócz źródła obrazu, czyli właściwości Source, definiujemy także Converter. Klasa ta będzie odpowiedzialna za przekonwertowanie ciągu danych z bazy na faktyczny obraz, natomiast jeśli telefon nie będzie miał zdefiniowanego zdjęcia wyświetli Klasa ta implementuje interfejs IValueConverter a jej przykładowa implementacja przedstawiona jest poniżej: Na razie metoda dla każdego wywołania zwróci grafikę domyślną (Listing 3). Stylowanie Ponieważ domyślny sposób wyświetlania może nie być dla nas odpowiedni więc każdą z kontrolek możemy ostylować. Możemy oczywiście użyć własne style ale warto zwrócić uwagę na zestaw styli systemowych. Użycie tych styli spowoduje, że kolorystyka naszej aplikacji będzie dostosowywać się do motywu wybranego przez użytkownika (Rysunek 4). Dla przykładu kontrolka wyświetlająca pełną nazwę telefonu ostylowana jest w następujący sposób: Powoduje to, że w zależności od wybranego tematu tekst w kontrolce wyświetlany jest w inny, ale spójny z wyglądem interfejsu całego telefonu, sposób (Listing 4). Filtrowanie źródła Ponieważ jedną z założonych funkcjonalności w aplikacji będzie możliwość przeszukiwania listy telefonów do widoku dodajemy dodatkowe pole Szukaj umożliwiającego wpisanie użytkownikowi frazy po której nastąpi Rysunek 4. Widok listowy po przełączeniu motywu telefonu Listing 11. Tworzenie bazy na podstawie istniejącego pliku bazy danych (C#) public bool CreateIfNotExists(){ bool created = false; if (!this.databaseexists()) { if (name!= null) { using (Stream resourcestream = Assembly.GetExecutingAssembly(). GetManifestResourceStream(name)) { if (resourcestream!= null) { using (IsolatedStorageFile myisolatedstorage = IsolatedStorageFile.GetUserStoreForApplication()) { using (IsolatedStorageFileStream filestream = new IsolatedStorageFileStream(FileName, FileMode.Create, myisolatedstorage)) { using (BinaryWriter writer = new BinaryWriter(fileStream)) { long length = resourcestream.length; byte[] buffer = new byte[32]; int readcount = 0; using (BinaryReader reader = new BinaryReader(resourceStream)) { while (readcount < length) { int actual = reader.read(buffer, 0, buffer.length); readcount += actual; writer.write(buffer, 0, actual); created = true; else { this.createdatabase(); created = true; 13

14 wyszukiwanie. Po potwierdzeniu wyszukiwania klawiszem enter lista produktów powinna zostać zawężona do elementów których nazwa lub opis zawierają wpisaną frazę. Definicja pola wyszukiwania przedstawiona jest w Listingu 5. Musimy oprogramować zdarzenie Search_KeyDown które będzie uruchamiane przy wpisaniu jakiegoś znaku do pola tekstowego. Implementacja przedstawiona jest w Listingu 6. Klasę MainViewModel rozszerzymy o dwie właściwość: Filter przechowującą aktualnie wyszukiwany tekst oraz FilteredItems zwracającą listę produktów spełniających warunki wyszukiwania (Listing 6). Należy też zmienić właściwość ItemsSource kontrolki LongListSelector, tak żeby wyświetlała teraz elementy zgodne z wpisanym filtrem z Listingu 7. Przechowywanie informacji w bazie danych Do tej pory aplikacja pracowała na statycznym źródle danych. Ponieważ nie jest to najbardziej optymalne rozwiązanie zaimplementujemy w pisanej aplikacji przechowywanie danych w dedykowanej bazie danych. Aplikacje Windows Phone 8 wykorzystują SQL Server Compact do przechowywania danych. Praca z taką bazą z poziomu kodu odbywa się z wykorzystaniem technologii Linq2SQL. Oznacza to, że nie możemy zadać zapytania bezpośrednio do bazy za cała komunikację z bazą odpowiada Framework. Aby rozpocząć pracę z bazą musimy opisać klasę produktu dodatkowymi atrybutami. Klasa ProductDescription zostanie opisana atrybutem [Table], a poszczególne właściwości atrybutami [Column]. Dodatkowo właściwość ID oznaczymy jako klucz główny oraz jako właściwość generowaną automatycznie przez silnik bazy danych opisany w Listingu 8. Klasa będzie dodatkowo implementowała dwa interfejsy INotifyPropertyChanged, INotifyPropertyChanging umożliwiające śledzenie zmian właściwości przez silnik bazy danych. Do komunikacji z bazą danych musimy napisać również klasę kontekstu dziedziczącą po klasie DataContext. To ta klasa jest pośrednikiem pomiędzy naszymi obiektami a bazą. Jej implementacja jest bardzo prosta: Mając tak zdefiniowane klasy możemy zająć się tworzeniem bazy danych (Listing 9). Możliwości tworzenia bazy danych Z kodu Najprostszą metodą utworzenia bazy danych jest wygenerowanie jej na podstawie wcześniej utworzonych klas. Poniższy kod sposoduje wygenerowanie bazy w lokalizacji isostore:/productdb.sdf: Listing 12. Modyfikacja metody tworzącej bazę danych(c#) public void EnsureData() { if(dbcontext==null) DBContext = new ProductsDataContext( isostore:/productdb.sdf ); DBContext.CreateIfNotExists(); Listing 13. Definicja kolumny przechowującej zdjęcie telefonu (C#) [Column(DbType= Image )] public System.Data.Linq.Binary PhotoContent { get { return _photocontent; set { if (value!= _photocontent) { InvokePropertyChanging( PhotoContent ); _photocontent = value; InvokePropertyChanged( PhotoContent ); Listing 14. Aktualizacja schematu bazy danych (C#) DatabaseSchemaUpdater dsu = DBContext.CreateDatabaseSchemaUpdater(); if (dsu.databaseschemaversion == 1) { dsu.addcolumn<productdescription>( PhotoContent ); dsu.databaseschemaversion = 2; dsu.execute(); 14 3/2013

15 WINDOWS PHONE 8 Adres isostore (Listing 10) wskazuje na tak zwany magazyn izolowany (ang. Isolated Storage). Jest to przestrzeń dyskowa w której aplikacja przechowuje swoje dane. Żadna inna aplikacja nie ma bezpośredniego dostępu do tej lokalizacji. Po uruchomieniu tego kodu baza zostanie założona. Żeby przekonać się, że wszystko przebiegło poprawnie możemy wykorzystać darmowe narzędzie o nazwie IsoStoreSpy dostępnej pod adresem: Pozwala on podłączyć się do emulatora i podejrzeć magazyn izolowany wybranej aplikacji. Z istniejącej bazy danych W sytuacji kiedy chcemy, żeby baza naszej aplikacji już na starcie była wypełniona inicjalnymi danymi możemy albo podczas zakładania bazy z kodu wypełnić ją danymi, albo przygotować plik bazy (plik godny z klasami opisanymi w klasie DBContext) w trakcie programowania, a następnie podczas instalowania wgrać go do wymaganej lokalizacji. Jeśli dla potrzeb naszej aplikacji wystarczy nam ba- Listing 15. Konwersja binarnych danych na onraz w klasie konwertera (C#) static readonly string NO_PHOTO = /Assets/NoPhoto.png ; public object Convert(object value, Type targettype, object parameter,system.globalization.cultureinfo culture) { if (value!= null && value is Binary && (value as Binary).Length > 0) { Binary bytesarray = value as Binary; using (MemoryStream memorystream = new MemoryStream(bytesArray.ToArray())) { var image = new BitmapImage(); image.setsource(memorystream); return image; else { var uri = new Uri(NO_PHOTO, UriKind.Relative); { BitmapImage image = new BitmapImage(uri); return image; Listing 16. Rozszerzenie bazy danych o nowe tabele (C#) if (dsu.databaseschemaversion == 2){ dsu.addtable<colors>(); dsu.addtable<productscolors>(); dsu.databaseschemaversion = 3; dsu.execute(); Listing 17. Definicja relacji pomiędzy tabelami w tabeli podrzędnej (C#) [Column] public int ProductID{ get; set; private EntityRef<ProductDescription> _Product; [Association(Storage = _Product, ThisKey = ProductID, IsForeignKey = true)] public ProductDescription Product{ get { return _Product.Entity; set { InvokePropertyChanging( Product ); _Product.Entity = value; InvokePropertyChanged( Product ); if (value!= null) this.productid = value.id; 15

16 za tylko do odczytu możemy dołączyć ją do projektu i oznaczyć jako Content. Plik oznaczone w ten sposób zostaną automatycznie przekopiowane podczas instalowania aplikacji. W takiej sytuacji connection string do bazy danych będzie wyglądac następująco: "Data Source = appdata:/ productdb.sdf ; File Mode = read only; Jeśli baza ma być dostępna zarówno do odczytu jak i do zapisu należy podczas instalowania przegrać ją do magazynu izolowanego. W tym celu plik bazy Rysunek 5. Docelowy schemat bazy danych danych, dołączony do projektu, oznaczamy jako Embedded Resource. W Listingu 11 rozszerzamy klasę ProductsDataContext o dodatkową metodę. Dodatkowo zmieniamy metodę EnsureData: (Listing 12). Aktualizacja bazy Jakąkolwiek metodę zakładania bazy danych wybierzemy może nastąpić potrzeba zmodyfikowania schematu bazy danych bez jednoczesnego usuwania danych wprowadzonych przez użytkownika. SDK WP8 udostępnia interfejs programistyczny do aktualizowania schematów baz danych. Każda baza danych jest oznaczona wersją. Jest to wartość przetrzymywana w tabeli systemowej. Na podstawie tej wartości możemy rozpoznać czy baza danych zainstalowana na urządzeniu wymaga aktualizacji. Aby przeprowadzić aktualizację musimy najpierw wprowadzić odpowiednie zmiany w klasach odpowiadających tabelom oraz, jeśli to wymagane, w klasie kontekstu. Do klasy dodajmy ProductDescription nową właściwość przechowującą informacje o zdjęciu dot. telefonu: Po wprowadzeniu tej zmiany w metodzie EnsureData sprawdzamy (Listing 13) w jakiej wersji jest teraz baza danych i jeśli jest w starszej zaktualizujemy ją (Listing 14). W ten sposób do tabeli została dodana nowa kolumna a wersja bazy została ustawiona na 2. Aby zdjęcia przypisane do telefonów wyświetlały się poprawnie zmodyfikujemy jeszcze klasę konwertera opisaną wcześniej (Listing 15). Relacje pomiędzy tabelami W ten sam sposób możemy rozszerzyć schemat bazy danych o dodatkowe tabele oraz zdefiniować relację pomiędzy tabelami (Listing 16). Listing 18. Definicja relacji pomiędzy tabelami w tabeli źródłowej (C#) private EntitySet<ProductsColors> _ProductsColors = new EntitySet<ProductsColors>(); [Association(Storage = _ProductsColors, OtherKey = ProductID )] public EntitySet<ProductsColors> ProductsColors { get { return _ProductsColors; set { InvokePropertyChanging( ProductsColors ); this._productscolors.assign(value); InvokePropertyChanged( ProductsColors ); Listing 19. Nawigacja do strony ze szczegółami wybranego produktu (C#) private void MainLongListSelector_SelectionChanged(object sender, SelectionChangedEventArgs e) { if (MainLongListSelector.SelectedItem == null) return; NavigationService.Navigate(new Uri( /ProductInfoPage.xaml?selectedItem= + (MainLongListSelector. SelectedItem as ProductDescription).ID, UriKind.Relative)); MainLongListSelector.SelectedItem = null; 16 3/2013

17 WINDOWS PHONE 8 Listing 20. Odczyt parametrów na stronie szczegółów produktu (C#) protected override void OnNavigatedTo(NavigationEventArgs e) { if (DataContext == null) { string selectedindex = ; if (NavigationContext.QueryString.TryGetValue( selecteditem, out selectedindex)) { currentitemid = int.parse(selectedindex); DataContext = App.ViewModel.Items. FirstOrDefault(elem => elem.id == currentitemid); Listing 21. Przykład użycia kontrolki ListPicker (XAML) <toolkit:listpicker ItemsSource= {Binding AvailableColors SelectionChanged= ColorPicker_ SelectionChanged > </toolkit:listpicker> Dodając nowe tabele należy pamiętać o dodaniu ich również do klasy kontekstu. Ponieważ telefony z systemem WP8 występują w różnych kolorach, na stronie stronie szczegółów telefonu umożliwimy wybór koloru telefonu i obejrzenie zdjęć telefonu w wybranym kolorze. Relacja pomiędzy tabelami przestawia poniższy diagram (Rysunek 5) Aby zdefiniować relacje pomiędzy tabelami musimy opisać odpowiednie właściwości w tabelach dodatkowymi atrybutami. W tabeli zawierającej klucze obce (czyli ProductColors na powyższym schemacie) do odpowiednich właściwości dodajemy poniższe atrybuty (Listing 17). W klasie źródłowej również tworzymy właściwość odpowiadającą relacji (Listing 18). Strona szczegółów Po kliknięciu w wybrany produkt na liście widoku głównego powinniśmy zostać przekierowani do widoku szczegółów. Widok ten nie istniej jeszcze w naszej aplikacji więc trzeba go dodać i oprogramować. Do projektu dajemy nową stronę o nazwie ProductInfoPage typu PanoramaPage. Jest to strona umożliwiająca przewijanie jej zawartości w poziomie na kilku podstronach. Aby umożliwić przejście do szczegółów produktu należy oprogramować zdarzenie wyboru pozycji na kontrolce listy (Listing 19). Wykonanie tego kodu spowoduje otwarcie strony ProductInfoPage.xaml z przekazaniem identyfikatora wybranego produktu. W kodzie strony szczegółów możemy odczytać identyfikator wybranego elementu i ustawić wybrany produkt jako kontekst strony (Listing 20). Po ustawieniu odpowiedniego kontekstu strony możemy zaprogramować wygląd strony korzystając z techniki wiązania analogicznie do widoku głównego strony. Dodatkowo, ponieważ chcemy dać możliwość wyboru koloru w którym prezentowane są zdjęcia, uzyjemy kontroli ListPicker dostępnej w zestawie dodatkowych kontrolek możliwych do pobrania ze stron CodePlex: Samo użycie kontrolki sprowadza się do ustawienia odpowiedniego wiązania (Listinng 21). Gdzie właściwość jest AvailableColors zwraca listę dostępnych kolorów powiązanych z aktualnym telefonem. Wymagania dotyczące publikowania Po zakończeniu prac nad aplikacją należy ją opublikować w sklepie z aplikacjami dla Window Phone. Aplikacja ta zostanie zweryfikowana pod względem zgodności z regułami zdefiniowanymi przez Microsoft. Spis wszystkich warunków, które musi spełniać aplikacja, wraz z testami które są przeprowadzane w celu weryfikacji, jest dostępny na: Reguły weryfikują różne aspekty działania aplikacji. Na przykład sprawdzany jest czas uruchomienia aplikacji. Reguła określa, że aplikacja powinna wyświetlić pierwszy ekran w ciągu 5 sekund od uruchomienia aplikacji. Jest możliwe, żeby pierwszym ekranem był ekran powitalny w formie grafiki o nazwie SplashScreenImage. jpg znajdującym się w głównym folderze aplikacji. W takiej sytuacji czas, w którym aplikacja musi być responsywna na działania klienta wydłuża się do 20 sekund. Jest to istotne np. w przypadku zakładania bazy danych. Michał Bakalarczyk Projektant aplikacji.net/sharepoint w Grupie Unity, gdzie od 6 lat współtworzy rozwiązania IT dla Klientów. 17

18 Firefox OS czy przełamie duopol ios i Android? Ostatnie wyniki badań International Data Corporation (IDC) wskazują jedno rynek mobilnych systemów operacyjnych, ze względu na ich popularność, jest ściśle podzielony. Zdecydowanym liderem jest Android, wyprodukowany przez Android Inc. (wykupioną później przez Google) udział w rynku mobilnych OS w pierwszym kwartale 2013 roku sięgnął 75%. Pozycję drugą zajmuje ios Apple a, z wynikiem 17%. Kolejne pozycje są właściwie marginalne Windows Mobile (3%), BlackBerry OS (2,9%) Skąd tak wysoka pozycja tych firm? Android jest najczęściej używaną platformą dla smartfonów na świecie stoi za tym przede wszystkim cena. Niskie koszty tworzenia, szeroka dostępność, mnogość aplikacji, sprawiły, że klienci często sięgają po to rozwiązanie. Również w środowisku programistycznym technologia ta jest popularna kod źródłowy jest dostępny, co powoduje, że nowe aplikacje i możliwości systemu są szybko i łatwo tworzone, a co ważniejsze, nie potrzebują oficjalnych kanałów dystrybucji. ios reklamuje siebie jako najbardziej zaawansowany mobilny system operacyjny na świecie - przyjazny interfejs, fenomenalna funkcjonalność i niezachwiana stabilność - to cechy, które powinny rekompensować także wysoki koszt urządzeń. Posiadanie takowego, to w niektórych środowiskach niemal prestiż. Programowanie z użyciem Objective-C obwarowane jest jednak kilkoma warunkami, jak np. rejestracja w programie developerskim Apple czy system rocznych opłat (jeśli chcesz zamieścić aplikację w sklepie). Czy w tak podzielonym świecie jest możliwe miejsce dla nowego gracza? Czy ktoś będzie mógł zastąpić obecnych liderów? Tego zadania podjęła się Mozilla, wypuszczając na rynek swój najnowszy produkt Firefox OS. Próby detronizacji podejmowane były wcześniej pojawiły się open source owe Sailfish OS, Buntu Otuch, Tizen. Wszystkie one przesyły jednak bez echa. Czy teraz będzie podobnie? Wygląda na to, że jest szansa na zmianę lidera. Firefox OS, zgodnie z założeniem Telefonica Digital oraz Mozilli, ma zdemokratyzować i rozbić obecny układ technologii mobilnych. Ma być systemem całkowicie opensouroce owym, który nie wymaga do uruchomienia wielu nakładów i bez problemu może współpracować z każdą siecią. Sam system traktuje sieć jako platformę - jest to nowe rozwiązanie, które może pozwolić wejść Firefox do świata technologii mobilnych niekoniecznie jako jedna z nich. Firefox OS zbudowany jest na technologiach webowych opartych na lekkim, Linuxowym systemie operacyjnym. Każda aplikacja, włączając w to np. kamerę jest aplikacją webową - budowaną z użyciem standardów HTML5, CSS3 i JavaScript. Jego Interface przypomina interface Androida sami twórcy nie ukrywają, że to rozwiązanie było dla nich inspiracją. Aplikacje w nim stworzone działają jako Web apps na wszystkich urządzeniach, na których funkcjonuje przeglądarka Firefox (Android, Windows 8). Prostota wykonania, tania produkcja i łatwość adaptacji może spowodować, że Firefox OS wywyło sporo zamieszania na rynku. System jest banalnie prosty w obsłudze, nie wymaga od użytkownika tworzenia setek kont, rejestracji, konfiguracji, dzięki temu telefon jest konkurencyjny (pod względem ceny oraz wydajności) z innymi smartfonami w tej samej klasie. Pierwsza prezentacja w lutym 2012 roku zrobiła duże zamieszanie i była szeroko komentowana. System początkowo funkcjonował na smartfonach współpracujących z Androidem. W styczniu 2013 roku nawiązała się współpraca z ZTE, który zapowiedział wydanie telefonów z Firefox OS. Do współpracy włączył się takżę Alcatel. Pierwsze telefony w dystrybucji pojawiał się w lipcu 2013 w Hiszpani, Wenezueli, Kolumbii i Polsce (za sprawą T-Mobile i Alcatel One Touch Fire). W dalszych planach jest Ameryka Południowa, Niemcy, Norwegia, Węgry, Grecja i Stany Zjednoczone. Czy Firefox OS ma szansę z tuzami na rynku? Czy zastąpi Androida? System jest nadal w fazie rozwoju, po kilku miesiącach funkcjonowania producenci zapowiedzieli pierwsze rozszerzenia, a opinie i wrażenia były pozytywne. Przyszłość pokaże, czy Mozilla wykorzysta szansę i ogromny kredyt zaufania, jaki otrzymała na starcie. Piotr Wirkus Piotr Wirkus jest konsultantem HAYS odpowiedzialny za rozwój dywizji IT & Telecoms w gdańskim biurze Hays Poland. Realizuje projekty średniego i wyższego szczebla na terenie województw: pomorskiego, kujawsko-pomorskiego oraz warmińsko-mazurskiego. Koordynuje również projekty obejmujące prace konsultantów w kilku biurach. By być bliżej branży, sam również uczy się programowania. Piotr od wielu lat związany jest z branżą HR. Doświadczenie zdobywał w firmach doradczych, gdzie zajmował się rekrutacjami na stanowiska średniego i wyższego stopnia oraz uczestniczył aktywnie w rekrutacjach międzynarodowych. Zanim związał się z branżą HR przez kilka lat zajmował się sprzedażą detaliczną w sieciach multimedialnych oraz w wydawnictwie. Ukończył Politologię na Uniwersytecie Gdańskim oraz studia podyplomowe Zarządzanie Personelem przy Szkole Wyższej Psychologii Społecznej 18 3/2013

19

20 Zdalne aplikacje mobilne rozwiązanie problemu wielo-platformowości? Różnorodność mobilnych systemów operacyjnych i urządzeń powoduje, że każdy twórca aplikacji mobilnych staje przed dylematem na jakie platformy przygotować aplikację aby dotrzeć do jak największej grupy użytkowników, a jednocześnie nie rozbić budżetu. Na szczęście wybór między wieloma aplikacjami natywnymi, a uniwersalną aplikacją webową to nie jedyna opcja! DOWIESZ SIĘ Jakie są możliwe metody przygotowania aplikacji mobilnych na wiele platform. Że czas reakcji aplikacji na interakcje użytkownika nie zawsze pogarsza sie wraz z przeniesieniem przetwarzania na serwer. Jaka jest proporcja kosztów przygotowania wielo-platformowych aplikacji mobilnych w oparciu o różne metody. O ile przygotowywanie aplikacji mobilnej na dwa lub trzy najpopularniejsze systemy operacyjne nie stwarza wielkich problemów jest coraz więcej firm oferujących takie usługi, a ceny konsekwentnie maleją o tyle zaadresowanie długiego ogona systemów operacyjnych stanowi już nie lada wyzwanie. Polscy operatorzy telekomunikacyjni oferują smartfony działające pod kontrolą co najmniej 7 systemów operacyjnych: Android, ios, Windows Phone, BlackBerry OS, Symbian, Samsung Bada i Firefox OS. Za chwilę na rynku pojawią się kolejne: Tizen, Ubuntu Touch OS, Jolla Sailfish OS i inne. Jeśli aplikacja ma być dostępna dla wszystkich użytkowników, to powinna być przygotowana na każdy z tych dziesięciu POWINIENEŚ WIEDZIEĆ Na czym polega architektura klient-serwer. Jakie są ograniczenia przeglądarek WWW w kontekście przygotowania aplikacji mobilnych. systemów operacyjnych. Przygotowanie tylu aplikacji natywnych jest zbyt kosztowne, a opracowanie jednej uniwersalnej aplikacji webowej może być co najmniej kłopotliwe. Zdalna aplikacja mobilna Inną opcją, która potencjalnie łączy zalety obu rozwiązań, jest zdalna aplikacja mobilna. Jest to aplikacja działająca na serwerze, której tylko interfejs użytkownika jest dostarczany do urządzenia mobilnego. Interfejs użytkownika jest odtwarzany na urządzeniu przez uniwersalnego klienta aplikacji zdalnej natywny komponent aplikacji zdalnej instalowany na urządzeniu mobilnym. Z pozoru jest to taka sama architektura jak w przypad- Rysunek 1. Architektura zdalnej aplikacji mobilnej 20 3/2013