Windows Runtime dla aplikacji Metro w Windows 8 - szybkie zebranie faktów (1)

O nowym interfejsie Windows 8 było wiadomo jakiś czas temu, tym niemniej nikt się nie spodziewał aż takiej rewolucji! Jeszcze kilka dni przed konferencją BUILD ukazał się Silverlight 5 RC, a nieco później kompatybilny dla niego Blend… Tymczasem nowy interfejs Metro choć bardzo przypomina ten z Windows Phone 7 zakłada zupełnie nową technologię jego wykonania.  Nie jest to już .NET czy Silverlight. Tak więc oprócz rewolucji dla użytkowników mamy też dużą rewolucję wśród programistów piszących pod Windows. Wchodzimy w nową erę, jesteśmy świadkami historycznego momentu na miarę wprowadzenia Windows 95 czy wprowadzenia .NET. Z tej okazji pozwoliłem sobie zmienić nazwy moich blogów na bardziej zgodne z duchem czasu (słowo .NET pozamieniałem na Win i Windows). Zamierzam być na bieżąco, pooglądać sobie dokładnie te różne sesje, ale myślę, że już zebrałem trochę informacji na pierwszy wstępny post (póki co przejrzałem sobie 58 prezentacji PowerPoint, nie licząc innych mniej bezpośrednich źródeł).

Zanim zainstalowałem sobie Windows 8 miałem przyjemność poobcować z nim na urządzeniu Slate.

Obsługa dotykowa jest znacznie lepsza niż myszką i faktycznie chodzi to bardzo płynnie. Choć po prawie całodniowym obcowaniu z Windows 8 przy użyciu myszki powiem, że i do tego można się przyzwyczaić (choć nie udało mi się uzyskać pewnych rzeczy odpowiadających gestom). BTW tryb Aero nie jest do końca czysty, widać, że wszędzie system został przerobiony pod kątem Metro, nawet jak nie jesteśmy w tym trybie. Np. pobieram prezentację Internet Explorerem i dostaję lokalną notyfikację o tym, że plik został pobrany (mogę kliknąć w popup i otwiera się Explorer - zupełnie jak w WP).

Aplikacje Metro będą pisane w nowym środowisku zwanym Windows Runtime. Co to takiego? To twór znacznie doskonalszy od .NET, który stawia na nowo pytania na ile ułatwienie w naszej pracy znajdujemy pisząc w danym języku, a na ile jest to związane z platformą czy bibliotekami.

• nowe API dla aplikacji klienckich Metro (zastępuje w tym podzbiorze funkcjonalności Win32)
• napisane w kodzie niezarządzanym, ale utrzymane w nowoczesnym, obiektowym i bardzo wysokopoziomowym podejściu (przy pisaniu aplikacji nadal widzimy jeden ze znanych nam języków, przy przesiadce z .NET/Silverlight praktycznie nie odczujemy wizualnie różnicy jeśli będziemy pisać w C# lub VB)
• język ma tutaj niewielkie znaczenie – na równi możemy stosować  JavaScript, C++, języki zarządzane C# i VB (jak to możliwe - otóż w Windows Runtime odbywa się projekcja odpowiedniego języka a metadane są kompatybilne składniowo z CLI)
• rozwiązanie bardzo wydajne - kod w JavaScript czy w C# od razu jest mapowany przez Windows Runtime na odpowiednie procedury w kernelu

• różne udogodnienia znane z .NET i Silverlight zostały zawarte w Windows Runtime
• rozdzielenie wyglądu od logiki (dla C++, C# i VB - prezentacją jest XAML, dla JS - HTML5)
• async /then (api wymusza na twórcach pisanie responsywnych aplikacji, a składnia jest tak prosta jak synchroniczna – w C# async, w JS konstrukcja then znana choćby z jquery)
• data binding
• animacje
• style i szablony (btw stylowanie w HTML wygląda analogicznie jak w XAML, dzięki odpowiednim tagom i kontrolkom)
• stany wizualne
• nowe kontrolki UI (niektóre zbliżone do tych znanych z Silverlight i z Windows Phone, ale są też nowe, bardziej rozbudowane, a znacznie większych predefiniowanych możliwościach – np. kontrolki list oprócz wirtualizacji UI obsługują też wirtualizację danych, mają więcej zdarzeń np. ItemClick i w ogóle możliwości)
• obsługa gestów (kilka nowych w stosunku do Windows Phone, w tym taki dla urządzeń)

• nawigacja (w sumie taka jak w Silverlight, czyli Frame, Page, …)
• API dla komunikacji, sensorów, notyfikacji, ….
• współdzielenie komponentów w różnych językach (nic nie trzeba rejestrować, np. piszemy klasę w C# i możemy jej identycznie użyć w JavaScript, dodatkowo stary kod C++ możemy opakować w Windows Runtime i udostępnić w ten sposób dla innych języków)
• typy są prawie zgodne z .NET, czasami możemy napotkać pewne różnice
• są inne przestrzenie nazw niż w WPF i Silverlight, choć wiele klas nazywa się tak samo
• programowanie w JavaScript jest tak proste jak w każdym innym języku, różnica zazwyczaj wynika tylko ze składni (potężna biblioteka WinJS)

• głównymi założeniami C#5 jest integracja z Windows Runtime, a także async i atrybuty parametrów
• grafikę 3D można rozwijać w DirectX
• aplikacje mają cykl życia (jak nie są na pierwszym planie to są usypiane, mogą też być później ubijane – model znany z Windows Phone, są odpowiednie zdarzenia, obiekty do sprawdzania stanu, zapisywania i pobierania danych – np. w JS mówi się o sesji)
• aplikacje mają uprawnienia definiowane w manifeście (tzw. capabilities - podobnie jak w Windows Phone)
• apliakcje są dystrybuowane przez Store (certyfikacja, trial, itd – podobnie jak w Windows Phone)
• aplikacje mogą wymieniać dane między sobą, mogą zawierać kontrakty (tego mi brakuje w Windows Phone, a kojarzy się z Androidem)

Przed zainstalowaniem aktualizacji do sterownika karty graficznej nie działały mi designery w Visual Studio 11 i w Blend 5, ale po instalacji wszystko zaczęło działać. Po uruchomieniu aplikacja się instaluje w systemie (podobnie jak na Windows Phone). Domyślnie jest ostylowana w Metro, czyli jest … cała czarna.

Tak więc nie dzieje się katastrofa. Nie żałuję, że zainwestowałem sporo czasu w  Silverlight i Windows Phone. Znajomość XAML-a, C#, Visual Studio, Blenda będą z pewnością bardzo przydatne przy nowej technologii, a poznanie Windows Phone sprawiło, że wiele wprowadzanych mechanizmów ani zachowanie interfejsu w Windows 8 mnie nie dziwią, wydają mi się znajome (styl metro, idee usypiania aplikacji, notyfikacji lokalnych i notyfikacji push, kafelki, background audio, transfer plików itd - choć czasami inaczej zrealizowane np. w cyklu życia apliakcji jest odzielny handlery - na otwarcie przez searcha, przez pickera itd.). Mimo braku bezpośredniej kompatybilności i tak Silverlight, a jeszcze bardziej ten z Windows Phone są najbardziej ideowo, a w wielu miejscach i technicznie zbliżone do założeń Windows Runtime.  WCF RIA Services są obecnie intensywnie rozwijane pod kątem obsługi klientów w JavaScript (obecnie SP2 RC), a także właśnie aplikacji Metro, więc i tej technologii nie żałuję. Wzorzec MVVM również znajdzie tutaj zastosowanie (w C#, w Java Script, …).  Tak więc nadal możemy stosować znane nam języki, narzędzia, wzorce, rozwiązania, zmieniła platforma klienta.

c.d.n (ciąg dalszy nastąpi)