You are currently browsing the category archive for the ‘Phone 8’ category.

Olá pessoal, este é um breve post para tirar algumas dúvidas que alguns clientes e parceiros vem me perguntando nas últimas semanas.

Para o Windows Phone 8.1 podemos ter dois tipos de projeto:

  1. Windows Phone Silverlight – Exclusivamente XAML
  2. Windows Universal Apps – XAML ou HTML5 + JavaScript

Se você é um desenvolvedor XAML, você tem três opções para criar suas Apps para Windows Phone 8.1

  1. Continuar desenvolvendo Apps usando projetos do tipo Silverlight 7.x/8.0 – Este tipo de projeto permite que você continue executando suas Apps em versões de Windows Phone 7.x, 8.0 normalmente. Além destes, também poderá roda-las em Windows Phone 8.1, porém sem tirar proveito das novidades da plataforma Windows Phone 8.1.
  2. Atualizar sua App para Windows Phone Silverlight 8.1 – Você poderá utilizar as novas funcionalidades da plataforma, porém sua App só rodará em dispositivos com o Windows Phone 8.1.
  3. Criar uma versão baseada em Windows XAML, ou Windows Universal App – Esta só rodará em dispositivos com Windows Phone 8.1, porém é a maneira mais simples de se criar aplicações Windows multiplataforma, ou seja, uma App única que rodará em Windows 8.1 e Windows Phone 8.1.

O que direciona nossa decisão é o tipo de recurso que a App utilizará. Por exemplo, Windows Universal Apps, não tem acesso aos seguintes recursos:

  • CameraCaptureTask
  • Camera Lenses
  • Lockscreen background image provider
  • Runs under Lock
  • Background Audio Agent
  • Alarms/Reminders
  • SocialRT (Silverlight 8.1 only)
  • VoIP
  • Continuous background location tracking (SL 8.0 only)
  • Wallet agents
  • System.ServiceModel (WCF/SOAP)

 

Bom, por enquanto é só, mas nas próximas semanas o blog estará bastante movimentado.

 

Abs,

@daibert

Anúncios

Olá pessoal,

neste post vou falar um pouco mais dos bastidores do Windows Phone 8.

Quando falamos tecnicamente do Windows Phone 8, a primeira coisa que nos vem a cabeça é o Kernel compartilhado do Phone com o Windows 8. Já apresentei neste post http://aka.ms/kernel8 uma visão geral do Kernel compartilhado entre o Windows 8 e o Windows Phone.

Desta vez, vamos entrar um pouco mais a fundo na plataforma.

Quando a Microsoft criou a primeira versão do Windows Phone, o Windows Phone 7.0, ela utilizou o Kernel do Windows CE como fundamento para o novo Sistema Operacional para telefones. Então veio a versão 7.5 e nova funcionalidades foram implementadas, porém o núcleo do Sistema Operacional, continuava o mesmo, do Windows CE.

 

phone7

Windows Phone 7.X

Não há problema algum com o Phone 7.X ter sido desenvolvido sob o Kernel do Windows CE. A questão é que o Kernel do Windows CE é uma tecnologia muito estável, porém já tem mais de 15 anos. Por este motivo, existiam alguns limitadores de integração com hardwares de última geração, como sensores e multiplos núcleos de processadores.

Então, quando a Microsoft resolveu fazer a versão Windows Phone 8, aproveitou o momento da Plataforma Windows e unificou o Kernel nas 2 plataformas.

Mas o que mudou efetivamente?

Com a utilização do mesmo Kernel nas duas plataformas, várias coisas como drivers, modelo de desenvolvimento, classes portáveis passaram a ser compatíveis entre as duas plataformas de forma transparente.

Outra coisa que passou a estar presente no Windows Phone 8 é parte do conjunto de componentes do Windows Runtime, que no Phone chamado de Windows Phone Runtime. Este conjunto de componentes permite que boa parte do código que é utilizado em uma aplicação Windows 8 possa ser reaproveitado em uma App para Windows Phone 8 e vice versa.

phone8_01

Compatibilidade de aplicações Windows Phone 7.X com o Windows Phone 8

Bom, mas se o kernel do Windows Phone 8 não é compatível com o Kernel do Windows Phone 7.5, como as Apps do WP 7.5 rodam no Windows 8?

Uma das coisas que a Microsoft tem em seu DNA é a compatibilitade com versões anteriores dos seus sistemas operacionais.

Desta forma, a implementação do Windows Phone 8 vem com um modo conhecido como “Quirks Mode”. O Quirks Mode, é uma camada que faz com que as Apps WP 7.X sejam executadas no WP 8.0 com o comportamento que teriam em um WP 7.X sem que o desenvolvedor precise fazer alterações no código.

Então podemos imaginar que as Apps para WP 7.x rodam um pouco mais lento no WP 8.x, o que é verdade. Mas, por outro lado, como os hardwares que rodam o WP 8.x são bem mais rápidos que os que rodam o WP 7.x, isto é compensado.

Mas o ideal seriamos recompilhar nossas Apps para Windows Phone 8.

Para conhecer mais sobre o Quirks Mode, vejam este video http://channel9.msdn.com/Events/Build/2012/3-045

 

phone8_02

Aplicações Windows 7.X rodando em Windows Phone 8

 

Mudando o Target de sua App para Windows Phone 8

O Quirks Mode é algo que foge do controle do desenvolvedor, sendo utilizado pelo próprio Windows Phone Runtime.

Mudar o target do seu projeto para Windows Phone 8, faz com que sua App passe a ser executada de forma nativa para a nova versão do Windows Phone 8.

Mudar o target para WP 8.x é bem simples. Basta abrir o projeto no Visual Studio 2012+, right-click no projeto e selecionar a opção Upgrade to Windows Phone 8.0

__image_thumb_10

_image_thumb_11

 

Uma vez isto feito, sua App não utilizará mais o quirks mode, o que pode gerar algum problema de comportamento da App, caso alguma API tenha comportamento diferente do esperado no WP 8.0 comparado com o de WP 7.x.

Desta forma, será necessário que você teste sua App depois de recompila-la para WP 8.0.

 

Boas referências:

Windows Phone Versions

http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202996(v=vs.105).aspx

Windows Phone API reference

http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff626516(v=vs.105).aspx

App platform compatibility for Windows Phone

http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206947(v=vs.105).aspx

De bonus, segue este poster!!!

image

 

Abs,

@daibert

Hoje me deparei com um parceiro implementando uma App que utiliza o Bing Maps. Ele me pediu algumas referências de por onde começar.

Normalmente eu direciono os parceiros e clientes para este post http://rbrundritt.wordpress.com/2012/11/06/getting-started-with-bing-maps-windows-store-apps-native/

Mas hoje descobri um documento que agrega os principais links que um desenvolvedor precisa.

Você pode baixa-lo aqui, ó http://sdrv.ms/1fz5EjB

Espero que este documento ajude vocês.

 

Abs,

@daibert

http://twitter.com/daibert

 

Olá pessoal. Uma maneira de aumentar o alcance de sua App para outros mercados, fora do Brasil, é criar sua App Multilingue.

Abaixo, segue uma lista de links que pode ajuda-los a entender como desenvolver Apps multilinguas.

 

Abs,

@daibert

Olá pessoal, está foi a minha apresentação na trilha Windows Phone dev no The Developers Conference Florianopolis 2013 fazendo um deep dive no Windows Runtime.

Aproveitem para ver um pouco mais de detalhes neste outro post sobre o mesmo assunto: http://aka.ms/internals01

Abs,
@daibert

 

http://twitter.com/daibert

Olá pessoal, está foi a minha apresentação na trilha Windows Phone dev no The Developers Conference Florianopolis 2013

 

 

Abs,
@daibert

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

Olá pessoal.

Hoje vou falar um pouco sobre o Secure Boot do Windows Phone 8. O Secure Boot é uma tecnologia que faz uma validação na imagem do Windows Phone que esta gravada no firmware do aparelho.

Desta forma, durante o boot é feita uma validação que garante que o sistema operacional que será carregado está integro.

Isto é um dos motivos que faz com que o Windows Phone 8 não tenha virus ou malwares instalados.

Todos os componentes do sistema operacional possuem uma assinatura digital que é validada pelo chamado pre-UEFI (http://msdn.microsoft.com/en-us/library/windows/hardware/gg463075.aspx). Esta é a garantia que só estes componentes autorizados pelo UEFI podem ser carregados.

Para saber mais sobre este assunto, recomendo a leitura dos links abaixo:

System on a Chip http://blogs.windows.com/windows/b/bloggingwindows/archive/2011/01/05/next-version-of-windows-to-run-on-system-on-a-chip-architectures.aspx 

UEFI e o Windows 
http://msdn.microsoft.com/en-us/windows/hardware/gg463149.aspx

Abraços,

@daibert

http://twitter.com/daibert

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