Zdecydowana większość dodatkowych czynności, jakie należy podjąć budując aplikacje pod system Windows Phone 7 (podobnie jak pod inne systemy mobilne) związana jest z wydajnością tych aplikacji. Spowodowane jest to oczywiście ograniczoną mocą procesora telefonu komórkowego. Ważne jest również jak najmniejsze zużywanie baterii, na co ma wpływ m.in. stopień obciążenia procesora. We wpisie tym czytelnik pozna podstawowe zasady, jakimi należy kierować się, aby wydajność tworzonych aplikacji była jak najlepsza, a zużycie baterii było jak najmniejsze.

Omówione zostaną także szczególne aspekty, które są związane z interfejsem użytkownika.

Poprawa szybkości ładowania kodu i zasobów aplikacji

W przypadku średniej wielkości i dużych aplikacji, poprawienie ich szybkości ładowania do pamięci może być uzyskane poprzez podział aplikacji na kilka plików DLL. Możliwe są tu dwie strategie. Pierwszą z nich jest podział dużych aplikacji na pliki DLL odpowiadające poszczególnym częściom aplikacji i ładowane ich w miarę potrzeby. Drugą, adekwatną w przypadku średniej wielkości aplikacji możliwością, jest umieszczenie rzadko używanych elementów (np. stron opcje i o programie) w osobnym pliku DLL, a całej reszty aplikacji w innym pliku DLL. Bardzo małe aplikacje oczywiście znikomo zyskają na takim podziale.

Trzeba zaznaczyć, że powyższa porada dotyczy ładowania kodu samej aplikacji, a nie danych aplikacji. Wszelkie dystrybuowane z aplikacją pliki danych i np. zasoby multimedialne powinny być oznaczone w pliku projektu jako Content, a nie jako Resource. Tak oznaczone pliki nie będą weryfikowane pod kątem podpisu cyfrowego generowanego przez usługę Marketplace (nie będą nawet umieszczone w pliku XAP aplikacji [sic!]), co spowoduje szybsze ładowanie aplikacji, szczególnie za jej pierwszym uruchomieniem.

Gdy aplikacja ze względu na ładowanie zasobów potrzebuje więcej niż sekundę, aby pokazać pierwszą stronę, firma Microsoft zaleca pokazanie ekranu splash screen (domyślnie zresztą zawartego w każdym nowym projekcie), choć z drugiej strony zalecane jest też utrzymanie ciągłości przejścia między systemem i aplikacjami w wymiarze interfejsu użytkownika. W praktyce więc, korzystne jest załadowanie takiej liczby zasobów, żeby możliwe było pokazanie początkowego stanu pierwszej strony aplikacji zawierającego np. animację ładowania pozostałych zasobów. Tym samym ekrany splash screen okazują się rzeczywiście przydatne tylko, kiedy takie częściowe ładowanie nie jest z różnych względów możliwe.

Skrupulatne podejście do wydajności podczas programowania

Modny obecnie paradygmat odwrócenia sterowania jest przykładem techniki, która choć jest bardzo pożyteczna, podczas tworzenia dużych aplikacji (np. webowych), to intensywnie stosowana w aplikacjach na telefon komórkowy może doprowadzić do zbyt małej ich wydajności.

Innym przykładem ułatwienia w programowaniu, które na telefonie komórkowym w mniejszym lub większym stopniu nie jest korzystne, z powodu wydajności, jest korzystanie z mechanizmów wiązania danych (ang. binding) z kontrolkami interfejsu użytkownika w technologii Silverlight, co jest oczywiście wolniejsze od ręcznego przepisywania danych do interfejsu użytkownika, w kodzie aplikacji.

Dodatkowym spowolnieniem podczas wiązania danych z kontrolkami interfejsu użytkownika jest korzystanie ze zautomatyzowanych konwerterów (np. popularny konwerter Silverlight służy do zmiany wartości logicznej na typ wyliczeniowy, używany przez kontrolki do określenia ich widoczności). Konwertery takie są z powodzeniem stosowane, w celu uproszczenia kodu, w aplikacjach Silverlight lub WPF przeznaczonych na komputery biurkowe, ale na telefonach komórkowych, powodowane przez nie spowolnienie, jest już odczuwalne przez użytkownika, jeśli np. są stosowane w listach. Rozwiązaniem jest oczywiście ręczna konwersja wartości w kodzie, przed dowiązaniem lub przepisaniem ich do kontrolek.

Kolejnym, związanym z technologią Silverlight, wrażliwym punktem wydajności jest korzystanie z rozbudowanych szablonów kontrolek. W najgorszym przypadku elementy tych szablonów mogą posiadać zapętlające się współzależności renderowania (np. dotyczące rozmiaru), które będą dodatkowo spowalniać renderowanie strony. Najlepiej jest stosować jak najprostsze szablony kontrolek, o stałych rozmiarach, określając ten rozmiar na sztywno. Gdy zaś potrzeba zastosować bardziej skomplikowane szablony, można je zamknąć jako osobne kontrolki, w najlepszym przypadku nie korzystające z wiązania danych. Stosowanie kontrolek zamiast wiązania danych komplikuje implementację, ale powoduje wzrost wydajności.

Wymienione w tym punkcie optymalizacje sprowadzają się do rezygnacji z najbardziej kosztownych wydajnościowo ułatwień w budowaniu aplikacji i zarządzaniu kodem, na rzecz własnych rozwiązań. Jest to często konieczna czynność, aby uzyskać zadowalającą szybkość aplikacji na telefonie komórkowym, choć oczywiście nie znaczy to, że jest to czynność wystarczająca.

Opóźnione ładowanie danych

Zalecane przez firmę Microsoft jest nie ładowanie żadnych danych, podczas konstruowania stron Silverlight z kodu XAML, ponieważ konstruowanie to samo w sobie jest kosztowne czasowo. Poprawnym w związku z tym sposobem postępowania ma być odczekanie do wystąpienia odpowiedniego zdarzenia, oznajmiającego o skonstruowaniu wszystkich elementów wizualnych strony (LayoutUpdated) i dopiero potem dokonanie czasochłonnego ładowania danych. Spowoduje to, że użytkownik relatywnie szybko zobaczy stronę, na którą zostaną następnie załadowane dane, zamiast długo oczekiwać na pokazanie się strony.

Być może czytelnik zgodzi się, że możliwe wydaje się rozwinięcie powyższej idei i w przypadku statystycznych stron o niezmiennym podczas konstruowania z kodu XAML układzie wizualnym, udostępnienie jakiejś formy ich prekompilacji (w zasadzie hibernacji), aby skrócić czas konstruowania. Przypominałoby to per analogiam możliwość oznaczania klas, z których nie można dziedziczyć, jako sealed w języku C#, co powoduje, że nie są już dla tych klas szukane nadpisania metod wirtualnych i w związku z tym poprawiona jest szybkość wywołań tych metod. Prekompilowane strony mogłyby być modyfikowane wyłącznie po całkowitym załadowaniu, ale taki schemat postępowania i tak jest obecnie zalecany, więc z punktu widzenia autora aplikacji korzystającego z gotowych, odpowiednio przygotowanych kontrolek XAML, koszt takiego rozwiązania byłby niewidoczny, a strony byłyby konstruowane szybciej.

Oczywiście wyrażoną na początku tego punktu zasadę opóźnionego ładowania danych na stronę można uogólnić i zastosować na wszystkie składniki strony z osobna, a nie tylko na stronę jako całość. W ten sposób można ładować poszczególne dane dopiero, kiedy użytkownik przejdzie do takiego miejsca na stronie, w którym dane te są potrzebne. Przykładowym miejscem zastosowania są tu strony przewijane w pionie lub poziomie, jak również strony pokazujące okna wyskakujące, a może nawet listy rozwijane.

Minimalizacja użycia wątku interfejsu użytkownika

Wątek interfejsu użytkownika nie powinien być nigdy zablokowany długotrwałą pracą, bo jego najważniejszym zadaniem jest odpowiadanie na interakcje użytkownika z aplikacją. Kiedy np. użytkownik naciśnie przycisk powodujący jakąś długotrwałą czynność, interfejs użytkownika nie powinien zostać zablokowany. Jednym ze sposobów uzyskania takiego efektu, gdy do wykonania jest długotrwała praca po stronie aplikacji, jest zlecenie pracy do wątku działającego w tle. Nie jest to niczym nietypowym również w przypadku programowania na biurkowej wersji Windows, ale ponieważ procesor telefonu komórkowego ma słabsze możliwości, do blokowania wątku interfejsu użytkownika dochodzi na nim znacznie łatwiej, stąd konieczność zlecania pracy do wątku tła występuje częściej.

Taki sposób postępowania będzie przypuszczalnie przynosić korzyści także w Windows Phone 7.1, w którym obsługa dotyku zostanie przeniesiona, z wątku interfejsu użytkownika, do wątku Kompozytora (co ma poprawić czas reakcji kontrolek na dotyk), bowiem wątek interfejsu użytkownika, jako główny wątek aplikacji, przypuszczalnie nadal będzie jedynym wątkiem, zdolnym ostatecznie odpowiedzieć na interakcję użytkownika z aplikacją, np. inicjując jakąś logikę biznesową. Poza tym do wątku interfejsu użytkownika należy obecnie też m.in. rysowanie elementów wizualnych po raz pierwszy, a można sobie wyobrazić, że może nastąpić to podczas wykonywania intensywnej pracy przez aplikację, w wyniku przewinięcia w tym czasie strony przez użytkownika.

Postrzegany czas odpowiedzi

Ważną cechą interfejsu użytkownika w środowisku o ograniczonej wydajności, jest zdolność do natychmiastowej odpowiedzi na bodźce użytkownika. W systemie Windows Phone 7 mocno akcentowane są animacje, więc jest to najbardziej oczywista forma odpowiedzi. Można np. wyświetlić animację ładowania strony lub okna wyskakującego, jeśli czynność ta będzie czasochłonna, aby zmniejszyć postrzegany czas odpowiedzi, czyli czas, po którym użytkownik może najpóźniej otrzymać odpowiedź, przy czym może to być także odpowiedź informująca jedynie, że należy czekać, a czas ten nie powinien przekraczać jednej sekundy.

Innym sposobem odpowiedzi, jest uruchomienie wibracji na 100 ms, czyli na najkrótszy możliwy czas, jako odpowiedzi na naciśnięcie przycisku, przed pokazaniem okna wyskakującego. Oczywiście ten sposób odpowiedzi nie powinien być nadużywany, a czas wibracji powinien być krótki, w przeciwnym wypadku użytkownik może potraktować go jako sygnał błędu.

Odpowiednia wielkość aktywnych elementów interfejsu użytkownika

Elementy interfejsu użytkownika, które można nacisnąć palcem, powinny być na tyle duże, aby nie zdarzało się często przypadkowe naciśnięcie niewłaściwych elementów. Jest to oczywiście implikacja użycia pojemnościowego ekranu dotykowego.

Przyjmuje się, że elementy te nie powinny być mniejsze, niż kwadrat o bokach 9 mm (ok. 34 pikseli) lub wyjątkowo 7 mm (ok. 26 pikseli) i nie powinny znajdować się bliżej siebie, niż w odległości 2 mm (ok. 8 pikseli).

Wybór właściwej klawiatury ekranowej

Jak wspomniano już w tym wpisie, znacząca większość obecnych na rynku telefonów z systemem Windows Phone 7 nie posiada klawiatury sprzętowej, więc jedynym na nich sposobem wprowadzania znaków jest klawiatura ekranowa (SIP).

System Windows Phone 7 pozwala ustalić (poprzez właściwość InputScope), jakiego rodzaju klawiatura będzie wyświetlana użytkownikowi, podczas wprowadzania znaków do konkretnego pola tekstowego. Dostępnych jest 10 podstawowych rodzajów SIP i różnią się one od siebie nie tylko dostępnością i układem klawiszy, ale także funkcjami takimi jak słownik i automatyczna wielka litera na początku. Wybór właściwej SIP z pewnością przyspiesza wprowadzanie danych, więc warto ustalić SIP dla każdego pola tekstowego.

Architekturę systemu operacyjnego Windows Phone 7 można z punktu widzenia budowania aplikacji pod ten system podzielić na kilka podstawowych obszarów, które zostaną omówione w tym wpisie.

Jądro

Jądro Windows Phone 7 bazuje na jądrze Windows CE 6.0, w stosunku do którego zostało wzbogacone m.in. o stronicowanie pamięci oraz o warstwy bezpieczeństwa, sieci i przechowywania danych. W jego skład wchodzą także sterowniki do wymienionych w poprzednim wpisie czujników telefonu oraz do multimediów i Wi-Fi.

Model aplikacji

Model aplikacji Windows Phone 7 cechuje:

• znany z technologii Silverlight i XNA format pliku XAP, zawierający całą aplikację (są to pliki DLL oraz manifest i zasoby, w tym ikona aplikacji, skompresowane w formacie ZIP);
• licencjonowanie z wykorzystaniem usługi Marketplace (użytkownik końcowy nie może zainstalować aplikacji inaczej, niż poprzez usługę Marketplace, aczkolwiek w wersji 7.1 za jej pośrednictwem można będzie dystrybuować aplikacje także do zamkniętego kręgu odbiorców), ponadto kod każdej aplikacji (oczywiście skompilowany do pośredniego języka Common Intermediate Language, CIL platformy .NET) jest przed jej umieszczeniem w usłudze Marketplace sprawdzany przez firmę Microsoft, a następnie podpisywany cyfrowo;
• aktualizacje aplikacji zawsze zatwierdzane przez użytkownika w usłudze Marketplace, chociaż poza tym będące całkowicie zautomatyzowane;
• izolacja każdej aplikacji w piaskownicy, przy czym autorzy systemu używają terminu „komora”, ang. chamber – są, bowiem cztery typy komór, a aplikacje (pochodzące spoza firmy Microsoft) znajdują się w komorach o najmniejszych przywilejach (LPC, ang. Least Privileged Chamber) co oznacza, że każda aplikacja nie ma dostępu do plików każdej innej aplikacji (oczywiście poza swoimi), zarówno jeśli chodzi o pliki uruchomieniowe, jak i pliki danych (ani używanej przez nią pamięci operacyjnej), nie ma także dostępu do plików systemu operacyjnego, co ma zapewnić bezpieczeństwo;
• w wersji 7.1 zapowiadana jest możliwość współdzielenia danych między aplikacjami za potwierdzeniem użytkownika, ale w praktyce na razie ma to być jedynie odczyt danych z dwóch aplikacji systemowych: kontaktów i kalendarza, więc jedynym miejscem integracji danych pozostaje chmura.

Model interfejsu użytkownika

Model interfejsu użytkownika Windows Phone 7 dziedziczy po sieci WWW sposób nawigacji w historii pomiędzy stronami aplikacji (za co odpowiedzialna jest warstwa powłoki systemu), z zastrzeżeniem, że nie jest możliwe przechodzenie wprzód w historii, można się tylko cofać. Związany z tym sposób przechodzenia między aplikacjami ma zapewnić wrażenie spójności aplikacji i systemu operacyjnego. Ponadto podzielenie funkcjonalności aplikacji na niewielkie obszary (strony) umożliwia, bardziej adekwatne do możliwości, dysponowanie ograniczonymi zasobami telefonu komórkowego.

Pomocny w takim sposobie nawigacji jest wątek Kompozytora (ang. Composer). Jest to wątek o wysokim priorytecie, odpowiedzialny za rendering (choć w wersji 7.1 odpowiadać będzie także za obsługę dotyku, co ma przyspieszyć czas reakcji telefonu na dotyk). Ten wspólny wątek renderingu umożliwia tworzenie płynnych animacji przejść między aplikacjami i ponieważ jest niezależny od głównego wątku aplikacji (zwanego wątkiem interfejsu użytkownika), zapewnia płynność raz uruchomionych animacji w aplikacjach.

Wątek Kompozytora (podobnie jak cały system) do renderingu wykorzystuje procesor karty graficznej, bo jak wspomniano w poprzednim wpisie, do minimalnych wymagań sprzętowych systemu należy GPU zgodny z DirectX 9. Zdaniem autora, niesie to oczywiście tę samą korzyść, jak na komputerach PC, na których wykorzystanie GPU pozwala odciążyć CPU. Jest to szczególnie istotne, jeśli weźmiemy pod uwagę, że na telefonach komórkowych czas CPU jest jeszcze cenniejszy.

Integracja z chmurą

System Windows Phone 7 w odróżnieniu od Windows Mobile 6 nie umożliwia obecnie synchronizacji danych z komputerem PC poprzez USB ani bluetooth, w związku z tym możliwa jest jedynie synchronizacja poprzez usługi w chmurze. Jest to przykład, jak ważna jest dla tego systemu chmura. Świadczy o tym również udostępnienie aplikacjom integracji z usługami takimi jak:

• notyfikacje typu „pchnij” (ang. push notifications), które pozwalają zmniejszyć zużycie baterii, w sytuacji, gdy aplikacja musiałaby periodycznie sprawdzać, czy na serwerze dostępne są nowe dane (usługa wykorzystuje do tego celu serwer pośredniczący firmy Microsoft, do którego powinien zostać, jako zapytanie, wysłany sygnał o dostępności nowych danych, który to sygnał jest następnie przekazywany do aplikacji);
• lokalizacja, która wykorzystując Wi-Fi pozwala uzyskać informację o lokalizacji szybciej, niż z systemu AGPS (wynika z tego, że łącznie system korzysta z trzech faktycznych źródeł informacji o lokalizacji: GPS, sieć komórkowa i Wi-Fi);
• wyszukiwarka i mapy bing, dla których dostępne są kontrolki mapy oraz API wyszukiwarki;
• Windows Live ID, będąca usługą logowania znaną również pod nazwą .NET Passport;
• Xbox LIVE, użyteczna w zakresie np. wymiany danych o wynikach gry na koncie użytkownika.

Środowisko uruchomieniowe aplikacji

W systemie Windows Phone 7 środowisko uruchomieniowe aplikacji bazuje na znanej z .NET Framework bibliotece uruchomieniowej CLR (ang. Common Runtime Library). Jednakże nie są oczywiście dostępne wszystkie języki platformy .NET. Jedynym językiem, w którym obecnie można pisać aplikacje jest język C#. Natomiast w wersji 7.1 dodatkowo dostępny będzie język VB.NET.

W skład środowiska uruchomieniowego wchodzą również dwie biblioteki odpowiedzialne za renderowanie interfejsu użytkownika aplikacji: Silverlight i XNA (opisane już w poprzednim wpisie). Ponadto trzecim elementem, na którym można budować interfejs użytkownika jest tandem HTML i JavaScript, renderowany przez wbudowaną w system przeglądarkę Internet Explorer 8, dostępną dla aplikacji jako komponent, podobnie jak ma to miejsce w biurkowej wersji Windows (w Windows Phone 7.1 będzie to wersja 9 przeglądarki, wyposażona w obsługę sprzętowego renderingu HTML 5).

Kolejnym składnikiem środowiska uruchomieniowego aplikacji są podstawowe API systemu operacyjnego, dające dostęp do obszarów takich, jak np.: wyposażenie telefonu, akcja tworzenia nowej wiadomości e-mail w systemowym programie pocztowym, i in. (w wersji 7.1 API mają być jeszcze znacząco rozbudowane, np. o obsługę wielozadaniowości). Oczywiście jest dostępna również najbardziej podstawowa biblioteka Base Class Library (BCL), wspólna z innymi platformami .NET, co zapewnia przenośność skompilowanego kodu między tymi platformami, pod warunkiem, że kod ten ogranicza się do obszarów niezwiązanych z konkretnym systemem operacyjnym (np. klasy danych aplikacji).

Środowisko uruchomieniowe aplikacji pozwala w wersji 7.0 systemu przechowywać dane w formie dowolnych plików, umieszczonych w wydzielonym dla każdej aplikacji obszarze, poprzez API Isolated Storage, które w podobnej formie znane jest z technologii Silverlight. Natomiast w wersji 7.1, system dodatkowo udostępnia obsługę danych strukturalnych, poprzez wbudowany silnik bazodanowy SQL Server CE (z dołączonym ORM, umożliwiającym obsługę zapytań LINQ to SQL, ale bez obsługi bardziej rozwiniętej technologii Entity Framework).

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.