Aplicativos modernos

Criar uma arquitetura de aplicativos modernos em várias plataformas

Rachel Appel

Quer você esteja criando um projeto do zero ou modificando uma solução existente, é importante conhecer o cenário dos aplicativos modernos. Isto significa diferenciar quais dispositivos, sistemas operacionais e navegadores estão disponíveis e precisam de atenção. E o item "dispositivos" não apenas significa smartphones, ou inclui tablets, PCs e telas grandes de computadores de mesa. No entanto, a venda de smartphone continua excedendo as vendas de todos os dispositivos. Alguns desenvolvedores talvez até tenham de considerar dispositivos portáteis como parte de sua arquitetura de várias plataformas.

O resultado final é que a gravação de software estes dias significa gravar para uma variedade de dispositivos. O objetivo principal é compartilhar o máximo de códigos possível entre várias plataformas para que você escreva a quantidade mínima de códigos. Isto ajudará você a ter o produto ou aplicativo enviado mais rapidamente. Além disso, estará menos propenso a bugs causados por reescrever a mesma lógica em linguagens diferentes.

Desenvolvimento de dispositivos entre plataformas

A maneira pela qual você aborda o desenvolvimento entre plataformas dependerá do tipo de software que você já tem em vigor. Se você tem um site de qual deseja compartilhar conteúdo, uma solução híbrida pode ser melhor. Se for um site maduro, você pode convertê-lo para um design com capacidade de resposta e dispositivos móveis com suporte. Você pode abandonar o site móvel totalmente e simplesmente fornecer um site e separar aplicativos nativos correspondentes. Outros fatores para considerar se o aplicativo é apenas outra maneira de apresentar o conteúdo do site ou se ele pode permanecer autônomo como sua própria ideia.

Compile primeiro seu site móvel e depois compile os aplicativos nativos. Enquanto você desenvolve os aplicativos nativos, o site móvel pode servir como o aplicativo até você ter abordado todas as plataformas. Estes com os sites já em funcionamento podem precisar usar aquele conteúdo e função de forma nativa para cada dispositivo. Você pode continuar a aumentar a sua base de usuários móveis enquanto desenvolve aplicativos nativos desta maneira. Quando você estiver pronto para escrever aplicativos nativos, talvez você precise de ajuda para decidir qual linguagem usar, então certifique-se de verificar a minha coluna de setembro de 2013, "Compreendendo as opções de linguagem para o desenvolvimento de aplicativos modernos" (msdn.microsoft.com/magazine/dn385713).

Enquanto é uma noção popular começar a desenvolver a maior plataforma ou aquela com as maiores vendas de dispositivos, às vezes é uma melhor decisão de negócios começar com a plataforma que tem recursos sendo executados paralelamente aos seus requisitos. Por exemplo, um aplicativo de aptidão que registra alimentos e exercícios pode ter um requisito de mostrar um resumo de suas refeições e atividades; o myFitnessPal é um bom exemplo disto no Windows Phone. Este tipo de dados é perfeito para um Live Tile, que está disponível apenas na plataforma do Windows.

Você pode descobrir se os seus requisitos correspondem a plataforma, listando todos os recursos dos aplicativos principais. Examine cada um verificando se tem suporte em cada plataforma e possivelmente até que ponto. Onde você verá que as divergências estão com os recursos específicos do hardware, como os recursos de câmera ou do sistema operacional como blocos ou reconhecimento de voz. As suas opções de arquitetura a partir de uma visualização de 9144 m (30.000 pés) levou você a ir em uma das três direções: aplicativos nativos, aplicativos híbridos ou Web móvel HTML5.

Nativo Isto significa prosseguir com toda a força em um aplicativo separado para cada plataforma. As plataformas provavelmente são do Windows Phone 8, iOS e Android. Para alguns, as plataformas como o BlackBerry ainda são aplicadas. Cada aplicativo aproveitará totalmente os recursos específicos que cada plataforma individual fornece. O desempenho do aplicativo nativo é ótimo, mas você deve se lembrar de escrever um código sólido e limpo, visto que o desempenho degrada rapidamente quando você não tem consciência. Você terá de escrever pelo menos a interface de usuário do aplicativo nativo individualmente para cada plataforma, assim o custo por plataforma aumenta e passa a ser a mais cara de todas estas opções.

Híbrido Em algum lugar naquela área cinza entre o nativo e a Web está o aplicativo híbrido. Os aplicativos híbridos geralmente integram conteúdo de um site existente em um aplicativo para a implantação e empacotamento nativo. Isto é especialmente útil para proteger rapidamente um slot em qualquer das lojas de aplicativos e ter a presença aqui, talvez enquanto estiver trabalhando em um aplicativo nativo completo para aquela plataforma. O desempenho é especialmente mais lento do que com aplicativos da Web e nativos, visto que os aplicativos híbridos são geralmente construídos ao envolver um HTML existente com um contêiner. Por exemplo, no Windows Phone, este é um controle WebBrowser. Sempre que houver uma camada extra, há também o potencial para problemas de desempenho.

A desvantagem, no entanto, é a implementação acelerada em uma plataforma nativa. Criar aplicativos híbridos exige que você use qualquer uma das seguintes ferramentas:

• Apache Cordova/PhoneGap
• Modelo de projeto do Visual Studio Windows Phone HTML5
• Telerik AppBuilder (anteriormente Icenium)
• Xamarin Studio

Devido sua natureza, os aplicativos híbridos envolvem conteúdo da Web usando o controle WebBrowser (mantendo o exemplo do Windows Phone), que é um elemento XAML:

<phone:WebBrowser x:Name="Browser"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch"
Loaded="Browser_Loaded"
NavigationFailed="Browser_NavigationFailed" />

Isto é tudo que você precisa para começar a criar um aplicativo híbrido. Em outras plataformas, os conceitos são os mesmos, embora os controles possam ser diferentes. Tenha cuidado ao criar aplicativos híbridos, já que eles podem não ter acesso ou privilégios para executar ações que um aplicativo nativo executaria. Isto é devido ao potencial para o script não autorizado da Web para executar no cliente. É por isso que os aplicativos HTML têm muitas das mesmas restrições.

Quando você cria aplicativos híbridos, você pode usar o Telerik AppBuilder ou Apache Cordova no lugar dos projetos do Visual Studio. Estas ferramentas de terceiros ajudam a fechar as lacunas entre o percepção da Web híbrida e uma aparência nativa de seu aplicativo.

HTML5 O benefício de escolher este caminho é a ampla disponibilidade imediata que a especificação do HTML5 traz para a tabela. Os sites da Web móvel podem ter um longo alcance, mas não têm a aparência nativa que os usuários querem ou que normalmente esperariam dos aplicativos nativos. Além disso, um aplicativo HTML5 pode não conseguir acessar alguns recursos específicos do hardware de sua plataforma de destino, como o Webcam ou acelerômetro.

O HTML5 tem o custo mais baixo por plataforma, já que você deve ser capaz de escrever uma vez e executar na maioria dos navegadores. Alguns navegadores móveis, no entanto, não estão atualizados com os suporte padrão. O que pode ser um grande problema ao desenvolver aplicativos em HTML5. Se os recursos nativos são importantes para o seu projeto, a falta de acesso nesta área pode determinar se você irá totalmente com os aplicativos nativos.

Enquanto o HTML5 ostenta uma ampla disponibilidade, tenha em mente que em um sentido, desenvolver para a Web é semelhante a desenvolver aplicativos nativos. Você precisa se preocupar em oferecer suporte a um número de navegadores. Como o desenvolvimento de dispositivo, os desenvolvedores da Web têm como objetivo estes navegadores com a maioria dos usuários—Internet Explorer, Chrome, FireFox e Opera.

Você deseja criar UXes ricas do lado do cliente em vários dispositivos e você não pode reutilizar um código de dispositivo específico. É improvável que os seguintes recursos nativos se comportem consistentemente ou estejam disponíveis entre as plataformas:

• Notificações push
• Wallet
• Near Field Communication (NFC)
• Multitarefa/multithreading
• Speech
• Esquemas de navegação
• Caixas de Diálogo

Nos aplicativos clientes híbridos ou HTML5, não dependa do acesso a estes atributos específicos do nativo. Se recursos como estes fazem parte dos seus requisitos de aplicativos, você precisará ir pelo caminho todo nativo.

Soluções entre plataformas do Architect

Determinar para quais plataformas você oferecerá suporte é apenas uma decisão no cenário de aplicativos. Você também deve projetar a solução e levar em consideração coisas como o tempo para colocar o produto no mercado e para qual plataforma desenvolver primeiro. Como compartilhar o máximo possível de códigos entre aplicativos é também uma importante consideração.

Os serviços da Web back-end e as APIs funcionam bem em um cenário de plataforma cruzada, pois todas as plataformas oferecem suporte ao HTTP. Usando camadas de serviços no back end significa que você precisa apenas escrever o código para estes serviços uma vez.

Quanto à expansão da arquitetura para focar no cliente, você desejará compartilhar o máximo de códigos possível. Você pode criar um código facilmente no Windows 8 e Windows Phone com Bibliotecas de Classes Portáteis (PCLs), mas isso deixa de fora outras plataformas como a Android e iOS. Você pode compartilhar códigos no Windows 8, Windows Phone, Android e iOS ao escrever no C# e usar as ferramentas Xamarin para compilar.

O ponto de se tornar nativo é que, desta maneira, os usuários podem obter a mesma aparência que a plataforma nativa. Enquanto ferramentas como Xamarin permitirão que você compartilhe alguns códigos na camada de interface do usuário, você obterá os melhores resultados de UX se você criar cada interface de usuário separadamente. Isto geralmente significa modificar o código Xamarin gerado. É uma boa hora para adicionar quaisquer recursos específicos da plataforma, assim os usuários em cada plataforma obtêm uma experiência personalizada.

A camada do código do aplicativo mapeia para as partes do controlador ou do ViewModel dos padrões Model-View-Controller (MVC) ou Model-View-ViewModel (MVVM). A camada da interface do usuário mapeia para o View tanto no MVC e MVVM. O Model, claro, é a representação de dados. Estas podem ser classes do JavaScript que mapeiam os objetos de banco de dados no Armazenamento Local, ou elas podem mapear os esquemas remotos de volta para o banco de dados. Os dados locais não são algo que você normalmente compartilharia entre os dispositivos, já que geralmente inclui informações específicas do dispositivo.

O caminho com menos resistência em criar uma solução é começar com as camadas back-end primeiro, depois criar um site, em seguida, criar aplicativos. Desta maneira, você obtém algo fora para a mais ampla gama possível. No lado dos aplicativos, você precisará determinar qual criar primeiro e se algum deverá ser sua plataforma primária.

Gosto da plataforma do Windows 8/Windows RT/Windows Phone e penso que ela (especialmente o Windows Phone) tem a melhor UX de todos os dispositivos disponíveis. Isto não é somente porque já trabalhei para a Microsoft. Eu acho que o iPhone tem uma boa UX também. Recursos como Blocos e câmeras topo de linha da Nokia são motivos convincentes para fazer do Windows Phone a plataforma de recursos para qualquer um que precise desse tipo de funcionalidade em um aplicativo. Além disso, o Windows Phone gerencia e mescla diretamente seus contatos, calendário e outros dados importantes por meio de dispositivos baseados no Windows com os aplicativos de calendário e pessoas baseados na nuvem e integrados.

Conclusão

Com o advento do movimento BYOD (Traga seu próprio dispositivo) em locais de trabalho em todos os lugares, o desenvolvimento de aplicativos nativos tem ser tornado um lugar comum. Como você pode ver, há muitas variáveis e coisas a considerar ao criar aplicativos que podem afetar o seu sucesso. A menos que você esteja trabalhando para uma corporação que exige um cliente desktop padrão, eu não aconselho isso. Isto equivale a não ser o primeiro aplicativo naquela plataforma.

Se você tem um orçamento generoso e pessoal, mais um intervalo de tempo prolongado para criar sua solução, você pode criar um site com uma versão móvel e um conjunto completo de aplicativos nativos. Isso significa que você está fornecendo todas as maneiras possíveis para acessar seus serviços e dados. Claro que, este caminho é o mais trabalhoso e mais caro.

Rachel Appel é consultora, autora, mentora e antiga funcionária da Microsoft com mais de 20 anos de experiência no setor de TI. Ela dá palestras em importantes congressos do setor, como o Visual Studio Live!, o DevConnections, o MIX e muitos outros. Sua experiência está ligada a soluções de desenvolvimento que alinham negócios e tecnologia com foco na pilha de desenvolvimento da Microsoft e em Web aberta. Para obter mais informações sobre a Appel, visite seu site em rachelappel.com.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Frank La Vigne (Microsoft) e Wally McClure (Scalable Development)