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 ...
wpf
windows-runtime
windows-store-apps
windows-10
win-universal-app
Ian Ringrose
źródło
źródło
Windows.*
obejmują przestrzenie nazw. Jak dotąd terminologia jest nieco myląca, ponieważ WinRT odnosi się zarówno do technologii, jak i do całego zestawu standardowych bibliotek. Nie sądzę jednak, aby istniała jakaś zwięzła etykieta tylko dla bibliotek interfejsu użytkownika (Windows.UI.*
).Odpowiedzi:
Na najniższym poziomie WinRT jest modelem obiektowym zdefiniowanym na poziomie ABI. Wykorzystuje COM jako bazę (więc każdy obiekt WinRT implementuje
IUnknown
i 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
, lubWindows.Graphics.Printing
, lubWindows.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.UI
lubWindows.UI.Xaml
. Wiele z nich jest bardzo podobnych do przestrzeni nazw WPF / Silverlight - np.Windows.UI.Xaml.Controls
Jest ściśle dopasowanaSystem.Windows.Controls
; to samo dotyczyWindows.UI.Xaml.Documents
itp.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
/r
interopó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.DateTime
iSystem.Uri
, odpowiednio; Interfejsy kolekcji WinRT jakIIterable<T>
iIVector<T>
stałyIEnumerable<T>
iIList<T>
; i tak dalej. Działa to w obie strony - jeśli masz obiekt .NET, który implementujeIEnumerable<T>
i przekaże go z powrotem do WinRT, zobaczy to jakoIIterable<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 przezusing
nowe 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ć
WebView
kontrolę ...). Wszystkie twoje umiejętności .NET i Silverlight pozostają bardzo istotne w tym modelu programowania.źródło
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.
źródło
Kluczową ideą jest to, że teraz istnieją dwie ścieżki rozwoju - Desktop i Metro.
Kilka ważnych punktów:
źródło
Popup
( msdn.microsoft.com/en-us/library/windows/apps/… ), więc jeśli chcesz, możesz przygotować coś podobnego do MDI. Oczywiście nie zaleca się nadużywania go, ponieważ ryzykujesz, że skończysz z interfejsem niedotykowym.localhost
możesz połączyć się tylko z tą samą aplikacją. Możesz użyć normalnych plików w jednym ze wspólnych „znanych folderów” (Dokumenty, Zdjęcia itp.), Ale jest to dość prymitywny hack, który wymaga odpytywania i jest widoczny dla użytkownika.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. .
źródło
Wiele szczegółów od Microsoft tutaj .
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 ++.
źródło