Em nosso primeiro texto (olha ele aqui) abordamos como a chegada do primeiro iPhone e das lojas de aplicativos revolucionaram o modo como interagimos com o mundo digital. Também discutimos a transição dos hábitos dos usuários em relação à essa nova tecnologia e que a tendência era que cada vez mais os usuários migrassem suas tarefas para seus tablets e smartphones. Nessa segunda parte continuaremos a pontuar sobre essas questões e iremos levantar as atuais possibilidades de desenvolvimento de aplicativos mobile.

A tendência estava certa ou era pura empolgação em relação a algo novo?

aplicativos mobile

Fonte: AppleInsider,2017 / Worldwide: Apple, 2008-2017

Os resultados falam por si. O gráfico abaixo mostra a quantidade de aplicativos disponíveis na App Store de 2008 até 2017.

O gráfico da Google Play Store segue a mesma forma. Com novos recursos sendo adicionados aos smartphones, abrem-se novas possibilidades de interações com o celular, com isso vemos que a tendência é que esse número continue a crescer cada vez mais.

 

aplicativos mobile

Com esse bombardeamento de informações e novas possibilidades, vemos o resultado na vida do usuário final. Em 2016 pela primeira vez o tráfego web de dispositivos móveis superou o tráfego de desktops/laptops. Mas não foi somente o tráfego web que sofreu essa migração. Mas, como podemos ver no gráfico a seguir, o tempo médio gasto por adultos em 2017 com mídias digitais foi em sua maioria mobile.

 

SUA DECISÃO

Após essas informações creio que você já se convenceu do impacto e da importância que esse setor tem na sua vida e de seus clientes. Então, finalmente cabe a você tomar uma decisão em relação à pergunta: Qual abordagem utilizar ao desenvolver seus aplicativos? Deve-se seguir o padrão consolidado de aplicativos nativos, ou se aventurar nos aplicativos multiplataforma? Aliás, qual a diferença?

Sem dúvidas, ou melhor, com muitas dúvidas, essa é uma questão deveras complicada. Para te ajudar, separei o texto em duas abordagens.

ABORDAGEM TRADICIONAL

Comecemos então com a abordagem oferecida diretamente pelas fabricantes dos sistemas operacionais.

Essa abordagem, também chamada de Desenvolvimento Nativo, consiste em utilizar as ferramentas pré-determinadas pela Apple e Google, XCode e Android Studio respectivamente.

Ao escolher a abordagem tradicional, a equipe de desenvolvimento deve conhecer as linguagens específicas de cada plataforma, Objetive-C, Java ou suas mais novas substitutas, Swift e Kotlin. Também é necessário conhecer as ferramentas ditas anteriormente.

Com todo esse conhecimento em mente, constrói-se então duas bases de código. Mesmo se a lógica a ser seguida seja exatamente a mesma, um código utilizado em uma plataforma não pode ser aproveitado em outra, precisando ser replicado.

Os pontos negativos dessa abordagem são óbvios:

  • Aumento no custo do projeto final
  • Aumento no número da equipe (ou tempo de entrega)
  • Maior probabilidade de se gerar um erro no código, visto a maior quantidade de linhas escritas
  • No caso de se ter somente uma equipe responsável pelas duas plataformas, a migração direta da lógica pode não ser possível por limitações tecnológicas, fazendo com que os aplicativos resultantes sejam mais diferentes ainda

Se você parou de ler aqui, com certeza já ligou para seu gerente de projetos para cancelar a contratação de qualquer projeto de “Desenvolvimento Nativo”. Mas não se engane.

A abordagem tradicional carrega as maiores vantagens que uma equipe de desenvolvimento pode ter:

  • A liberdade de saber que código está escrito
  • Agilidade em ajuste de Bugs, reduzindo significantemente o custo nas manutenções
  • Maior possibilidade de customizações dos componentes do aplicativos, gerando aplicativos mais “ricos” graficamente
  • Acesso rápido, quase imediato às novas tecnológicas incorporadas pelas fabricantes

ABORDAGEM MULTIPLATAFORMA PARA APLICATIVOS MOBILE

Essa segunda opção foi uma abordagem construída ao longo do tempo com o objetivo de reduzir os impactos dos pontos negativos da abordagem tradicional.

O grande diferencial que essa abordagem propõe é baseado em uma pequena frase de efeito, que nem sempre é verdade:

“Code once, deploy for all” ou “Code once, run everywhere”.

Hoje, essa abordagem se divide em duas categorias:

Desenvolvimento Multiplataforma Híbrido/Web

Nessa categoria, estão os aplicativos que necessitam o mínimo possível de acesso às características específicas de cada plataforma. Os aplicativos construídos dessa forma são apenas “sites em miniatura” que são montados dentro de uma WebView (entenda como uma página de um navegador).

Visto a simplicidade dessa abordagem já podemos levantar os seguintes pontos positivos:

  • Rápida prototipagem
  • Rápida construção
  • Requer muito pouco conhecimento do desenvolvimento de aplicativos, de forma que um desenvolvedor Web pode assumir o desenvolvimento sem maiores problemas
  • Custo mais baixo

Mas nem tudo são flores. Como dito anteriormente, o esqueleto desses aplicativos é muito frágil e possui nada mais que uma camada Web com plug-ins para acessar algumas características, como câmera, etc. Ou seja, aplicativos nessa categoria:

  • Não possuem acesso à todas APIs (recursos) que o sistema oferece
  • Possuem comportamento diferente dependendo da versão da WebView (browser) do seu sistema operacional
  • Não utilizam os elementos gráficos nativos dos sistemas operacionais, podendo oferecer uma experiência mais limitadas aos usuários finais

Apesar de todos benefícios, em certos projetos, essas limitações se tornam de fato um gargalo, impossibilitando o desenvolvimento.

Com o objetivo de não se perder a agilidade no desenvolvimento, mas reduzir as limitações em relação ao desenvolvimento utilizando as ferramentas nativas, criou-se uma nova categoria de desenvolvimento multiplataforma.

Desenvolvimento Multiplataforma Nativo

Em último lugar temos talvez o método mais controverso de desenvolvimento atualmente existente. Mas por que controverso?

Quando tratamos de desenvolvimento multiplataforma na primeira vez, falava-se apenas de aplicativos multiplataforma híbridos. A utilização de APIs nativas em código não nativo ainda estava crescendo e carregava pouca credibilidade com grandes empresas.

O cenário atual é bem distinto. Hoje temos várias opções de frameworks e plataformas que utilizam essa abordagem. Por exemplo, Xamarin, Kony e React Native. Grandes empresas como a Microsoft estão por trás de sistemas robustos de desenvolvimento multiplataforma nativo.

A forma como essas ferramentas trabalham é bem similar. A maioria delas funciona do seguinte modo:

Interface

Todos elementos gráficos utilizados são elementos nativos de cada plataforma. Inclusive, algumas ferramentas, assim como o Xamarin, oferecem a possibilidade de integração com os ambientes de desenvolvimento padrões para gerar a interface do aplicativo.

Lógica (Código)

O código escrito é executado através em uma máquina virtual que traduz o código para o código à ser realmente executado no smartphone.

“Se é multiplataforma não é nativo. Se não é nativo é mais fraco”, você deve estar pensando. Mas você está errado. Um código escrito utilizando plataformas como o Xamarin possuem o mesmo “poder de fogo” de um código escrito em Swift e Kotlin.

Mas o poder dessa abordagem vai muito além de uma simples tradução.

Os pontos positivos são:

  • Essas plataformas, além de fazerem a tradução do código, também possibilitam o desenvolvedor escrever trechos de código nativo caso seja de seu interesse, ampliando as possibilidades de desenvolvimento para bem próximo à experiência da abordagem tradicional
  • Acesso à todas APIs dos sistemas operacionais nativos
  • Rápido suporte aos novos recursos incorporados
  • Os elementos gráficos são os mesmos elementos gráficos usados nas ferramentas padrão
  • À parte de códigos específicos que venham ser escritos, a base de código de ambas plataformas permanece a mesma. Facilitando a correção ou atualização de alguma lógica

Por outro lado, o grande contratempo dessa abordagem vem justamente da estratégia em se usar uma máquina virtual que executa o código. Com isso:

  • O tempo para executar um mesmo código é ligeiramente maior, reduzindo um pouco a performance de uma tarefa em relação à mesma sendo executada diretamente pelo código nativo
  • O desenvolvedor não sabe exatamente qual código (linha por linha) está sendo executado, ficando sujeito às implementações feitas pela plataforma escolhida
  • O preço de utilização das ferramentas de desenvolvimento pode ser muito elevado, dependendo da opção escolhida. Mas para desenvolvedores independentes e pequenas empresas existem boas opções e planos sem custo.

QUAL ESCOLHER?

Depois de tanta informação faltou o veredito. Certo? Errado.

O objetivo desse texto não é dar uma resposta pronta de qual abordagem você deve seguir. Mas sim, auxiliar sobre os pontos positivos e negativos de cada uma delas. Por outro lado, também não é o objetivo aqui levantar toda essa discussão sem dar um direcionamento de quando usar qual estratégia. Mas se lembre, o que será proposto a seguir é apenas uma sugestão. Você pode seguir, ou não, de acordo com sua necessidade.

aplicativos mobile

* Baixa – Telas simples, sem animações. Pouca ou nenhuma conexão com a internet.

* Média – Telas mais animadas. Conexão ativa com a internet. Leitor de QrCode / código de barras.

* Alta –Interface complexa e muito animada, uso de hardware específico como leitor de digital e identificação facial, restrição de uso de memória, utilização de recursos pesados como realidade virtual

Logicamente existem várias combinações possíveis. Mas espero ter lhe ajudado a compreender melhor as atuais possibilidades de desenvolvimento de aplicativos móveis.