WinMK Live: BUILD 2014 - aplikacje WinRT z dostępem do całego Windows, WinRT/XAML na Windows Phone, uniwersalne aplikacje XAML

Dla odmiany zwróciłem się teraz ku drugiej stronie mocy czyli WinRT, XAML i .NET. Trzy poniższe prezentacje nie wyczerpują wymienionych zagadnień nawet w ogólnej postaci, dlatego bedę je kontynuować w następnym poście. Świat XAML czy .NET od kilku ostatnich lat zaczął zmierzać w inną stronę niż przed 2011 rokiem, kiedy co rok były nowe frameworki, języki lub ich nowe wersje. Nowe funkcjonalności wymyślane są adekwatnie do nowych czasów, w dobie ukierunkowanej na Web, urządzenia mobilne i chmurę. Windows Phone 8.1 zrównał XAML i HTML5 jako języki platformy, co stało się naturalną konsekwencją unifikacji z Windows 8.1. Co ciekawe w nowym WP mamy więcej kontrolek XAML niż JavaScript, odwrotnie niż w Windows, gdzie to JavaScript ma przewagę w kontrolkach.

Respecting Your Investments: How to Leverage Your Existing Code In a New Windows Runtime LOB App5

Bardzo ciekawa prezentacja. Od wersji Windows 8.1 Update umożliwiono aplikacjom wgrywanym nie przez Store komunikację z zewnętrznym komponentem WinRT, który może wykonywać dowolny kod desktopowego .NET. Miłośnicy Web zapytają po co. Odpowiedź jest prosta. W warunkach produkcyjnych nie przepisuje się całych systemów, całego kodu ciągle na nowe technologie, czas to pieniądz. Można sobie wyobrazić jak stara aplikacja desktopowa w .NET potrzebuje szybko otrzymać nowy dotykowy intefejs użytkownika, by mogła działać na tablecie. Robimy wrapper na kod z logiką aplikacji np. taki korzystający z SQL Servera, generujemy proxy, rejestrujemy jako COM, dodajemy referencję, uzupełniamy manifest i możemy cieszyć się aplikacją z nowoczesnym interfejsem. Potem robimy np. instalator i wgrywamy klientowi komponent oraz aplikację Windows Store. Microsoft w niektórych systemowych aplikacjach Modern UI też zastosował sztuczki z wołaniem zewnętrznego COM-a, choć trochę w innej postaci.

Visual Studio domyślnie zdejmuje blokadę na firewall.

WCF na Windows Store nie wspiera komunikacji dwukierunkowej, ale można użyć ASP.NET SignalR.

zwykły serwis Web API, ale hostowany na samym urządzeniu w lokalnym procesie

COM-y umożliwiają komunikację, wystarczy załadować je poza kontenerem aplikacji. Można skorzystać z dowolnego API dostępnego na Windows, w Windows 8.1 Update 1 możemy wykorzystywać tylko kod zarządzany.

Komponent WinRT można zdeployować niezależnie od aplikacji np. instalator może go zainstalować obok naszej aplikacji Modern UI. Jest hostowany w innym kontekście, w kontekście pełnej maszyny CLR. W efekcie dostajemy dostęp do innego API. Możliwość komunikacji zewnętrznej jest dostępne od Windows 8, aplikacje Mail i Contact wspólnie korzystają z zewnętrznego COM-a.

Dla komponentów wewnątrz aplikacji Visual Studio robi to za nas, w przypadku zewnętrznego komponentu musimy to sami zrobić.

ActivatableClassAttribute wskazuje, że jest to broker komponent. Taka jest różnica w stosunku do komponentów wewnętrznych aplikacji. Aplikacje wrzucane do Windows Store ze ścieżką do desktopa nie przejdą procesu certyfikacji.

“very old school code”

idl - generowany z szablonu broker komponentu dla Visual Studio, który wkrótce zostanie opublikowany w galerii

debugowanie broker komponentu przez zapiecie się do procesu dllhost.exe

Aplikacje WinRT mogą zostać uśpione, broker komponent może je w bardzo krótkim czasie obudzić (na demie się nie udało)

Windows Runtime for Windows Phone Developers

Z pewnością warto obejrzeć. W przypadku nowego Windows Phone 8.1 sprawa z XAML trochę się uprościła, a jednocześnie pokomplikowała. Otóż wspierane są teraz dwa modele aplikacji – stary, obecnie znowu zwany po imieniu Silverlight (w dobie prezentowania WP8 przemianowano go na .NET) oraz nowy model zgodny z Windows Store apps. Mamy więc obecnie dwa rodzaje XAML, dwa podzbiory WinRT oraz mobilną wersję WinJS. Wybór nie jest jednoznaczny.

Silverlight na WP zawiera pewne funkcjonalności, których nie ma jeszcze w Windows Store apps, z drugiej strony nie ma wszystkich nowości wprowadzonych z Windows Store apps np. nowego XAML, kontrolek, narzędzi, ale można z niego wywoływać większość WinRT API nie związanego z UI (często mamy alternatywę nową i starą, a nie zapominajmy że WP 8 też wprowadził już wcześniej mniejszy podzbiór WinRT API, często API dedykowanego tylko dla WP, które teraz też ma już nowszych następców). Kto jednak zainwestował już w swoją appkę albo ma coś w niej specyficznego jak np. Lens, to dalej będzie jechał na konglomeracji Silverlight i WinRT.

Kto zaczyna nową aplikację, a nie ma specyficznych rzeczy jak np. schowek, to powinien postawić na nowy model Windows Store i pełne WinRT. Dzięki temu może wspóldzielić kod z aplikacją Windows i zrobić dwie aplikacje jednocześnie. Teraz pytanie - XAML czy WinJS? Odpowiedź nie będzie jednoznaczna, zależy od umiejętności, rodzaju kodu do reużytkowania, inaczej podejdzie osoba związana z XAML, inaczej rasowy web developer. Na obecny moment więcej kontrolek, także nowych jest w XAML, WinJS mobilny nie ma np. hub-a, autosugestbox-a czy contentdialogu. Nikt nie chwalił się też renderowaniem dowolnej zawartości kafelków w inny sposób niż przez XAML.

To wszysko to też pewne uproszczenie, bo są różnice w zachowaniu lub API także pomiędzy uniwersalnymi już Windows Store apps na tabletach i smartfonach. Pomijam tu oczywiście różnice wynikajace z dostosowania samego UI do różnych wielkości ekranu i do user experience urządzeń. Windows Phone to nie tylko podzbiór, ale czasami nadzbiór tego, co mamy w Windows, także w najnowszym XAML i WinJS. Cześć tych różnic wynika jak sądzę z nowych pomysłów jakie już trafiły do WP 8.1, a nie zdążyły zaistnieć w Windows 8.1 lub po prostu ze specyfiki urządzenia. Niemniej jednak możemy dziś współdzielić 90% kodu, co jest niewątpliwie sporym sukcesem.

nowe API do emaili

dodano folder Roaming, tak jak w Windows, dodatkowo pojawił się folder nieznany z Windows - Project

Po wybraniu WinRT XAML rzeczy z WinRT zamiast starego API

LauchUriAsync i ContactPicker tak jak w Windows, nowe klasy PhoneCallManager i ChatMessageManager

zamiast agentów model znany już z Windows

modele kafelków i notyfikacji znane z Windows, aczkolwiek XamlRenderingTask jest unikalną klasą w WP 8.1 pozwalajacą wyrenderować dowolną zawartość XAML!

nawigacja jak w Windows, z dokładnoscią do klawisza Back, który już teraz nie zadziała z automatu, ale można ręcznie przechwycić jego naciśniecie i je obsłużyć

klient http oparty na WinRT, wprowadzony z Windows 8.1

lokalizacja znana z Windows (XAML)

podobnie jak w Windows

File picker znany z Windows, ale jest mniej zasobów, więc aplikacja jest usypiana, a nawet może zostać zamknięta. Dlatego w Windows Phone jest inny zestaw metod zakończonych na *Continue, które zlecają wykonywanie aplikacji po powrocie z file pickera.

MediaElement mający pasek sterujący, podobnie jak w Windows.

sharowanie

podobnie jak w Windows

http://aka.ms/WpWinRT

Developing Apps using the Common XAML UI Framework

Dobra prezentacja Tima Heuera, jednego z nielicznych jaki został, może jedynego, którego kojarzę jako prezentera z czasów Silverlight. Sumiennie dokonał porównania uniwersalnego XAML między Windows i Windows Phone. Dowiemy się, co jest identyczne, co ma taki sam zapis, ale inne zachowanie, co jest unikalne dla każdej z platform, jakie są unikalne nowo wprowadzone funkcjonalności w UI WP 8.1. Tutaj mała moja dygresja, że WinJS też nie jest w pełni uniwersalny, funkcjonują dwie wersje biblioteki, nie wszystko każda wspiera, czasami są inne zachowania przy takim samym kodzie. Tak więc niezależnie od obranej technologii sytuacja wygląda podobnie.

Flyout - na WP na cały ekran

CommandBar - ten sam kod, dwie wizualizacje

SDK do reklam - różne frameworki dla Windows i Windows Phone

Nowe kontrolki dla WP 8.1: AutoSuggestBox (podobne zachowanie do SearchBox z Windows, ale bez powiązania z kontraktem), ContentDialog (dialog z dowolną zawartością XAML)