Windows 10
Uma introdução à criação de aplicativos do Windows para dispositivos Windows 10
Você viveram para ver isso: um único SO Windows pode ser executado em todos os tipos de dispositivo do Windows. Ele tem uma plataforma de dispositivo único para habilitar os drivers universais genuínos de hardware e uma plataforma de aplicativo único para habilitar os verdadeiros aplicativos Windows universais. Anos de criação, isso é uma realização significativa de engenharia.
No nível do sistema operacional, isso significa uma base de código única, ágil e fácil de manter. Para desenvolvedores, ele fornece uma superfície de API unificada e confiável em cada dispositivo do Windows, de dispositivos de Internet das coisas (IoT) como Raspberry Pi to phone, Xbox, tablet, Surface Hub, laptop, PC e muito mais (como Microsoft HoloLens). Conforme mostrado na Figura 1, é uma promessa write-once-run-everywhere (escreva uma vez e execute em todos os lugares), entregue no Windows 10 com a plataforma de aplicativos universal (UAP).
.png "A plataforma de aplicativo Universal habilita aplicativos em todas as famílias de dispositivos do Windows")
Figura 1 A plataforma de aplicativo Universal habilita aplicativos em todas as famílias de dispositivos do Windows
A jornada para Windows 10
A convergência do Windows tem sido uma longa viagem. Em 2011, a Microsoft tinha três plataformas com três sistemas operacionais. O SO do PC e do servidor era Windows, criado sobre a base de código do Windows NT. O sistema operacional para celular era o Windows Phone, um derivativo do Windows CE com semelhanças superficiais ao Windows NT, mas uma base de código diferente. O SO do Xbox 360 era o Windows NT, mas era uma bifurcação de 10 anos, então totalmente divergente a ele, e também era uma base de código distinto.
Nesse momento, a Microsoft trabalhou para trazer um Internet Explorer comum a cada plataforma. Não houve nenhum Windows Core, nenhuma plataforma Windows e nenhuma UAP. A implementação do Internet Explorer nesses três sistemas operacionais foi bem-sucedida, mas precisou de uma ginástica de engenharia considerável.
Com o Windows Phone 8, o kernel do sistema operacional Windows NT foi substituído pelo Windows CE em celulares. Essa convergência nivelou o caminho em direção a uma única base de código. O Windows, Windows Phone e o Xbox 360 aproveitaram o mesmo kernel, embora cada um ainda tivesse bases de código exclusivo. Em 2013, o Xbox One foi lançado e com ele um núcleo do sistema operacional compartilhado com o Windows 8. A Microsoft estava perto de uma base de código que você poderia senti-la, mas ela ainda estava atendendo a três sistemas operacionais distintos.
O Windows 10 foi a chance de reunir essa troika e convergir os esforços de engenharia. No entanto, ao mesmo tempo, novos aplicativos da tecnologia exigiam a adição de mais destinos do Windows: IoT, Microsoft HoloLens, Surface Hub e futuros membros da família de dispositivos do Windows. O Windows 10 precisava ser um sistema operacional não apenas para Windows, Phone e Xbox, mas também para todas as plataformas futuras.
A Microsoft fez isto. O Windows 10 se tornou o SO de volume reduzido de núcleo único que é executado em cada família de dispositivo. Isso não foi tão simples como Arquivar | Salvar Como. Pessoas inteligentes trabalharam muito para fornecer uma maravilha de engenharia em um período de tempo incrível. O Windows 10 é a única base de código necessária para habilitar a UAP. Cada produto Microsoft a partir deste ponto em diante será escrito junto ao núcleo único que compõe o Windows 10.
Unidade não uniforme A união das bases de código em um único núcleo do sistema operacional não significa uma única interface de usuário em diferentes dispositivos. O Windows Phone tem uma interface inteligente possível de ser usada com apenas uma mão e muito apreciada significativamente diferente da experiência do Xbox de 10 pés (3,05 metros). O mesmo acontece com o Surface Hub, Microsoft HoloLens e Raspberry Pi. Eles oferecem a maior parte de seu valor por meio de suas experiências exclusivas. Ainda assim, o sistema operacional com bibliotecas, tempo de execução e estruturas, é o mesmo. A plataforma do dispositivo e a plataforma do aplicativo são as mesmas. A interface do usuário e recursos do shell, no entanto, são diferentes e ajustados para o modelo de uso correto para cada dispositivo. Eles não são os mesmos.
Em teoria, alguém pode inicializar esse sistema operacional básico e até mesmo executar aplicativos, mas ninguém nunca o fará porque ele é apenas um bloco de construção. Para atender a cada fator forma corretamente, os componentes específicos do shell do dispositivo são adicionados ao núcleo do sistema operacional, como o Menu Iniciar, suporte HID específico e qualquer peças e partes necessárias para habilitar os recursos específicos do dispositivo, como aplicativos da área de trabalho. Esses componentes extras criados a partir do sistema operacional básico para formar os diferentes SKUs do sistema operacional que você vê como produtos Microsoft, como Windows, Server, Xbox e HoloLens.
Plataforma de aplicativo única Aqui está um jogo divertido para brincar com seus amigos. Diga que vai adotar as mais recentes inovações de aplicativos Microsoft, mas não quer ser direcionado para o Windows 10. Como? A próxima geração de aplicativos Windows não tem como destino o sistema operacional. Em vez disso, eles estarão voltados para a plataforma de aplicativo. No Windows, a UAP é um modelo de aplicação consistente e uma superfície de API garantida em cada dispositivo do Windows.
A UAP não é um tempo de execução. Um aplicativo do Windows, mesmo um escrito em uma linguagem gerenciada (como Visual Basic ou C#) compila para o sistema operacional como qualquer outro aplicativo. Ele não é executado dentro de um tempo de execução. Ele não requer um tempo de execução. A UAP é uma superfície de API comum em vários dispositivos, portanto direcionar a UAP é direcionar um conjunto e versão de APIs específico.
Vale a pena salientar que você cria aplicativos e jogos do Windows com as ferramentas e tecnologias que você já conhece. Os aplicativos Windows escritos em linguagens gerenciadas ainda aproveitam o Microsoft .NET Framework, que por si só é apenas um conjunto de interfaces, classes de base e métodos auxiliares. O subconjunto do .NET Framework completo que é usado em aplicativos gerenciados, visando a UAP é chamado de .NET Core. Complementando isso, a maioria das APIs que você pode usar em aplicativos destinados a UAP estão no Tempo de Execução do Windows, que desenvolve em todas as linguagens, não apenas as linguagens gerenciadas.
Não é apenas XAML Esse artigo demonstrará um aplicativo XAML, mas aplicativos DirectX e JavaScript (aplicativos da Web do Windows) também são suportados pela UAP, assim como estavam no Windows 8. Dito isso, é fascinante ver o aspecto emergente do XAML. O XAML é importante para muitas plataformas da Microsoft – Windows Presentation Foundation (WPF), Silverlight no navegador e no Windows Phone e, agora, a plataforma de interface do usuário do Windows (que começou como codinome “Júpiter”).
O Microsoft Office 2016 agora é uma família de aplicativos UAP. Qual a tecnologia de interface do usuário usada? XAML. Graças a essa relação, a plataforma XAML é rica em recursos e controles que a Microsoft e desenvolvedores de terceiros, como você, podem usar em seus aplicativos do Windows.
O shell da área de trabalho do Windows apresenta muitos recursos novos, como o Menu Iniciar e a Central de ações. Qual a tecnologia de interface do usuário usada? XAML. Graças a essa relação, o XAML tem uma atuação excelente, fornecendo recursos de processamento para desempenho de subsegundos se ele for aproveitado.
Quando se trata de XAML, a Microsoft tem tudo incluído. Muitos aplicativos importantes do sistema operacional, como fotos e aplicativos do MSN, como Saúde & e Aptidão física, contam com a plataforma de interface de usuário XAML para fornecer os mesmos recursos avançados que todos os desenvolvedores podem utilizar em seus aplicativos do Windows. O que você vê em aplicativos Microsoft, você também pode fazer. Não é somente a área de superfície da API igual para todos, e sim a plataforma de interface de usuário do XAML.
Valor para os desenvolvedores de Software Não basta escrever um aplicativo que possa ser executado em cada dispositivo. Para agregar valor real aos usuários, seu aplicativo do Windows precisa de aprimoramento em diferentes dispositivos. Graças à capacidade de extensão do UAP, você pode incluir o código específico do dispositivo em um único binário que será executado em cada dispositivo.
Você obtém mais do que um único binário com o UAP, mas também um repositório para tudo: para celular, tablet, desktop e até mesmo aplicativos do Xbox. A experiência é simplificada, a monetização é simplificada e as métricas para monitorar o sucesso de mercado também são simplificadas.
Tanto a Loja quanto a plataforma permitem a implantação de ativos adequadamente. Isso significa que ativos destinados a experiência do Xbox não serão simplesmente empurrados para o celular. E a capacidade do Windows 8 de empacotar ativos destinados a escala e resoluções específicas permanecem no UAP.
Como sempre, você permanece no controle. Só porque o UAP oferece suporte a todos os dispositivos do Windows, não significa que você precisa. Você escolhe qual família de dispositivos de seu aplicativo do Windows terá suporte. Se seu aplicativo do Windows for apenas para celular, apenas para Xbox ou apenas para HoloLens, é bom para você. A Loja do Windows garante que seu aplicativo é entregue às famílias de dispositivos selecionadas por você.
O valor não é somente o alcance mais amplo, mas uma experiência geral mais fácil. Há um conjunto de ferramentas, incluindo o Visual Studio e o Blend para Visual Studio, que você já conhece e gosta. Há um conjunto familiar de linguagens, inclusive JavaScript, o .NET Framework (Visual Basic ou C#) e o C++/CX. No final, você e sua equipe criam aplicativos do Windows usando o que você já conhece.
Muito a considerar
Com muito poder, vem também grande responsabilidade. O UAP permite que os aplicativos do Windows sejam executados em todos os tipos de dispositivos do Windows. Isso é excelente, mas ele vem com uma limitação: Nem todo dispositivo fornece a mesma experiência do usuário. Isso significa que, embora você possa utilizar muitas das mesmas técnicas de design para Web responsivas (RWD) usadas em seus aplicativos Web, você deve considerar como o fluxo de trabalho de aplicativo do Windows é reproduzido em diferentes tipos de dispositivos destinados a diferentes tipos de uso. O UAP só pode habilitar o suporte em diferentes dispositivos. Cabe ao desenvolvedor e ao designer criarem uma experiência do usuário que seja ótima em todos eles.
A Microsoft fornece um amplo conjunto de ferramentas para ajudar a criar aplicativos do Windows ágeis e adaptáveis. O Visual Studio pode simular a taxa de proporção, escala e tamanho durante o tempo de design. O Visual Studio pode simular também (e às vezes emular) os dispositivos específicos destinados, mesmo se você não possui o hardware. Isso permite testar aplicativos do Windows e refinar suas experiências ao longo do caminho.
A caixa de ferramentas XAML tem vários novos controles e aprimoramentos para ajudá-lo a criar interfaces responsivas ágeis e adaptáveis que combinam bem com todos os dispositivos e cada tamanho de tela. Por exemplo, o RelativePanel é novo para os desenvolvedores de XAML. Ele herda do Painel igual a todos os outros controles de layout, como Grade e StackPanel, mas permite que desenvolvedores e designers posicionem elementos filho em relação a outros elementos filho. A árvore visual do XAML resultante é mais simples para renderizar e muito mais simples de manipular em resposta às alterações de layout. Os Estados visuais são outro aprimoramento para desenvolvedores XAML, tornando mais simples responder a alterações no layout.
Isso é importante: Criar um aplicativo do Windows que tem como alvo vários dispositivos não significa escrever para o menor denominador comum. A interface do usuário é rica como também é o conjunto de recursos. A verificação do tempo de execução (usando o namespace Windows.Foundation.Metadata.ApiInformation) permite que você inclua recursos específicos do dispositivo que aprimore seus aplicativos para a melhor experiência do usuário possível em cada dispositivo. Os novos recursos e controles convergidos são os blocos de construção, com os quais você precisa sonhar grande.
Anatomia de um aplicativo do Windows
Agora vamos examinar as técnicas essenciais para criar um aplicativo do Windows que será executado em qualquer família de dispositivos. Pressupomos que você está familiarizado com o desenvolvimento de aplicativos XAML do Tempo de Execução do Windows (WinRT) do Windows 8.1. Os aplicativos Windows são a evolução desses aplicativos. Você encontrará muitos recursos na Microsoft Virtual Academy para aprendizado, que pode ser encontrada em aka.ms/w8learn. Este artigo concentra-se em novos recursos no UAP — para a execução de aplicativos do Windows em famílias de dispositivos.
No Visual Studio 2015, o nó Modelos/Visual C#/Windows Universal na caixa de diálogo Novo Projeto tem vários modelos de projeto: o aplicativo em branco, a biblioteca de classes e o componente do Tempo de Execução do Windows. Você pode usar o modelo de aplicativo em branco para criar um aplicativo do Windows. Os modelos de Biblioteca de classe e componente do Tempo de Execução do Windows permitem encapsular a interface do usuário e a lógica para reutilização em outros projetos. Uma biblioteca de classe oferece suporte a aplicativos não são UAP, mas está limitada a linguagens gerenciadas. Componentes do Tempo de Execução do Windows podem ser compartilhados entre linguagens (incluindo JavaScript e C++ c++ /CX), mas tem regras que restringem a superfície de API pública.
Para este exemplo, escolha o Aplicativo em branco, como mostrado na Figura 2.
.png "Por padrão, os aplicativos do Windows usam o Modelo em branco")
Figura 2 Por padrão, os aplicativos do Windows usam o Modelo em branco
Onde estão todos os outros modelos? Considere o modelo de aplicativo de Hub que acompanha o Windows 8. Foi usado por muitos desenvolvedores. Foi copiado por muitos desenvolvedores. Esse surto de aplicativos "eu também" criaram consistência visual na Loja do Windows, mas não contribuem para a diversidade do ecossistema. Agora, o modelo do Aplicativo em branco está em primeiro plano, encorajando os desenvolvedores a criarem interfaces visualmente consistentes, ainda que diferentes na plataforma. Muitos modelos da comunidade já começaram a aparecer na Galeria do Visual Studio, incluindo um, Template10, que foi escrito pelos autores deste artigo.
**Olá, mundo!**Você criou seu primeiro aplicativo do Windows. Embora a interface do usuário esteja em branco, ela já pode ser executada em todos os dispositivos do Windows. O Gerenciador de Soluções do Visual Studio revela como um aplicativo básico do Windows é simples: um único projeto com um App.xaml e um único arquivo MainPage.xaml para interface do usuário inicial.
A solução inclui outros arquivos de suporte familiares. O Package.appxmanifest declara os recursos que o aplicativo solicitará da máquina do usuário, como a localização do usuário, acesso à câmera e o sistema de arquivos. O esquema XML foi expandido, mas é quase o mesmo que o appxmanifest para aplicativos universais do Windows 8.1.
Onde estão os dois cabeçalhos? Aplicativos universais do Windows 8 precisam de um cabeçalho de projeto para um Phone e um para Windows. O UAP não requer vários cabeçalhos. Em vez disso, você pode adaptar suas interfaces para acomodar para onde quiser que o seu aplicativo do Windows seja executado. Dito isso, você certamente pode criar uma solução com vários cabeçalhos se ela for adequada ao fluxo de trabalho da equipe de desenvolvimento. As duas abordagens são igualmente suportadas.
Incluindo conteúdo Ao abrir o MainPage.xaml, você verá a experiência de tempo de design do Visual Studio XAML aprimorada. O designer é mais rico e mais rápido. A capacidade para simular a taxa de proporção e escala foi melhorada e as próprias ferramentas foram ampliadas. Agora vamos adicionar um pouco de XAML, como mostrado na Figura 3. (Graças ao nosso amigo David Crawford para este exemplo.)
Figura 3 O RelativePanel permite desenhar o layout da interface de uma forma simples
<Grid Background="{StaticResource EggshellBrush}">
<RelativePanel x:Name="PromoArea">
<Image x:Name="BannerImage" HorizontalAlignment="Right"
Height="280" Stretch="UniformToFill"
Source="Assets/clouds.png"
RelativePanel.AlignRightWithPanel="True"/>
<Grid x:Name="BannerText" Margin="24"
Background="{StaticResource BlueBrush}">
<StackPanel Margin="12" HorizontalAlignment="Stretch">
<TextBlock x:Name="Headline" Text="Come fly with us"
Margin="0,-32,0,0" FontSize="48"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource LustScriptFont}" />
<TextBlock x:Name="Subtitle" FontSize="21.333"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource DomusTitlingFont}">
<Run Text="Fly return to London"/>
<LineBreak/>
<Run Text="For only $800"/>
</TextBlock>
</StackPanel>
</Grid>
</RelativePanel>
</Grid>
O código na Figura 3 cria o cabeçalho da página para um aplicativo simples para uma empresa aérea fictícia. Especificamente, ele aproveita o novo RelativePanel em XAML, que permite a reorganização da interface de uma forma simples. O RelativePanel posicionará a imagem do banner à direita da página e contém a grade que contém as ofertas especiais recentes da companhia.
Adicionando alguns ativos O XAML faz referência a três arquivos adicionados à pasta Ativos: um arquivo de imagem, Clouds.png e duas fontes personalizadas, DomusTitlingFont.ttf e LustScriptFont.ttf. As fontes e os recursos do pincel personalizados são declarados em App.xaml:
<Application.Resources>
<SolidColorBrush x:Key="BlueBrush" Color="#FF1C90D1"/>
<SolidColorBrush x:Key="EggshellBrush" Color="#FFFAFFF7"/>
<FontFamily x:Key="LustScriptFont">
Assets/Fonts/LustScriptDisplay.otf#Lust Script Display
</FontFamily>
<FontFamily x:Key="DomusTitlingFont">
Assets/Fonts/DomusTitling.otf#Domus Titling
</FontFamily>
</Application.Resources>
Esses arquivos estão incluídos no download do código que acompanha este artigo.
Observe que a imagem de bitmap está em uma escala. Se você quiser acomodar dispositivos com resolução superior, você pode dimensionar seus ativos e nomeá-los usando o fator de escala apropriado para que todos os usuários obtenham a melhor experiência visual sem baixar ativos para outros fatores de dimensionamento.
Execução em dispositivos De volta ao MainPage.xaml, a interface do usuário está tomando forma. Para executar o aplicativo, você pode selecionar o destino na lista suspensa de dispositivo de destino do Visual Studio. Observe que ele inclui Windows Simulator (para teste de toque), Computador Local, Computador remoto (para testes em ARM) e Dispositivo (hardware de celular real). Os emuladores de celulares estão na mesma lista. Escolha e execute em Computador Local e, depois, em um dos emuladores de celular para ver seu aplicativo do Windows executado em diferentes dispositivos sem quaisquer compilações especiais.
Talvez você tenha percebido que a execução de um aplicativo do Windows no Computador Local, em outras palavras, na área de trabalho do seu PC, é uma experiência em janelas e não a experiência de tela inteira do Windows 8. Isso ocorre porque você está executando seu aplicativo na área de trabalho SKU do Windows 10. O SKU do Windows 10 móvel ainda inicia os aplicativos do Windows em tela inteira para tornar a navegação mais fácil ao toque. Mas, o SKU da área de trabalho do Windows 10 também inicia os aplicativos do Windows em tela inteira se você escolher a experiência de toque por meio da interface de sequência em um tablet ou laptop convertido.
Interfaces adaptáveis Embora o aplicativo do Windows seja executado em ambos os dispositivos, após um exame detalhado a interface do usuário não é muito boa na tela menor do celular. O texto do cabeçalho é muito grande para a tela pequena e será truncado. Este é o início de uma viagem mais longa para testar e melhorar a experiência do usuário na variedade de dispositivos possíveis para esse aplicativo do Windows.
Vamos modificar o layout do cabeçalho quando detectarmos a tela mais estreita do telefone. É importante, no entanto, reconhecer que não é o telefone que está sendo detectado, é a largura da tela. Isso permite uma experiência específica na área de trabalho e o celular.
Observe que não há uma API para detectar um celular. No entanto, como o design deveria exigir a operação com uma só mão específica para o celular e tablets menores, você pode testar o tamanho diagonal do dispositivo físico em um gatilho de Estado Visual personalizado (que não será discutido neste artigo).
Estados visuais não são novidade no XAML. O Gerenciador de Estado Visual permite que desenvolvedores e designers para definam diferentes Estados Visuais (significando layouts de tela diferentes) e alternem entre eles em tempo de execução. Os Disparadores adaptáveis de estado visual são novos com o UAP. Eles acabam com a abordagem programática para alternar Estados Visuais. Em vez disso, você declara quando um Estado Visual deve ser visível em XAML e a plataforma subjacente faz o resto.
Agora, modifique o XAML em MainPage.XAML, como mostrado na Figura 4.
Figura 4 O XAML agora oferece suporte à declaração de regras para adaptação de uma Interface
<Grid Background="{StaticResource EggshellBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="WindowStates">
<VisualState x:Name="NarrowState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="120"/>
<Setter Target="BannerText.(RelativePanel.Below)"
Value="BannerImage"/>
<Setter Target="BannerText.Width" Value="660"/>
<Setter Target="BannerText.Margin" Value="0,0,0,24"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="12"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="MediumState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="660"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="180" />
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="14"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="WideState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1000"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<RelativePanel...
Na Figura 4, observe que há três Estados Visuais declarados: NarrowState, WideState e MediumState. Cada um desses Estados Visuais corresponde a diferentes intervalos de largura da tela. Você pode criar tantos Estados Visuais quantos forem necessários para suportar as famílias dos dispositivos de destino. O nome usado para cada Estado Visual não é significativo.
O XAML também demonstra Setters de Estado Visual, que são novos no UAP e permitem que você defina um valor da propriedade em separado sem a sobrecarga de uma animação de storyboard. Aqui, estamos usando os setters para alterar a posição relativa dos filhos no RelativePanel definindo a propriedade RelativePanel anexada nos elementos filho, e também estamos alterando a altura de BannerImage e FontSize dos elementos de texto. Com os Estados Visuais em vigor, a interface faz um excelente trabalho adaptando para uma tela mais estreita. Experimente e veja!
Figura 5 mostra como a interface do usuário se adapta às alterações na largura da tela. Em seu aplicativo do Windows, você pode tirar proveito dos gatilhos de Estado Visual para ajustar os elementos da melhor maneira que atenda aos usuários.
.png "Adaptação a alteração da largura da tela")
Figura 5 Adaptação a alteração da largura da tela
A versão completa deste exemplo, que está incluído no download do código que acompanha este artigo, desenvolve ainda mais a interface do usuário e fornece exemplos adicionais de uso do RelativePanel e disparadores de Estado Visual para implementar uma interface do usuário adaptável.
Código adaptável A interface do usuário se adapta às telas diferentes, mas diferenças em dispositivos ampliam a mais do que o tamanho da tela. Por exemplo, celulares tem botões de hardware, como Voltar e Câmera, que podem não estar presentes em uma plataforma diferente como um PC. O UAP padrão tem a maior parte das necessidades de aplicativos da superfície de API do Windows, mas a funcionalidade específica do dispositivo é desbloqueada com SDKs de extensão que você adiciona aos projetos como assemblies externos, como mostrado na Figura 6. Elas permitem um conjunto mais amplo de funcionalidades específicas de dispositivos sem invalidar a capacidade de seu aplicativo ser executado em outros tipos de dispositivos.
.png "Adicionar uma extensão é tão simples quanto adicionar uma referência de projeto")
Figura 6 Adicionar uma extensão é tão simples quanto adicionar uma referência de projeto
As duas plataformas mais comuns de SDKs de extensão são as extensões de Desktop e Móvel, que permitem recursos exclusivos para os respectivos SKU do Windows. A extensão Móvel, por exemplo, habilita as APIs necessárias para usar o botão de câmera do hardware.
O SKU do Windows Mobile pode ser executado em celulares e tablets pequenos. No entanto, nem todos os tablets (nem mesmo todos os celulares) têm um botão de câmera de hardware. SDKs de extensão habiltam o suporte do botão, mas não colocam botões no dispositivo. Como resultado, em tempo de execução, você deve testar para recursos do dispositivo antes de invocar os recursos do SDK de extensão.
Assim como SDKs de extensão de plataforma, como Móvel e Desktop desbloqueiam os recursos de dispositivos para aplicativos do Windows, os SDKs de extensão personalizada adicionam suporte para componentes adicionais, como o Kinect para Windows ou hardware de terceiros. Isso, também, não impede o seu aplicativo de ser executado em outros tipos de dispositivos.
Como verificar por recursos do dispositivo? Utilize os métodos na classe Windows.Foundation.Metadata.ApiInformation que retornam um valor booliano simples se um tipo ou método tem suporte no dispositivo atual. Você pode habilitar seu aplicativo do Windows para usar o botão da Câmera com um código como este:
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(
"Windows.Phone.UI.Input.HardwareButtons"))
{
Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
HardwareButtons_CameraPressed;
}
Observe como o código de Windows.Phone.UI.Input.HardwareButtons pode ser executado apenas se o SDK de extensão estiver habilitado no dispositivo. Ao contrário em condicionais de compilação, os testes de recursos não resultam em vários binários. Isso significa que você pode aprimorar ou fazer o downgrade normalmente da experiência do usuário de acordo com os recursos do dispositivo atual. Essa é uma abordagem eficiente para habilitar um único binário. Ela cria variabilidade ilimitada, permitindo que você aproveite ao máximo seus aplicativos do Windows em famílias de dispositivos diferentes.
Conclusão
Se você estiver familiarizado com o desenvolvimento de aplicativos universais para Windows 8, então, criar aplicativos do Windows visando o UAP deve parecer como cozinhar em casa. Aplicativos do Windows não se destinam ao Windows 10. O UAP é o destino e ele será desacoplado do SKU do Windows. O UAP incrementa versões em uma cadência além do Windows. Isso significa que aplicativos do Windows não precisarão ser redirecionados toda vez que o sistema operacional Windows tenha sua versão alterada. Os Aplicativos do Windows se destinam a uma ou mais versões UAP e testam para esses recursos exatamente como eles testam para recursos do dispositivo. Essa abordagem flexível oferece uma maneira simples e limpa para aproveitar os recursos futuros.
Criar um aplicativo do Windows significa que o seu aplicativo pode ser executado em qualquer dispositivo do Windows. Este presente vem com uma limitação do mundo real: O UAP pode executar seu aplicativo, mas somente os desenvolvedores e designers podem tornar a interface do usuário e o código adaptado para oferecer a melhor experiência de usuário possível. Se você quiser criar binários específicos do dispositivo separados, você pode fazer isso. Mas, se você optar por criar um aplicativo do Windows que ofereça suporte a vários tipos de dispositivos, todas as ferramentas e infraestrutura estão em um lugar e prontas para você ter sucesso.
Jerry Nixon é um desenvolvedor e divulgador da Microsoft do Colorado. Nixon ensina e fala sobre o Windows, desenvolvimento de área de trabalho e celular. Sua carreira iniciada com o Microsoft SQL Server 6.5, oferece soluções centradas em dados com um termo novo para "desenvolvedores de banco de dados". Ele recebeu um Comenda Naval para civis pelo trabalho de segurança, que precede o seu trabalho para a startup que se tornaria a Microsoft CRM. Por 15 anos, Nixon cria soluções móveis centradas na Microsoft. Atualmente, ele fala sobre XAML e mobilidade em eventos, comunidades e universidades e a maior parte de seu tempo livre é gasto ensinando suas três filhas as histórias dos personagens e enredos de episódios de Star Trek.
Andy Wigley é um desenvolvedor e divulgador da Microsoft do Reino Unido. Ele ingressou na Microsoft em 2012 e antes trabalhou como consultor e era membro proeminente da comunidade dos desenvolvedores de aplicativos móveis. Ele foi orgulhosamente denominado como um Microsoft Most Valuable Professional (Profissional mais importante da Microsoft - MVP) por 10 anos consecutivos. Wigley é conhecido pelos vídeos do ponto de partida do Windows Phone populares que estão disponíveis em channel9.msdn.com e está feliz por estar trabalhando com Jerry Nixon em uma série de vídeos de acompanhamento no desenvolvimento de aplicativos do Windows.