Estou tentando entender o novo Windows 8 Runtime usado para criar aplicativos no estilo Metro . Eu sei que você pode usá-lo com XAML e é baseado no .NET, para que C # e VB.NET possam ser usados para escrever os aplicativos, mas parece ter algo a ver com HTML, CSS, DOM e JavaScript.
Alguém pode explicar o que é isso em alguns parágrafos, em termos que um programador de interface do usuário .NET possa entender? (Estou sentindo falta de algo "chave" necessário para entendê-lo.)
Todos sabemos que o WPF, o Silverlight , o Windows Forms etc. continuará funcionando no Windows 8 (e Windows 10) em pelo menos nos sistemas Intel, portanto, não me diga que ...
wpf
windows-runtime
windows-store-apps
windows-10
win-universal-app
Ian Ringrose
fonte
fonte
Windows.*espaços de nomes cobrem. A terminologia até agora é um pouco confusa aqui, pois o WinRT se refere à tecnologia e a todo o conjunto de bibliotecas padrão. Eu não acho que exista um rótulo conciso apenas para as bibliotecas da interface do usuário (Windows.UI.*).Respostas:
No nível mais baixo, o WinRT é um modelo de objeto definido no nível ABI. Ele usa o COM como base (para que todo objeto WinRT implemente
IUnknowne refcounting) e crie a partir daí. Ele adiciona muitos conceitos novos em comparação com o COM antigo, a maioria dos quais vem diretamente do .NET - por exemplo, o modelo de objeto do WinRT possui delegados e os eventos são feitos no estilo .NET (com delegados e adicionar / remover assinante) métodos, um por evento) em vez do antigo modelo COM de fontes e coletores de eventos. Entre outras coisas notáveis, o WinRT também possui interfaces parametrizadas ("genéricas").Outra grande mudança é que todos os componentes do WinRT têm metadados disponíveis para eles, assim como os assemblies do .NET. No COM, você meio que teve isso com typelibs, mas nem todos os componentes do COM os tinham. Para o WinRT, os metadados estão contidos nos arquivos .winmd - consulte "C: \ Arquivos de programas (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" na Visualização do desenvolvedor. Se você bisbilhotar, verá que eles são realmente conjuntos de CLI sem código, apenas tabelas de metadados. Você pode abri-los com o ILDASM, de fato. Observe que isso não significa que o próprio WinRT seja gerenciado - ele simplesmente reutiliza o formato do arquivo.
Existem diversas bibliotecas implementadas em termos desse modelo de objeto - definindo interfaces e classes do WinRT. Mais uma vez, veja a pasta "Metadados do Windows" mencionada acima para ver o que há; ou simplesmente inicie o Pesquisador de objetos no VS e selecione "Windows 8.0" no seletor de estrutura, para ver o que é coberto. Há muita coisa lá, e ela não lida apenas com a interface do usuário - você também recebe namespaces como
Windows.Data.Json, ouWindows.Graphics.Printing, ouWindows.Networking.Sockets.Em seguida, você obtém várias bibliotecas, que estão lidando especificamente com a interface do usuário - a maioria seria vários namespaces sob
Windows.UIouWindows.UI.Xaml. Muitos deles são muito semelhantes aos namespaces WPF / Silverlight - por exemplo,Windows.UI.Xaml.Controlssão muito semelhantesSystem.Windows.Controls; idem paraWindows.UI.Xaml.Documentsetc.Agora, o .NET tem a capacidade de referenciar diretamente os componentes do WinRT como se fossem assemblies do .NET. Isso funciona de maneira diferente da COM Interop - você não precisa de artefatos intermediários, como assemblies de interoperabilidade, apenas
/rum arquivo .winmd e todos os tipos e seus membros em seus metadados ficam visíveis para você como se fossem objetos .NET. Observe que as próprias bibliotecas do WinRT são totalmente nativas (e, portanto, os programas C ++ nativos que usam o WinRT não exigem CLR) - a mágica de expor tudo o que é gerenciado é dentro do próprio CLR e é de nível bastante baixo. Se você criar um programa .NET que referencie um .winmd, verá que ele realmente se parece com uma referência externa de montagem - não há truques fáceis como o tipo incorporação nele.Também não é um mapeamento contundente - o CLR tenta adaptar os tipos WinRT aos seus equivalentes, sempre que possível. Assim, por exemplo, GUIDs, datas e URIs tornar-se
System.Guid,System.DateTimeeSystem.Uri, respectivamente; Interfaces de coleta do WinRT comoIIterable<T>eIVector<T>torneIEnumerable<T>- se eIList<T>; e assim por diante. Isso acontece nos dois sentidos - se você tem um objeto .NET que implementaIEnumerable<T>e o repassa ao WinRT, ele será visto comoIIterable<T>.Por fim, o que isso significa é que seus aplicativos .NET Metro obtêm acesso a um subconjunto das bibliotecas .NET padrão existentes e também às bibliotecas WinRT (nativas), algumas das quais - particularmente
Windows.UI- se parecem muito com o Silverlight, em termos de API. Você ainda tem XAML para definir sua interface do usuário e ainda lida com os mesmos conceitos básicos do Silverlight - ligações de dados, recursos, estilos, modelos etc. Em muitos casos, é possível portar um aplicativo Silverlight simplesmente pelosusingnovos namespaces, e ajustando alguns lugares no código em que a API foi ajustada.O próprio WinRT não tem nada a ver com HTML e CSS, e só se relaciona com o JavaScript no sentido de que ele também é exposto ali, semelhante à maneira como é feito para o .NET. Você não precisa lidar com HTML / CSS / JS ao usar as bibliotecas de interface do usuário do WinRT no seu aplicativo .NET Metro (bem, acho que, se você realmente quiser, pode hospedar um
WebViewcontrole ...). Todas as suas habilidades em .NET e Silverlight permanecem muito relevantes neste modelo de programação.fonte
Na palestra Build :
Eles estão fornecendo APIs comuns para aplicativos HTML / CSS / JavaScript e aplicativos C # / XAML. C # e XAML serão usados, mas não serão exatamente o WPF ou o Silverlight.
fonte
A idéia principal é que agora existem duas faixas de desenvolvimento - o Desktop e o Metro.
Alguns pontos importantes:
fonte
Popup( msdn.microsoft.com/en-us/library/windows/apps/… ); portanto, se você quiser, poderá criar algo semelhante ao MDI. Obviamente, não é recomendável abusá-lo, pois você corre o risco de acabar com uma interface do usuário não compatível com o toque.localhost, você pode conectar-se apenas ao mesmo aplicativo. Você pode usar arquivos normais em uma das "pastas conhecidas" compartilhadas (Documentos, Imagens, etc.), mas esse é um hack razoavelmente grosseiro que requer pesquisa e fica visível para o usuário.Há uma versão modificada da arquitetura que certamente o ajudará a entender exatamente onde estão as coisas. Um dos ninjas da Telerik conversou com a equipe do CLR e modificou a imagem:
Aqui você pode ver onde está o CLR. O framework .NET agora possui dois perfis
1- Perfil do .NET Metro (CLR que lida com o aplicativo Metro)
2- Perfil do cliente .NET (tempo de execução CLR para aplicativos C # e VB.NET)
Espero que isso lhe dê uma imagem mais clara. Leia o artigo completo em Uma imagem ruim vale por mil longas discussões. .
fonte
Muitos detalhes da Microsoft aqui .
Em resumo, o Windows Runtime é um novo conjunto de bibliotecas que expõe a funcionalidade do Windows e está disponível para JavaScript / C # / VB / C ++. Cada idioma foi criado para entender e poder chamá-los diretamente, em vez de precisar passar por uma camada de thunking.
Silverlight e WPF são tipos de XAML executados no CLR. Entre outras funcionalidades, o Windows Runtime expõe uma versão do XAML muito semelhante ao Silverlight, mas de maneira nativa, não por meio do CLR. Ele pode ser acessado pelo CLR, mas também pelo C ++.
fonte