Jak działa Windows 8 Runtime (aplikacje WinRT / Windows Store / Windows 10 Universal App) w porównaniu z Silverlight i WPF? [Zamknięte]

Próbuję przekonać się do nowego środowiska wykonawczego systemu Windows 8, które służy do tworzenia aplikacji w stylu Metro . Wiem, że możesz go używać z XAML i jest on oparty na .NET, więc C # i VB.NET mogą być używane do pisania aplikacji, ale wydaje się, że ma to coś wspólnego z HTML, CSS, DOM i JavaScript.

Czy ktoś może wyjaśnić, co to jest w kilku akapitach, w kategoriach zrozumiałych dla programisty interfejsu .NET? (Brakuje mi czegoś „kluczowego”, co jest konieczne, aby to zrozumieć.)

Wszyscy wiemy, że WPF, Silverlight , Windows Forms itp. Będą nadal działać pod Windows 8 (i Windows 10) przynajmniej na systemach Intel, więc proszę nie mów mi, że ...

Na najniższym poziomie WinRT jest modelem obiektowym zdefiniowanym na poziomie ABI. Wykorzystuje COM jako bazę (więc każdy obiekt WinRT implementuje IUnknowni przelicza) i stamtąd buduje. Dodaje całkiem sporo nowych koncepcji w porównaniu do COM starych, z których większość pochodzi bezpośrednio z .NET - na przykład model obiektowy WinRT ma delegatów, a zdarzenia są wykonywane w stylu .NET (z delegatami i dodawanie / usuwanie subskrybenta metody, jedna na zdarzenie) zamiast starego modelu COM źródeł zdarzeń i ujść. Oprócz innych ważnych rzeczy WinRT ma również sparametryzowane („ogólne”) interfejsy.

Kolejną dużą zmianą jest to, że wszystkie komponenty WinRT mają dostępne dla nich metadane, podobnie jak zestawy .NET. W COM masz coś takiego z typelibami, ale nie każdy składnik COM je miał. W przypadku WinRT metadane są zawarte w plikach .winmd - zajrzyj do „C: \ Program Files (x86) \ Windows Kits \ 8.0 \ Windows Metadata \” w Preview Developer. Jeśli się rozejrzysz, zobaczysz, że w rzeczywistości są to zestawy CLI bez kodu, tylko tabele metadanych. W rzeczywistości można je otworzyć za pomocą ILDASM. Uwaga: nie oznacza to, że sam WinRT jest zarządzany - po prostu ponownie używa formatu pliku.

Następnie istnieje wiele bibliotek zaimplementowanych w ramach tego modelu obiektowego - definiujących interfejsy i klasy WinRT. Ponownie spójrz na wspomniany wyżej folder „Metadane Windows”, aby zobaczyć, co tam jest; lub po prostu uruchom Przeglądarkę obiektów w VS i wybierz „Windows 8.0” w selektorze ram, aby zobaczyć, co jest objęte. Jest tam dużo i nie dotyczy tylko interfejsu użytkownika - dostajesz także przestrzenie nazw takie jak Windows.Data.Json, lub Windows.Graphics.Printing, lub Windows.Networking.Sockets.

Następnie dostajesz kilka bibliotek, które konkretnie zajmują się interfejsem użytkownika - głównie byłyby to różne przestrzenie nazw pod Windows.UIlub Windows.UI.Xaml. Wiele z nich jest bardzo podobnych do przestrzeni nazw WPF / Silverlight - np. Windows.UI.Xaml.ControlsJest ściśle dopasowana System.Windows.Controls; to samo dotyczy Windows.UI.Xaml.Documentsitp.

Teraz .NET ma możliwość bezpośredniego odwoływania się do komponentów WinRT, tak jakby były one zestawami .NET. Działa to inaczej niż COM Interop - nie potrzebujesz żadnych pośrednich artefaktów, takich jak zespoły /rinteropów, wystarczy plik .winmd, a wszystkie typy i ich elementy w jego metadanych stają się dla ciebie widoczne, jakby były obiektami .NET. Zauważ, że same biblioteki WinRT są w pełni natywne (a więc natywne programy C ++ korzystające z WinRT wcale nie wymagają CLR) - magia ujawnienia wszystkich zarządzanych rzeczy jest w samym CLR i jest dość niska. Jeśli zdemaskujesz program .NET, który odwołuje się do .winmd, zobaczysz, że faktycznie wygląda on jak zewnętrzne odwołanie do zestawu - nie ma w tym sztuczki polegającej na ręcznym podstępowaniu, takim jak osadzanie typu.

Nie jest to również mapowanie tępe - CLR próbuje dostosować typy WinRT do ich odpowiedników, tam gdzie to możliwe. Tak np GUID, daty i URI stać System.Guid, System.DateTimei System.Uri, odpowiednio; Interfejsy kolekcji WinRT jak IIterable<T>i IVector<T>stały IEnumerable<T>i IList<T>; i tak dalej. Działa to w obie strony - jeśli masz obiekt .NET, który implementuje IEnumerable<T>i przekaże go z powrotem do WinRT, zobaczy to jako IIterable<T>.

Ostatecznie oznacza to, że Twoje aplikacje .NET Metro mają dostęp do podzbioru istniejących standardowych bibliotek .NET, a także (rodzimych) bibliotek WinRT, z których niektóre - szczególnie Windows.UI- wyglądają bardzo podobnie do Silverlight, pod względem API. Nadal masz XAML do zdefiniowania interfejsu użytkownika i nadal masz do czynienia z tymi samymi podstawowymi pojęciami, co w Silverlight - powiązania danych, zasoby, style, szablony itp. W wielu przypadkach możliwe jest przeniesienie aplikacji Silverlight po prostu przez usingnowe przestrzenie nazw, i poprawianie kilku miejsc w kodzie, w których interfejs API został dostosowany.

Sam WinRT nie ma nic wspólnego z HTML i CSS i ma związek z JavaScript tylko w tym sensie, że jest tam ujawniony, podobnie jak to jest zrobione dla .NET. Nie musisz zajmować się HTML / CSS / JS, gdy używasz bibliotek interfejsu użytkownika WinRT w aplikacji .NET Metro (cóż, myślę, że jeśli naprawdę chcesz, możesz hostować WebViewkontrolę ...). Wszystkie twoje umiejętności .NET i Silverlight pozostają bardzo istotne w tym modelu programowania.

Z keynote kompilacji :

Zapewniają wspólne interfejsy API zarówno dla aplikacji HTML / CSS / JavaScript, jak i C # / XAML. Zostaną użyte C # i XAML, ale nie będzie to dokładnie WPF ani Silverlight.

Kluczową ideą jest to, że teraz istnieją dwie ścieżki rozwoju - Desktop i Metro.

• Komputer jest miejscem, w którym znajdują się stare aplikacje.
• Nową klasę aplikacji, aplikacje Metro, można budować na wiele sposobów, w tym przez VB.NET, C # lub C ++. Te trzy opcje językowe mogą wykorzystywać XAML do budowania interfejsu użytkownika. Alternatywą jest użycie JavaScript / HTML5 / CSS do opracowania zarówno interfejsu użytkownika, jak i kodu aplikacji.

Kilka ważnych punktów:

• Windows 8 przypomina coś w rodzaju powiększonego systemu operacyjnego telefonu komórkowego.
• W Metro nie ma nakładających się okien najwyższego poziomu, tak jak nie ma ich w telefonie komórkowym. Jeśli chcesz mieć aplikację w stylu MDI, musisz pozostać na pulpicie.
• Aplikacje w stylu Metro są automatycznie zawieszane, gdy nie są widoczne. Zrobiono to, aby przedłużyć żywotność baterii. Oznacza to, że nie ma sensu, aby wiele istniejących aplikacji komputerowych, które wykonują przetwarzanie w tle, nawet gdy użytkownik nie wchodzi z nimi w interakcję, zostało przeniesionych do metra.
• Wersja ARM systemu Windows 8 nie obsługuje aplikacji komputerowych. Więc jeśli chcesz napisać aplikację i chcesz, aby działała na dowolnej wersji systemu Windows, musi to być aplikacja Metro.

Istnieje zmodyfikowana wersja architektury, która z pewnością pomoże ci zrozumieć, gdzie dokładnie są te rzeczy. Jeden z ninja z Teleriku porozmawiał z zespołem CLR i zmodyfikował zdjęcie:

Tutaj możesz zobaczyć, gdzie stoi CLR. Struktura .NET ma teraz dwa profile

1-. Profil Metro .NET (CLR, które dotyczą aplikacji Metro)

2- Profil klienta .NET (środowisko wykonawcze CLR dla aplikacji C # i VB.NET)

Mam nadzieję, że daje to wyraźniejszy obraz. Przeczytaj cały artykuł w Zły obraz wart jest tysiąca długich dyskusji. .

Wiele szczegółów od Microsoft tutaj .

Środowisko wykonawcze systemu Windows jest udostępniane za pomocą metadanych interfejsu API (pliki .winmd). Jest to ten sam format, który jest używany w środowisku .NET (Ecma-335). Podstawowa umowa binarna ułatwia dostęp do interfejsów API środowiska wykonawczego Windows bezpośrednio w wybranym języku programowania. Kształt i struktura interfejsów API środowiska wykonawczego systemu Windows mogą być rozumiane zarówno przez języki statyczne, takie jak C #, jak i języki dynamiczne, takie jak JavaScript. IntelliSense jest dostępny w JavaScript, C #, Visual Basic i C ++.

W skrócie, Windows Runtime to nowy zestaw bibliotek udostępniających funkcjonalność Windows i dostępny w JavaScript / C # / VB / C ++. Każdy język został tak zaprojektowany, aby mógł go nazywać bezpośrednio, bez konieczności przechodzenia przez jakąś warstwę zagłuszania.

Silverlight i WPF to wersje XAML działające na CLR. Wśród innych funkcji Windows Runtime udostępnia wersję XAML bardzo podobną do Silverlight, ale robi to w natywny sposób, nie poprzez CLR. Można uzyskać do niego dostęp z CLR, ale także z C ++.