Koncepcja Windows Phone 7 w porównaniu do Windows Mobile 6 i innych systemów mobilnych « Pabloware + Windows Phone

Pabloware + Windows Phone

Niezależny blog firmy Pabloware o systemie Windows® Phone 7

Koncepcja Windows Phone 7 w porównaniu do Windows Mobile 6 i innych systemów mobilnych

Biblioteka Silverlight

Windows Phone 7 już od pierwszego wrażenia znacznie różni się od swego poprzednika, co wynika z obranego profilu użytkownika końcowego i koncepcji jego pracy z systemem, a ma swoje głębsze konsekwencje technologiczne. Spróbujmy zrozumieć, z czego dokładnie te konsekwencje wynikają.

Zacznijmy od tego, że poprzednia wersja została od początku zaprojektowana dla urządzeń z ekranem opornościowym (reagującym na dotyk pojedynczego rysika), podczas gdy nowa wersja przeznaczona jest wyłącznie dla urządzeń z ekranem pojemnościowym (potrafiącym rozpoznać dotyk wielu palców).

Oczywista różnica z tego wynikająca, to konieczność zapewnienia obsługi nowych zdarzeń interakcji z interfejsem użytkownika, bowiem ekran pojemnościowy pozwala na wykonanie gestów, takich jak np. powiększanie dwoma palcami. Ponadto elementy interaktywne na ekranie i odległość między nimi muszą być odpowiednio większe, aby obsługa palcem była równie precyzyjna, jak obsługa rysikiem, znanym ze starszej wersji systemu mobilnego. Także sposób odpowiedzi interfejsu użytkownika na bodźce powinien być bardziej dynamiczny, bo bardziej dynamiczna jest swobodna praca z ekranem pojemnościowym, niż praca z rysikiem.

Chociaż widać już pierwsze różnice wprowadzane przez nowy system, to zasadne mogłoby się wydawać utrzymanie pełnej zgodności z narzędziami dla programistów przeznaczonymi dla Windows Mobile 6. Konieczne byłoby dodanie jedynie kilku nowych kontrolek i zdarzeń do istniejących kontrolek, aby zapewnić obsługę wielodotyku. Uczynili tak np. autorzy Delphi, wprowadzając do wersji 2010 obsługę wielodotyku w znanej bibliotece wizualnej VCL.

Wydaje się jednak, że dla twórców Windows Phone 7 kluczowa była chęć zmiany profilu użytkownika końcowego systemu mobilnego z biznesowego na indywidualno-biznesowego, a co za tym idzie uczynienia interfejsu użytkownika bardziej atrakcyjnym dla tych osób. Sposób, w jaki firma Microsoft rozumie tę atrakcyjność, nie jest oczywiście przedmiotem tego wpisu, można jedynie zasygnalizować, że wraz z systemem Windows Phone 7 zaproponowano nowy język wizualny komunikacji z użytkownikiem – nazwany Metro UI (nazwa ta inspirowana jest językiem wizualnym komunikacji miejskiej). Najkrócej rzecz ujmując, sprowadza się on do „minimalistycznej” w formie grafiki, nieprzypominającej niczym interfejsu biurkowego Windows (ani Windows Mobile 6, który z biurkowego Windows się wywodzi) – połączonej z relatywnie dużą ilością animacji, która „wynagradza” minimalizm grafiki.

Z tego punktu widzenia słuszna wydaje się zmiana głównej technologii interfejsu użytkownika na omawianą za chwilę bibliotekę Silverlight, która z sukcesem rozwijana jest od 2007 roku i stanowi obecnie najciekawszą propozycję tej firmy w zakresie programowania interfejsów użytkownika, daleko wykraczającą poza dotychczas proponowane przez Microsoft rozwiązania. Choć trzeba zaznaczyć, że prym ten wiedzie razem z podobną do niej, lecz przeznaczoną na biurkowy system Windows i z tego powodu będącą jej (w pewnym uproszczeniu) nadzbiorem, biblioteką WPF (Windows Presentation Foundation), która ze względu na nowatorskość, obecnie jest jeszcze relatywnie mało wykorzystywana w praktyce.

Biblioteka Silverlight, jaką znaliśmy przed premierą Windows Phone 7, jest dostępną na komputery z systemami Windows i Mac OS wtyczką do przeglądarki internetowej, pozwalającą uruchamiać bogate w animacje aplikacje, podobnie jak Adobe Flash, jednak z różnicami pod względem możliwości i intencji użycia. Jej pierwotne miejsce przeznaczenia (wtyczka przeglądarki) może wydawać się skrajnie różne od aplikacji telefonu komórkowego, kiedy weźmiemy jednak pod uwagę fakt, że biblioteka Silverlight jest kompletnym środowiskiem uruchomieniowym aplikacji, zamkniętym w niewymagającej wiele miejsca postaci, nakierowanym od początku na multimedialność oraz nieobciążonym charakterystyką interfejsu użytkownika biurkowego systemu Windows, to zacznie nam się wydawać adekwatna do zamierzonego kształtu systemu.

Oczywiście nie jest to dokładnie ta sama biblioteka Silverlight, co we wtyczce do przeglądarki, ale z punktu widzenia jej użytkownika – programisty – niewiele się od niej różniąca. Jest to mianowicie biblioteka Silverlight w wersji 3 (lub 4 w Windows Phone 7.1) wzbogacona głównie o API obsługi telefonu i optymalizacje wydajnościowe, spowodowane ograniczoną mocą obliczeniową telefonu komórkowego, w porównaniu do komputera biurkowego. Jedyna w API różnica o powszechnym znaczeniu, wynika z tych optymalizacji i dotyczy wielowątkowości animacji, więc zmiany zostały ograniczone do minimum.


Należy zaznaczyć, że powyższej genezy przejścia na technologię Silverlight nigdy firma Microsoft (o ile autorowi wiadomo) nie przedstawiła. W związku z tym geneza ta została autorsko wyprowadzona z cząstkowych informacji udostępnianych przez producenta i jako subiektywna obarczona jest ryzykiem.

Z punktu widzenia innowacyjności interfejsu użytkownika, nowy system z jednej strony korzysta z wypracowanych przez firmę Apple (pioniera użycia ekranu pojemnościowego) szczegółowych rozwiązań – np. zastosowanie gestu przewijania w kontrolkach wyboru daty. Jednak z drugiej strony firma Microsoft w nowym systemie mobilnym odchodzi od swojego systemu biurkowego dalej niż zrobiła to firma Apple, wprowadzając niestosowane przez konkurenta podejście. W związku z tym jest to innowacja, ale trzeba przyznać, że bazująca na fundamentach wypracowanych przez firmę Apple.

Biblioteka XNA

Omówienie technologii interfejsu użytkownika nowego systemu mobilnego nie byłoby kompletne, gdybyśmy nie wspomnieli o znanej z konsoli do gier Xbox biblioteki XNA. Jest ona dostępna na Windows Phone 7 równolegle z biblioteką Silverlight, jednak służy do pisania gier i aplikacji stricte multimedialnych.

W obecnej wersji systemu nie można łączyć na ekranie elementów interfejsu pochodzących z obu bibliotek, ale zmieni to się w Windows Phone 7.1. Można natomiast korzystać z API pomocniczych obu bibliotek w jednej aplikacji, co jest korzystne, bo oba API uzupełniają się.

Wymagania sprzętowe

Dużą zmianą, w stosunku do systemu Windows Mobile 6 jest określenie przez firmę Microsoft bardzo szczegółowych wymagań sprzętowych, które muszą zostać spełnione przez producentów telefonów, aby ich produkty mogły być wyposażone w nowy system. Jest to ułatwienie dla programistów, bo umożliwia skupienie się na spójnej konfiguracji sprzętowej, na której będzie działać aplikacja – zapewniając jej z nią kompatybilność.

Warto zauważyć, że takie stanowisko dotyczące sprzętu jest pośrednim między skrajnymi stanowiskami dwóch, jak się wydaje najważniejszych na tym rynku, konkurentów firmy Microsoft. Z jednej strony firma Apple jest wyłącznym producentem jedynego w danej generacji modelu telefonu komórkowego, dedykowanego swojemu systemowi mobilnemu, więc umożliwia programistom zoptymalizowanie aplikacji, w pełni dla tego modelu. Z drugiej strony firma Google nie narzuca w praktyce żadnych wymagań sprzętowych (są one bowiem bardzo niskie, więc traktowane symbolicznie) – co przypomina sytuację systemu Windows Mobile 6 i znacznie utrudnia zapewnienie przez programistów kompatybilności aplikacji z wszystkimi urządzeniami, na których można zainstalować dany system operacyjny.

Wydaje się, że stanowisko dotyczące wymagań sprzętowych Windows Phone 7 koresponduje z opisaną, na początku tego wpisu, chęcią zmiany profilu użytkownika końcowego systemu, bowiem użytkownicy indywidualni mają z reguły mniejszą, niż użytkownicy biznesowi, możliwość uzyskania dedykowanych dla swych urządzeń aplikacji, jak również uzyskania szybkiej pomocy technicznej, stąd konieczność zapewnienia spójnej i bardziej niezawodnej platformy sprzętowej.

Znaczące, z programistycznego punktu widzenia, obligatoryjne wymagania sprzętowe Windows Phone 7 to:

  • System-on-a-chip Snapdragon z procesorem Scorpion o zestawie instrukcji ARMv7 i zegarze 1 Ghz oraz z procesorem karty graficznej zdolnym do akceleracji DirectX 9 (w przypadku Windows Phone 7.1 możliwa jest również nowsza wersja tego SoC z zegarem 800 Mhz, lecz równie wydajna, bądź też wersja szybsza z zegarem 1 Ghz – w obu przypadkach są to SoC ze zaktualizowanym GPU) – do dyspozycji aktywnej aplikacji jest 90% czasu procesora;
  • minimum 256 MB pamięci RAM, z czego aktywna aplikacja otrzymuje 90 MB
    (w wersji 7.1, w zależności od ilości wolnej pamięci, będzie mogło to być więcej), przy czym wszystkie aktualnie obecne na rynku telefony z Windows Phone 7 dysponują 512 MB pamięci RAM;
  • przynajmniej 8 GB pamięci flash (każda aplikacja ma do dyspozycji maksymalnie 2 GB, co wynika z architektury systemu);
  • trzy przyciski sprzętowe służące do sterowania systemem: wstecz, start i szukaj (dla aplikacji obecnie dostępny jest tylko przycisk wstecz, natomiast przycisk szukaj zostanie udostępniony w wersji 7.1) oraz trzy przyciski sprzętowe typowe dla wszystkich telefonów komórkowych: głośność, aparat i włącz/odblokuj;
  • wysoka, jak na telefon komórkowy rozdzielczość ekranu 480×800 (do pewnego momentu dopuszczana była niższa rozdzielczość 320×480, ale ostatecznie
    nie pojawiły się urządzenia z tą rozdzielczością i obecnie Microsoft rekomenduje programistom koncentrowanie się wyłącznie na wyższej rozdzielczości);
  • ekran pojemnościowy musi potrafić jednocześnie wykrywać minimum cztery punkty dotyku, w związku z tym możliwe jest operowanie czterema palcami jednocześnie, co stwarza możliwość kreacji nowych gestów sterowania aplikacjami, jak również dostępna jest gotowa biblioteka, umożliwiająca wykrywanie standardowych gestów;
  • obecne muszą być następujące czujniki: AGPS, przyspieszeniomierz, kompas (którego API zostanie wprowadzone dopiero w wersji 7.1 systemu) oraz czujnik zbliżeniowy i czujnik światła (oba nie są obecnie dostępne poprzez API systemu);
  • aparat fotograficzny z lampą błyskową i kamera o matrycy minimum 5 megapikseli (w wersji 7.0 aplikacje mają do dyspozycji tylko API robienia zdjęć, ale w wersji 7.1 dodany ma być dostęp do bieżącego strumienia kamery, co umożliwi konstruowanie aplikacji z dziedziny rzeczywistości rozszerzonej);
  • wibracja i radio FM.

Opcjonalne zalecenia sprzętowe o znaczeniu dla programistów są następujące:

  • podczas projektowania systemu, firma Microsoft oczekiwała wyboru przez producentów telefonów wyświetlaczy klasy OLED, jako słabiej zużywających baterie, niż wyświetlacze LCD, gdy znaczna część ekranu jest czarna, a jest to domyślny kolor tła ekranów systemowych Windows Phone 7 – ostatecznie jednak na rynku obecne są urządzania obu rodzajów, więc zdaniem autora nie zawsze zastosowanie czarnego koloru tła przyniesie korzyść użytkownikom, aczkolwiek w aplikacjach codziennego użytku warto stosować domyślne kolory i wybór pozostawić użytkownikowi, który może wybrać biały kolor tła w ustawieniach systemu;
  • telefony mogą posiadać klawiaturę sprzętową, przy czym dostępna jest oczywiście klawiatura ekranowa (SIP, ang. Software Input Panel), która dostosowuje swój układ w zależności od rodzaju wprowadzanych informacji – np. adres internetowy (zdecydowana większość aktualnie obecnych na rynku telefonów klawiatury sprzętowej nie posiada);
  • od wersji 7.1 producenci będą mogli opcjonalnie wyposażać swoje urządzenia w żyroskop, który będzie od tej wersji systemu dostępny dla aplikacji.

No Responses to “Koncepcja Windows Phone 7 w porównaniu do Windows Mobile 6 i innych systemów mobilnych”

Kanał RSS z komentarzami do tego wpisu. TrackBack URL

Leave a Response