Opções diferentes

Quando desenvolvimento de softwareSeja para um projeto divertido ou para um projeto comercial formal, um requisito pode ser atendido por muitas opções e tecnologias diferentes. Depois de algum tempo observando muitas delas, é natural pensar em qual é a melhor opção para o requisito.

Vamos considerar as opções para criar um aplicativo móvel.

Às vezes, a melhor opção é determinada pela compatibilidade entre as implicações da opção e os pontos fortes técnicos da equipe de desenvolvimento. (Abordarei as implicações um pouco mais tarde) A primeira opção a ser considerada ao criar um aplicativo móvel são os aplicativos nativos, mas isso gera imediatamente um alerta: quando o código para uma plataforma estiver pronto, ele precisará ser transcrito para outra plataforma. Em segundo lugar, cada tecnologia nativa tem suas próprias implicações. Portanto, para ter uma experiência móvel bem-sucedida em todas as plataformas nativas, é necessário um desenvolvedor para cada plataforma.

Mesmo que houvesse um desenvolvedor para cada plataforma, vale a pena desenvolver um aplicativo móvel nativo para cada plataforma em vez de modificar uma página da Web para que ela possa ser visualizada em qualquer dispositivo? Essa é uma questão importante a ser considerada, portanto, aqui está um gráfico de comparação das principais características.

Com base nessa comparação, parece que um aplicativo nativo oferece uma gama maior de opções de criatividade e serviço. Se a equipe de desenvolvimento lidar com todas as implicações para cada plataforma, pode ser uma boa ideia desenvolver um aplicativo móvel nativamente para cada plataforma, considerando que os aplicativos nativos têm o melhor desempenho e supondo que a empresa esteja disposta a pagar um custo mais alto.

Vamos falar mais sobre essas "implicações".

Implicações

Ao lidar com estruturas de software e APIs, cada estrutura funciona naturalmente com o programador, pelo menos interagindo com (em outros casos, dominando) determinadas tecnologias ou linguagens de programação. Isso ocorre naturalmente se a estrutura for uma extensão de outra tecnologia.

Por exemplo, considere o Node.js, um tempo de execução de JavaScript. Ao usar o Node.js, por ser um tempo de execução de JavaScript, o código será naturalmente programado em linguagem JavaScript. Portanto, trabalhar com a estrutura do Node.js implica que o programador conhece, ou pelo menos pode interagir com, a linguagem JavaScript. Chamaremos essa dependência de estrutura de implicações.

Veja a seguir algumas implicações para algumas estruturas de aplicativos móveis.

Há outro custo que não é visível à primeira vista. Embora os diferentes projetos de plataforma tenham o mesmo núcleo e a mesma lógica, em última análise, eles são projetos individuais. Cada projeto tem uma linguagem, um ciclo de vida de aplicativo e SDKs diferentes, portanto, cada projeto também precisará de manutenção especializada. Tudo isso pode se acumular. Se a criação do aplicativo nativamente parecer muito cara ou se a equipe de desenvolvimento não conseguir lidar com todas as implicações, outra estratégia poderá ser usada.

O uso de uma tecnologia de plataforma cruzada tornou-se muito popular como uma solução híbrida para o desenvolvimento móvel, de modo que você pode escrever um conjunto de códigos que pode ser usado em várias plataformas e proporcionar ao usuário uma experiência nativa. Há muitas tecnologias de aplicativos móveis multiplataforma, cada uma com suas próprias implicações. A estratégia é escolher uma tecnologia que tenha uma implicação que a equipe de desenvolvimento domine, além de outra consideração. Como se trata de plataforma cruzada, é importante escolher uma solução que tenha uma grande porcentagem de código de transcrição; o código que pode ser escrito uma vez e executado nativamente em todas as plataformas.

Minha experiência

Quando decidi que queria desenvolver aplicativos móveis, meu primeiro pensamento foi: "Quais tecnologias nativas eu conheço?"

Eu tinha usado Objective-C para um aplicativo iOS. Se eu quisesse criar um aplicativo nativo para Android ou Windows Phone, teria que aprender sobre a estrutura do projeto e o ciclo de vida do aplicativo e esperar poder programar na linguagem que eles usavam. Como eu só conhecia uma tecnologia nativa (iOS), decidi que era melhor investir tempo aprendendo uma tecnologia de plataforma cruzada.

Então, pensei: "Se vou usar uma tecnologia de plataforma cruzada, o que devo fazer? implicações Posso lidar com o melhor?".  Xamarin foi uma escolha natural para mim, graças à linguagem e à estrutura do aplicativo. O C# é uma das linguagens com as quais tenho mais facilidade de lidar, além de a estrutura ser intuitiva. Uma página .xml com seu código de back-end, o ciclo de vida do aplicativo também era do tipo C. Consegui aprender rapidamente o XAML e a estrutura e o ciclo de vida do aplicativo.

Mais tarde, descobri que o Xamarin gerava aplicativos nativos que compartilhavam 95% do código comum. Também cheguei a um nível aceitável de compreensão dos aplicativos nativos para Android e iOS. Então, decidi testar os projetos nativos gerados pelo Xamarin. Parecia que os aplicativos nativos eram muito bem estruturados e codificados. Pensei: "Uau, em teoria, é possível alguém desenvolver um aplicativo Android nativo completo sem conhecer Java ou a estrutura do aplicativo Android ou mesmo sem ter o Android Studio". Outra vantagem das tecnologias multiplataforma vem da camada de abstração. Ao usar o Xamarin, o código lida com eventos móveis (como Swipe) da maneira do Xamarin.

Posso codificar uma vez e usar esses eventos sem nem mesmo saber como fazer isso de forma nativa.

Decidi que era uma boa ideia tirar o máximo proveito desses projetos gerados e tentei fazer tudo no Xamarin, porque algumas coisas não são implementadas na estrutura. Por exemplo, o Xamarin não tem uma tag de botão de rádio para aplicativos iOS. Em vez de modificar o aplicativo iOS gerado e usar o botão de rádio da Apple, decidi implementar meu próprio botão de rádio no Xamarin, que era renderizado nativamente no iOS. Essa parecia ser uma boa escolha que se tornaria uma vantagem, mas também encontrei uma desvantagem: ao fazer uma alteração mínima em um projeto Xamarin, ele precisa ser recompilado para ver as alterações no dispositivo. Isso pode consumir muito tempo se você quiser testar várias alterações.

Conclusões

Decidi usar o Xamarin para criar aplicativos móveis porque ele era multiplataforma. Assim, a maior parte do código teria que ser escrita apenas uma vez. E os projetos gerados pelo Xamarin eram nativos. Esse não é o caso de todas as tecnologias de plataforma cruzada. O fato de os projetos finais serem nativos é uma vantagem, pois as características móveis podem ser usadas.

Ainda assim, estudei projetos nativos para Android e iOS para poder modificar os projetos gerados se algo realmente não puder ser feito no Xamarin (percebi que o Xamarin não suporta tudo para todas as plataformas). Novamente, isso pode ser feito porque o Xamarin gera projetos nativos.

Em outras palavras, aproveito o Xamarin para reutilizar o código e gerar plataformas totalmente nativas na medida em que ele me permite, mas também sei como fazer isso sem o Xamarin, caso eu realmente precise modificar um projeto nativo. As implicações do Xamarin são meus pontos fortes em programação. Foi assim que determinei que o Xamarin era a melhor opção para mim no que diz respeito ao desenvolvimento de aplicativos móveis.

É importante observar que a melhor opção é um equilíbrio entre os pontos fortes técnicos da equipe de desenvolvimento e as implicações da tecnologia. O Xamarin com experiência em plataformas nativas foi a melhor opção para mim, mas eu tenho experiência em C#. Outro desenvolvedor poderia ter trabalhado mais rapidamente com o Ionic se, por exemplo, ele fosse um mestre em AngularJS.