Opinião.17 Out 2014

Aplicações mobile: chamem-nos nativas, híbridas ou simplesmente HTML5

Não é novidade nenhuma que as aplicações para dispositivos móveis (mobile apps) constituem um marco na história da tecnologia, revolucionando a maneira como interagimos com vários sistemas e serviços de informação móveis. É certo. No entanto, causa alguma surpresa e fascínio que algo tão banalizado e cujo o uso é de domínio comum, não tenha uma abordagem de desenvolvimento consensual (longe de ser empírica) e que pode colocar no mesmo plano de discussão uma empresa startup ou uma gigante informática.

O principal ponto de debate nesta área envolve linguagens nativas e HTML5, já que a base de programação de uma app poderá ser inteiramente suportada pela linguagem nativa do dispositivo (Android, iOS e Windows Phone possuem linguagens nativas diferentes entre si) ou por HTML5, linguagem transversal a todos os dispositivos móveis quando disponibilizada num browser. Esta última opção denomina-se web app pois tal como um website engloba de forma generalizada HTML5, apoiado por CSS e JavaScript. Há ainda a possibilidade de fazer uso das duas opções na mesma aplicação, ou seja, criar aplicações híbridas (hybrid apps).

Como é óbvio, construir uma aplicação que faz uso das mesmas linguagens do sistema operativo que a acolhe (linguagens de programação nativas) pressupõe um maior poder de acesso aos recursos do sistema, eficiência e independência (para o bem e para o mal, refira-se). Entende-se portanto que quando as aplicações mobile começaram a difundir-se em larga escala, fazer uso das linguagens nativas para o seu desenvolvimento era a escolha por excelência.

Porém cedo se percebeu que em determinados contextos um website devidamente otimizado para dispositivos móveis poderia obter o mesmo nível de experiência de utilização quando comparado a uma aplicação nativa. O surgimento e evolução do HTML5 foi um grande impulso para agilizar as web apps como alternativa às aplicações nativas (native apps).

Optar pelo HTML5 no desenvolvimento deste tipo de aplicações é uma escolha que se pode definir como "eclética". É uma linguagem considerada "multiplataforma" e certifica que a app será carregada em qualquer dispositivo que tenha um browser ou uma aplicação que interprete HTML. Evita-se assim a criação de raiz da mesma app cada vez que for necessário distribuí-la num sistema operativo diferente, reduzindo substancialmente o tempo e respetivo custo de desenvolvimento.

Não é de todo errado considerar uma web app como sendo um website adaptado a dispositivos móveis, mas é importante realçar que a maneira como é desenvolvida e otimizada demarca-se bastante da forma como se desenvolvem websites para desktop (por exemplo uma loja online) ou mesmo websites responsive, isto é, que conseguem organizar de várias formas o seu conteúdo de acordo com a dimensão do ecrã (seja ele desktop ou mobile).

Por norma uma web app desenvolve-se apenas numa página (Single Page Application) com o intuito de reduzir o número de pedidos ao servidor (e consequentemente o tempo de espera). O dinamismo de conteúdos de informação é assegurado por um uso extensivo de JavaScript, linguagem de programação que permite expandir a interação com os elementos do HTML5.

Porém existem, à data, várias limitações associadas às web apps sobretudo no que toca à dependência de conectividade, ou seja, acesso à internet. Embora seja legítimo apontar essa falha à grande maioria das web apps, a verdade é que o HTML5 possui recursos que lhe permitem não só suprir as diferenças entre os dois polos aplicacionais, como até ganhar vantagem sobre as aplicações nativas, uma vez que permite guardar variáveis e bases de dados no dispositivo do utilizador, embora ainda com algumas questões de fiabilidade e compatibilidade por resolver/aperfeiçoar. Obviamente não dispensa aceder uma primeira vez ao URL onde está alojada a web app, tal como também se tem de garantir conectividade para descarregar uma aplicação nativa, mas depois da primeira ligação, e se construída com esse propósito a web app pode manter-se estável e executável sem necessidade de acesso à internet.

Em relação a atualizações que sejam necessárias aplicar periodicamente à aplicação, as web apps possuem clara vantagem sobre as native apps: é muito menos doloroso para uma equipa de desenvolvimento correr um update único que se reflete em todos os dispositivos que possuem a app em questão, ao invés de ter de criar uma atualização para cada versão existente que a app possui. No caso das apps nativas, como estão instaladas no dispositivo do utilizador, tem que haver uma permissão do mesmo, correr o processo de atualização e esperar que a nova versão seja totalmente compatível com o seu sistema. Perante esta realidade é praticamente impossível existir uma web app desatualizada ou incompatível.

Penso que se vai verificar nos dispositivos móveis o mesmo que se verificou nos computadores pessoais: a preferência generalizada pelas aplicações online em detrimento do software, tirando proveito do armazenamento em cloud (note-se os casos do Google Drive ou Dropbox).

Além do mais, mesmo que haja uma necessidade de conectividade acima do normal (depende da web app em questão) tal não se pode considerar algo crítico nos dias que correm. Tentar encontrar um espaço público sem pontos de acesso à rede é que poderá revelar-se uma tarefa árdua.

Partilho da opinião de que embora exista um vasto conjunto de situações em que o HTM5 consegue fazer esquecer as aplicações nativas, as suas limitações e as limitações que lhe são impostas não o permitem ser uma solução 100% viável especialmente quando são necessárias funcionalidades mais avançadas, pois como já foi referido, é dificultado o seu acesso a recursos do sistema. A restrição ao uso da câmara de um smartphone ou ao acesso da lista de contactos do utilizador são exemplos disso mesmo.

Por seu turno, as aplicações híbridas ajudam a colmatar essas falhas na medida em que se podem considerar aplicações nativas comandadas por HTML5 encapsulado em frameworks (PhoneGap, Appcelerator são exemplos). É como se houvesse uma espécie de "tradutor" sempre presente entre o HTML e o dispositivo e por isso mesmo não se pode considerar que exista uma "comunicação" direta. Posto isto é muito mais difícil otimizar devidamente e com eficiência uma aplicação híbrida. Quanto a mim é uma solução de meio-termo tal como foi o caso do Flash embutido nos web browsers.

Isto é o que se passa atualmente. Contudo, não querendo ser presunçoso, parece-me evidente que o HTML irá dominar quase na totalidade esta área da tecnologia móvel num futuro mais ou menos próximo. É uma tecnologia que é desenvolvida de uma forma realmente sustentável e com a intervenção de um vasto conjunto de entidades além de que assenta no modelo de arquitetura de ficheiros REST, sistema que muitos defendem poder ser o futuro de todas as máquinas que comuniquem em rede, inclusivamente... robôs. Estes indicadores fazem acreditar que existe uma maior margem de progressão no HTML comparativamente a linguagens de programação nativas como Java ou Objective-C.

Fora de ilusões, é certo que terá que haver boa vontade das empresas distribuidoras de dispositivos móveis para que em conjunto possibilitem um maior poder de acesso aos recursos do sistema por parte do HTML e que validem novas funcionalidades que esta tecnologia dispõe mas que em muitos casos os dispositivos não reconhecem.

Já se vai assistindo a algumas ações tomadas nesse sentido: o novo iOS8 da Apple suporta WebGL e IndexedDB, recursos que respetivamente melhoram a renderização de gráficos e permitem o armazenamento de dados offline a mando do HTML5. O mesmo já era suportado no sistema Android da Google, embora apenas no Chrome e não no browser que vem instalado por defeito.

Mais importante do que tomar partido de uma destas opções de desenvolvimento à cabeça, é saber qual a que melhor se adequa ao objetivo em causa, tendo em conta os recursos disponíveis e entraves atuais ao HTML5.

Se o pretendido é uma simples aplicação de cariz informativo e com pouco conteúdo, desenvolver uma web app é a opção a tomar.

Já no caso de ser necessário aceder a dados do sistema como o calendário do utilizador por exemplo, e os recursos financeiros são limitados, a preferência deve ser dada ao desenvolvimento de uma hybrid app.

Mas se o negócio ou entidade depender(em) totalmente do êxito da aplicação, se o controlo sobre os recursos do sistema operativo é indispensável para assegurar uma boa performance, e se existe disponibilidade financeira, então uma native app é pois claro a escolha a fazer.

Tony Oliveira