You are currently browsing the tag archive for the ‘Internals’ tag.

Olá pessoal.

Hoje cedo um cliente me perguntou sobre o processo de instalação das Apps no Windows Phone 8. Ele queria saber o motivo da “demora” na barra de progresso da instalação da App.

Não é o objetivo deste singelo post explicar todo o processo de instalação da App no Windows Phone. Mas o importante aqui é entender os “momentos” em termos de percentual desta instalação.

A instalação da App começa quando a Windows Phone Store chama o método “InstallationManager.AddPackageAsync”. Quando este método é disparado, é iniciado o download do pacote e o processo de instalação.

Desta forma, o pacote da aplicação passa por 4 fases de instalação que são:

  1. 5% completed – Quando a loja mostra a janela perguntando se o usuário deseja instalar o App.
  2. 10% completed – Logo após o usuário aceitar a instalação do App

  3. 55% completed – Quando o pacote do aplicativo foi baixado

  4. 100% completed – Quando o aplicativo foi instalado com sucesso.

 

Bom, por enquanto é só.

 

Abs,

@daibert

http://twitter.com/daibert

Anúncios

Olá pessoal. Esta semana um cliente me pediu uma explicação “bem” detalhada sobre a diferença entre uma aplicação Windows Store feita em HTML5/Javascript versus a mesma aplicação feita em C# (ou VB.Net). Perguntei qual nível ele gostaria de chegar e ele me falou: “Quero saber lá das profundesas”.

Bom, com base nisto, fui resgatar algumas informações importantes que vi em um Deep Dive de Windows Runtime que tive no inicio do ano passado.

A chave para a discussão é saber que, independente da linguagem escolhida o produto final será o mesmo, um binário APPX. Mas, dependendo desta escolha, realmente o modelo de execução das Apps será diferente.

Mas vamos começar pelo começo. Primeiramente, quando você for desenvolver sua Windows Store App, você deve começar por onde você já conhece. Se é um desenvolvedor C#, não vá inventar moda de aprender Javascript + HTML5 + CSS3 para desenvolver sua App. Siga a “lei do menor esforço”.

Sabemos que a criação de aplicações Windows Store pode ser feita em HTM5/Javascript, C#, VB.NET, C++. Mas é importante lembrar que componentes Windows Runtime reutilizáveis, só podem ser criados em C#, VB.NET e C++. E que DLLs estáticas, carregadas por “load library” só podem ser feitas em C++. Isto está representado no quadro abaixo para faciltar:

 

Linguagem

Windows Store app

Componente reutilizável Windows Runtime

Static Library

HTML / JavaScript

X

   

VB .NET

X X  

C# .NET

X X  

C++

X X X

 

Porém, em casos muito específicos, pode ser que você precise seguir nesta linha de “inventar moda”. Como por exemplo, se quiser uma aplicação de extrema performance, deverá seguir pelos caminhos do C++, que é mais performático que o C# e o Javascript, mas por sua vez, nem todo mundo conhece bem o suficiente para desenvolver uma App em C++.

O Windows Runtime, disponibiliza para todas as linguagens suportadas por ele, seus componentes. Isto é o que chamamos de Windows Runtime “in a box”. Além disso, cada linguagem, herda suas específicas como no quadro abaixo:

API específicas

JavaScript

VB.NET/C#.NET

C++

WinJS

X

   

WinRT APIs

X

X X

.NET subset

  X  

Win32 subset

  X X

C Runtime

    X

Platform namespace

    X

 

Por exemplo, pode ser que não existam algumas funcionalidades em .NET subset com APIs equivalentes em C++ ou Javascript.

Um exemplo disto é o namespace System.Net.HTTP no C#. Este componente existe para C# mas não tem um equivalente em C++, e acredite, é bem trabalhoso criar um a partir do zero. Desta forma, podemos utilizar uma arquitetura de componentes aonde a sua aplicação C++ chame um componente feito em C#, para facilitar algumas situações.

Neste post não vou contar a estória do Windows Runtime do começo, mas o importante neste momento é saber que o Windows Runtime é uma evolução e mistura do bom e velho COM.

Desta forma, as Apps Windows Store rodam em um contexto como se fossem uma aplicação COM/DCOM utilizando a arquitetura de componentes do Combase.dll, Ole32.dll, Oleaut32.dll, etc.

Então, ao invés de termos um Co* (Co = Component Object) temos um Ro* (Runtime Object), BSTR para strings no COM e HSTRING no Windows Runtime, assim como no COM, todos os componentes derivam de IUnknow, no Windows Runtime, todos os componentes derivam de IInspectable.

Seria algo como: image

Mas até agora, você está pensando: “O Daibert está me enrolando e não falou ainda da diferença entre as Apps feitas em Javascript e C#”. Pois bem. Contei toda a estória acima para que você possa entender o mecanismo por trás disto tudo.

A grande diferença entre as Apps feitas em Javascript para as feitas em C# é o contexto em que elas rodam.

 

image

As aplicações feitas em Javascript rodam dentro de um container chamado de Windows Web Application ou WWAHost .

Como o Javascript não é compilado, precisamos de um surrogate (neste caso o WWAHOST.EXE) para hospedar o container que executa o Javascript, no caso do Windows o engine chamado de Chakra. Esta combinação, permite que a aplicação feita em Javascript consuma componentes Windows Runtime. Da mesma forma como esta arquitetura não permite que criemos componentes reutilizáveis em Javascript (Viu agora que aquela estória toda lá em cima não foi em vão?).

Já as aplicações feitas em C# e XAML são realmente compiladas e tranformadas em código binário.

 

Bom, espero ter ajudado vocês a entenderem um pouco mais de como funcionam por dentro as Windows Store Apps.

 

Abraços,

@daibert

http://twitter.com/daibert

 

Referências:

COM Surrogate:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms691260(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682432(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms695225(v=vs.85).aspx

MIDL – Microsoft Interface Definition Language

http://msdn.microsoft.com/en-us/library/windows/desktop/aa367091(v=vs.85).aspx

Atualizações Twitter