Xamarin Forms, MVVMCross e SkiaSharp: A Santíssima Trindade do desenvolvimento de aplicativos multiplataforma

Fale sobre estabelecer altas expectativas. A santíssima trindade, nada menos!

A verdade é que o desenvolvimento de aplicativos móveis é caro quando você segmenta várias plataformas, porque não há código compartilhado. A Apple exige que você codifique em Objective-C ou Swift, o Android exige que você codifique em Java e o WinPhone exige que você desenvolva em .NET, geralmente C#. Acrescente a isso a infinidade de bibliotecas que cada plataforma fornece para lidar com mapas, desenhos, imagens ou GPS – uma enorme quantidade de tempo e conhecimento é necessária para criar um único aplicativo móvel.

Desnecessário dizer que a maioria das startups não pode se dar ao luxo de triplicar suas despesas, e mesmo as empresas estabelecidas podem ter dificuldade em justificar o preço de entrada no espaço móvel.

Neste artigo, você aprenderá como o Xamarin Forms, em combinação com MVVMCross e SkiaSharp, pode ser uma maneira viável de criar aplicativos móveis multiplataforma sem comprometer a familiaridade, o desempenho e a exclusividade. O artigo revisará essas três tecnologias e como elas podem reduzir o custo de desenvolvimento, permitindo a reutilização máxima de código em várias plataformas móveis.

Um problema importante

A questão do desenvolvimento de aplicativos móveis multiplataforma é real e, como tal, muitas soluções diferentes surgiram ao longo dos anos para reduzir os custos de desenvolvimento compartilhando código entre plataformas. Na indústria de videogames, por exemplo, todos os principais mecanismos de jogos fornecem uma solução multiplataforma, com até mesmo Unreal e Unity visando telefones celulares e tablets.

Na frente do aplicativo, houve várias tentativas de liderar esse mercado multiplataforma ao longo dos anos. Muitos ficaram aquém e foram perdidos no abismo, mas alguns deles ainda sobrevivem depois de vários anos. Entre eles está o Xamarin, a única solução .NET que oferece suporte para todas as três plataformas móveis.

Nativo ou não, aqui vou eu

Portanto, há uma guerra travada entre diferentes soluções e quem diz que guerra significa propaganda!

A guerra é travada principalmente na frente do grande N : ser nativo! Você precisa ter cuidado com a palavra porque ela não tem um significado claro. É a palavra mais usada no mundo do desenvolvimento mobile hoje em dia e está muito na moda. A verdade é que ninguém concorda com o que realmente significa.

Ao selecionar um framework multiplataforma, todas as opções “nativas” não são iguais, então cuidado, você pode estar comparando maçãs com laranjas. Para alguns é sobre a linguagem de programação, para outros é sobre poder usar os recursos de hardware, outros pensam que é sobre o uso de APIs/UI da plataforma e, muitas vezes, trata-se apenas de não ser um aplicativo da web.

Há argumentos de todos os lados do debate e não vou me aprofundar porque é inútil. Por que é inútil? Bem, deixe-me contar um fato difícil de engolir: seus usuários finais não se importam!

Sim, você leu certo, apenas seus programadores se importam. Seu usuário final nunca escolherá seu aplicativo por causa da tecnologia subjacente: ele escolherá seu aplicativo porque ele responde ao problema e oferece uma boa experiência.

Então, em vez de brigar pelo significado de uma palavra, vamos ver como o Xamarin fornece uma maneira eficiente de dar aos usuários o que eles se importam.

O Pai, o Filho e o Espírito Santo

Antes de prosseguirmos, vamos apenas esclarecer os três elementos que compõem nossa solução para o problema de desenvolvimento multiplataforma.

O Pai: Xamarin

Como mencionado anteriormente, o Xamarin é uma solução .NET para desenvolvimento de aplicativos móveis e de desktop. Foi comprado pela Microsoft em 2016, mas datado de cerca de quatro anos atrás com o projeto Mono. Atualmente, possui três soluções: Xamarin.iOS, Xamarin.Android e Xamarin.Mac. As demais plataformas já lidam com aplicativos .NET por padrão, sendo soluções da Microsoft. Resumindo, o Xamarin oferece um link direto para APIs de plataforma em .NET. Você pode, portanto, usar recursos nativos de um aplicativo .NET. Há também um módulo de extensão para Xamarin chamado Forms que fornece uma camada de abstração para a interface do usuário.

O Filho: SkiaSharp

SkiaSharp é um .NET wrapper sobre a biblioteca de gráficos vetoriais Skia do Google. Skia é o mecanismo de renderização nativo do Android, Chrome, ChromeOS e Firefox. Com o SkiaSharp, você pode usar a biblioteca em seu aplicativo .NET para torná-lo multiplataforma. Isso significa que a sombra pura que seu designer diz “tornará seu aplicativo muuuuito melhor” pode ser codificada apenas uma vez, em vez de ser repetida para cada plataforma de destino. Pessoalmente, acho que seu melhor recurso é a capacidade de renderizar gráficos SVG de uma maneira que permite evitar a duplicação dos vários fatores de forma, mantendo uma renderização nítida e perfeita em pixels.

O Espírito Santo: MVVMCross

Para manter tudo bem separado e frouxamente acoplado, nossa solução santificada contará com o MVVMCross. Este framework implementa uma infraestrutura MVVM (Model-View-ViewModel) para que tudo possa ser mantido independente. Sem ficar muito técnico, os aplicativos geralmente são divididos em três partes:

1. O Modelo: Uma representação de memória de nossos dados
2. The View: Nossa UI, apresentando os dados e ações aos usuários
3. O ViewModel: A camada que liga nosso Model ao nosso View e vice-versa

Na engenharia de software, sempre nos esforçamos para manter a visualização separada do ViewModel para que a lógica do aplicativo (no ViewModel) possa ser reutilizada mesmo se alterarmos a representação visual. O MVVMCross nos ajuda a conseguir exatamente isso, manipulando vinculações de dados e fornecendo padrões e ferramentas para abstração de plataforma.

Com o que os usuários finais se importam

Apenas para recapitular, existem coisas diferentes que diferenciam os aplicativos de sucesso dos ruins. Um aplicativo de sucesso:

1. Resolve um problema da vida real
2. Oferece uma experiência agradável

O ponto número 1 obviamente não tem nada a ver com a estrutura que você escolher. Então, vamos nos concentrar no ponto número 2. Existem três aspectos principais que contribuem para a diversão do seu aplicativo:

1. Familiaridade
2. atuação
3. Singularidade

Familiaridade

A familiaridade está relacionada à facilidade de uso e à rápida busca pelo aplicativo.

Em outras palavras, trata-se de usar os diferentes paradigmas de interface do usuário da plataforma de maneira coerente em todo o sistema. Por exemplo, coisas simples como posições de botões, ações de contexto de lista ou navegação contribuem para a familiaridade do seu aplicativo.

A familiaridade é o principal ponto fraco de aplicativos web ou frameworks baseados em uma interface web. O Xamarin Forms, por outro lado, fornece mapeamentos de plataforma cruzada para elementos de interface do usuário fornecidos pelo fornecedor.

Seus usuários, portanto, obtêm uma experiência que está de acordo com a aparência geral da plataforma, para que se sintam intuitivamente à vontade em seu aplicativo.

atuação

Francamente, mencionar “nativo” em sua propaganda de marketing não significa nada. Tome Jasonette como um exemplo que é “nativo sobre HTTP”. A interface do usuário é armazenada em um servidor web… olá, ida e volta e lentidão, então vemos que nativo não pode necessariamente implicar em melhor desempenho!

Portanto, com esse mito fora do caminho, ao analisar os benchmarks da vida real, o Xamarin se apresenta como a solução mais completa em relação ao desempenho. Xamarin Forms, não exigindo consideravelmente mais alternâncias de contexto, oferece desempenho comparável aos aplicativos de idioma nativo.

Minha conclusão é que suas escolhas de implementação são o que pode tornar seu aplicativo mais lento, em vez de Xamarin versus idioma nativo. Outras opções estão em clara desvantagem em relação ao desempenho.

Singularidade

A possibilidade de seus designers criarem um aplicativo com aparência única também é muito importante a ser considerada se você deseja fornecer a melhor experiência possível ao usuário e diferenciar seu aplicativo.

Muitas vezes, a exclusividade implica a criação de controles, animações ou gestos personalizados. Quando não estiver prontamente disponível no Xamarin, você pode usar o SkiaSharp (um wrapper em torno da biblioteca de renderização de gráficos vetoriais Skia do Google) e aproveitar o conceito de renderizador personalizado do Xamarin Forms para chegar o mais próximo possível do hardware, enquanto sempre codifica em um único linguagem, algo que as outras soluções não podem oferecer.

O que você cuida como um negócio

Neste ponto, você provavelmente está pensando que a escolha do framework também é uma decisão de negócios. Além de fatores fora do escopo deste artigo, como disponibilidade de recursos humanos, o Xamarin tem muito a oferecer, especialmente quando acoplado ao MVVMCross. Vou elaborar quatro aspectos que você vai querer considerar em sua decisão:

1. Preço e custos de desenvolvimento
2. Reutilização de código
3. Disponibilidade de componentes
4. Apoio e comunidade

Preço e Custos de Desenvolvimento

Vamos tirar isso do caminho. Desde o início deste ano, o Xamarin é gratuito para freelancers e pequenas empresas como startups (com o Visual Studio Community Edition). Para organizações maiores, ele vem “gratuitamente” com uma licença do Visual Studio que você já deve ter. Xamarin Forms, MVVMCross e SkiaSharp também são gratuitos e de código aberto!

Como já mencionei, seguir a rota .Net com o Xamarin permite desenvolver seus aplicativos em uma única linguagem do começo ao fim. A maioria das outras soluções exigem que seus programadores conheçam diferentes idiomas. No caso do Cordova, por exemplo, você precisa ser fluente não apenas em HTML, Javascript, CSS, mas possivelmente em Objective-C, Java e/ou C# se precisar acessar APIs de fornecedores que não tenham um plugin disponível .

A variedade de linguagens usadas faz com que haja mais trocas de contexto e mais ferramentas para dominar, levando à diminuição da eficiência. O Xamarin, por outro lado, é uma solução completa: no Visual Studio você cria, implanta e depura em todas as plataformas.

Embora não esteja diretamente relacionado ao Xamarin, você também obtém muitos recursos em C# que aceleram o desenvolvimento escolhendo a solução .Net. Ou seja, você se beneficia dos ótimos recursos do C# 4.5+, como multi-threading fácil com async/await, closures e reflection, todos os quais demonstraram melhorar a eficiência.

Reutilização de código

Você provavelmente já pensou em reutilização de código e provavelmente considera todas as soluções equivalentes a esse respeito. Desculpe dizer amigo, mas você está errado!

Os programadores entre vocês devem ter se perguntado por que diabos eu proporia o uso do MVVMCross sobre a camada MVVM que está incorporada ao Forms? Bem, aqui está algo a considerar: você está realmente apenas criando aplicativos para dispositivos móveis?

Ao isolar a lógica do seu aplicativo com o MVVMCross e usar a inversão de controle que ele fornece, você pode reutilizar uma quantidade máxima de código em dispositivos móveis, mas também em Windows e Mac (porque o Xamarin.Mac é seu amigo).

Isso não apenas economizará dinheiro, mas também apresentará boas práticas de engenharia que reduzirão seus custos de manutenção de código.

Disponibilidade de componentes

Talvez você não seja como eu, mas eu odeio reinventar a roda. Portanto, ter acesso a componentes existentes que você pode integrar facilmente em seu aplicativo é crucial para acelerar seu tempo de lançamento no mercado e, muitas vezes, reduzirá seus custos ao mesmo tempo.

Escolher o Xamarin e o MVVMCross oferece duas opções para escolher os componentes existentes. Primeiro, mais e mais componentes estão disponíveis para Xamarin com ou sem Forms. O Xamarin tem um Component Store integrado ao Visual Studio, onde você pode encontrar várias soluções para problemas comuns de aplicativos e outras empresas vendem diretamente, portanto, pesquise antes de começar a escrever seus próprios componentes (ou considere vendê-los assim que forem criados).

Em segundo lugar, você desejará pesquisar pacotes Nuget porque é provável que alguém já tenha escrito o código para fazer o que você precisa. Entre esses pacotes, você encontrará uma lista decente de plugins MVVMCross multiplataforma que resolverão problemas comuns como e-mail, GPS ou localização.

Se você já tem experiência com C#, provavelmente tem seus componentes preferidos. Claro, você não quer deixá-los ir, eles se sentem tão confortáveis. Fique tranquilo, você pode criar associações em C# para componentes existentes e usá-los como se fossem empacotados com o Xamarin, mesmo em formulários com um pouco de ajuda de renderizadores personalizados.

Falando nisso, você pode querer dar uma olhada no repositório Github de associações do Xamarin antes de criar o seu próprio.

Suporte e Comunidade

Finalmente, o acesso a suporte e exemplos é um fator muito importante na escolha de um framework. O Xamarin já existe há algum tempo, então a comunidade está em um tamanho muito bom hoje.

Procurar informações no Google geralmente resulta em um bom número de respostas (dica: tente também suas pesquisas por monotouch e monodroid, os ancestrais do Xamarin) e o Xamarin oferece muitos exemplos e ótima documentação em seu site.

Além disso, como o Xamarin realmente é apenas uma ligação sobre as APIs do fornecedor, a documentação da Apple e do Google é sempre relevante e responderá a muitas de suas perguntas. Você pode então criar seu próprio serviço MVVMCross para abstrair as APIs do fornecedor dentro do seu código compartilhado.

Quanto ao futuro do Xamarin, com sua aquisição em março passado pela Microsoft, minha aposta é que não vai a lugar nenhum, exceto para frente. Desde essa venda e a mudança correspondente para um modelo gratuito, a comunidade só cresceu, o suporte melhorou e o produto continuou melhorando, possivelmente até em um ritmo mais rápido!

O futuro parece brilhante para o Xamarin.

Vamos nos preparar para fazer barulho!

Estou ciente do fato de que posso estar abrindo uma lata de vermes com este artigo. Agora, não me entenda mal, existem outras opções que valem a pena considerar e convido você a fazê-lo, porque minhas preocupações podem não ser as mesmas que as suas.

Lembre-se de que, se você tiver um cronograma de seis semanas e quatro meses depois ainda não tiver um aplicativo pronto, não estará ganhando. Isso deixaria dois meses e meio e muito dinheiro para treinar alguém internamente ou contratar alguém experiente. Insistir em construir um aplicativo “nativo” nesse ponto pode ser bastante prejudicial para o destino do seu projeto.

O Xamarin e essas tecnologias complementares fornecem exatamente o que seus usuários se importam e o que você precisa. Espero que este artigo o ajude a tomar uma decisão bem informada sobre a estrutura que você pode escolher para seu próximo aplicativo móvel.