> For the complete documentation index, see [llms.txt](https://guias.mosaico.gov.pt/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guias.mosaico.gov.pt/guias-praticos/usabilidade-como-desenvolver-aplicacoes-para-dispositivos-moveis/boas-praticas.md).

# Boas práticas

Os indivíduos, de forma individual ou no seio das empresas, esperam uma boa experiência na utilização de aplicações para dispositivos móveis dos serviços da AP portuguesa. A concretização deste objetivo passa por um bom funcionamento das aplicações e dos serviços nelas disponibilizados, qualquer que seja o dispositivo ou o navegador pelo qual acedem. As aplicações para dispositivos móveis são uma forma de simplificar o acesso aos serviços públicos.

Como boa prática devemos considerar os diversos tipos de aplicações para dispositivos móveis que podem ser criadas, avaliando as suas características e quais as vantagens e as desvantagens para a aplicação concreta que pretendemos desenvolver.

De seguida detalhamos quais os tipos de aplicações móveis que devem ser analisados segundo os requisitos de cada aplicação e serviços a disponibilizar ao indivíduo ou empresa.

## **Tipos de aplicação** 

### **1) Aplicação web**

As aplicações web (web apps) são na realidade websites otimizados para dispositivos móveis, e que apresentam uma experiência semelhante às aplicações nativas, mas através do navegador de internet (Chrome, Safari, Edge, etc.).

Consideramos duas técnicas principais para o desenvolvimento deste tipo de aplicação:

* Aplicação web responsiva: um site que responde às dimensões do navegador em qualquer ponto. Esta resposta às dimensões do navegador é feita de forma fluída e flexível.
* Aplicação web adaptativa: um site que se adapta à largura do navegador em pontos específicos. Este tipo de site só foca em pontos específicos de largura e apenas se adapta nesses pontos à mudança de largura.

Tendo em conta estas duas técnicas, a nossa recomendação é a de que a aplicação web seja desenvolvida como uma aplicação web responsiva. Este desenvolvimento deverá seguir ainda a estratégia de progressive enhancement. 

### **2) Progressive enhancement**

O progressive enhancement é uma estratégia para o design web que dá enfâse ao conteúdo principal da página. Esta estratégia passa por adicionar de forma progressiva mais nuances, camadas de apresentação e recursos sobre o conteúdo principal, de acordo com a velocidade e condições de acesso de dados disponível em cada momento. O benefício desta estratégia é permitir que todos os utilizadores possam ter acesso ao conteúdo e à funcionalidade-base de uma página da web, usando qualquer navegador ou ligação à internet, além de fornecer uma versão mais completa da página para aqueles utilizadores que tenham navegadores de internet mais avançados ou que tenham disponível uma maior largura de banda.

Vantagens:

* O utilizador não precisa de instalar a aplicação no dispositivo móvel
* Os custos de desenvolvimento são mais baixos que no desenvolvimento de uma aplicação nativa, porque são utilizadas linguagens de programação comuns
* É mais fácil disponibilizar as atualizações porque estas poderão ser disponibilizadas de modo automático e não estão dependentes da loja de aplicações

Desvantagens:

* Não é possível utilizar todas as funcionalidades avançadas e nativas do dispositivo móvel

### **3) Aplicação nativa**

Uma aplicação nativa (app nativa) é definida como uma aplicação cujo código de programação é específico para o dispositivo móvel. São disso exemplo o uso de Objective C para sistema operativo iOS ou o uso de Java para o sistema operativo Android.

Vantagens:

* Desempenho rápido e um nível alto de fiabilidade
* Disponibiliza uma ligação fácil a muitas das funcionalidades nativas do dispositivo, como a câmara, contactos, calendário e outras características como o giroscópio, GPS, touch ID, etc.
* Algumas aplicações podem ser utilizadas sem ligação à internet

Desvantagens:

* O desenvolvimento destas aplicações apresenta custos de desenvolvimento mais altos, bem como será necessário mais tempo para o seu desenvolvimento, devido à dependência da linguagem específica do sistema operativo do dispositivo.
* O desenvolvimento destas aplicações obriga a duplicar a aplicação noutras linguagens de programação para conseguir apresentar noutros dispositivos baseados em sistemas operativos distintos.

### **4) Aplicação híbrida**

Uma aplicação híbrida (app híbrida) é muito semelhante a uma app nativa, no sentido em que pode ser encontrada e instalada através da loja de aplicações (App Store) do fabricante do sistema operativo do dispositivo (por exemplo: PlayStore da Google). A diferença entre as aplicações nativas e as aplicações híbridas encontra-se no processo de desenvolvimento.

Vantagens:

* As aplicações híbridas são desenvolvidas com linguagens de programação comuns ao desenvolvimento de aplicações web como HTML 5, CSS e Javascript
* São utilizáveis em todos os tipos de dispositivos, e o código precisa de ser escrito apenas uma vez, em que apenas o contexto de execução é nativo ao sistema operativo do dispositivo
* Os custos e o tempo necessários para desenvolver este tipo de aplicações são menores do que no caso das aplicações nativas

Desvantagens:

* Apesar de o desempenho deste tipo de aplicações ser semelhante ao das aplicações nativas, no caso das aplicações com necessidades de gráficos de alta qualidade existe uma degradação do desempenho da aplicação.
* Precisam de um plugin nativo (o contexto de execução) para conseguir aceder às funcionalidades nativas do dispositivo, como, por exemplo, o touch ID e a câmara. Se não existir um plugin nativo, será necessário desenvolvê-lo, o que poderá ser uma tarefa mais complexa.
* Todas as aplicações híbridas estão dependentes de frameworks e bibliotecas open source, como o [Ionic](https://ionicframework.com/) ou o [Cordova](https://cordova.apache.org/). 

### **5) Progressive web applications**

Algumas tecnologias emergentes permitem evoluir as aplicações web e torná-las aplicações web progressivas (progressive web applications – PWA). Estas tecnologias disponibilizam funcionalidades até agora disponíveis apenas para aplicações nativas ou híbridas.

Exemplos de funcionalidades que poderemos tirar partido com o uso de PWA:

* Adicionar ícones ao ecrã principal do telemóvel
* Enviar notificações push ao utilizador
* Disponibilizar um serviço quando o utilizador está sem ligação à internet
* Integrar um serviço com outras partes do telemóvel, como, por exemplo, a câmara fotográfica

A utilização de PWA permite que os utilizadores deixem de estar dependentes da instalação de novas versões das aplicações para terem acesso a novas funcionalidades e correção de bugs. 

## **Quando optar por aplicações nativas ou híbridas**

Há situações em que uma aplicação nativa ou híbrida é a única solução, como, por exemplo:

O utilizador precisa de recolher e guardar dados, mas não lhe é possível ter uma ligação de internet estável, sendo necessário o funcionamento em modo offline, e uma PWA não é opção. O serviço só funciona se tiver uma iteração constante no dispositivo do utilizador, como, por exemplo, em aplicações de fitness e saúde.

Outra situação em que poderá fazer sentido utilizar uma aplicação nativa, será quando a mesma só necessita de funcionar num dispositivo. Exemplos práticos: todos os utilizadores usam o mesmo dispositivo padrão departamental; necessidade de usar uma capacidade específica do dispositivo.

Salvo exceções do tipo das acima referidas, é bastante difícil justificar a opção de aplicações híbridas/nativas no desenvolvimento de uma aplicação para disponibilização de um serviço, para o indivíduo comum. Ainda assim, será necessário seguir boas práticas gerais e boas práticas de serviço.

**Se está limitado por funcionalidades do dispositivo**

Se a sua aplicação nativa requer uma funcionalidade que está disponível num pequeno grupo de dispositivos, então terá de apresentar a aplicação como progressive enhancement.

Nesta situação, apresentamos a aplicação apenas aos utilizadores que têm esses dispositivos, uma vez que é a forma mais fácil de completarem a sua tarefa. Mesmo assim, será preciso apresentar aos restantes utilizadores uma forma simples de conseguirem completar as suas tarefas.

## **Quando evitar aplicações nativas ou híbridas**

Como já foi referido, as aplicações nativas ou híbridas não são a melhor forma de disponibilizar serviços. É mais simples e menos dispendioso disponibilizar um website responsivo, desenvolvido com boas práticas web, e a funcionar em todos os navegadores e dispositivos móveis.

Ao construir uma aplicação nativa ou híbrida, será necessário suportar todos os sistemas operativos para os dispositivos móveis mais utilizados nas localizações-alvo da aplicação. Isto pode tornar-se muito dispendioso, quer na construção quer na manutenção das aplicações.

Existem outras abordagens possíveis para ultrapassar algumas das limitações das aplicações web, como as já referidas aplicações web progressivas.

Deve considerar sempre as alternativas possíveis antes de decidir desenvolver aplicações nativas ou híbridas, que são uma opção apenas quando não existe outra forma de ir ao encontro das necessidades do utilizador.

## **Acessibilidade**

De acordo com o [DL nº 83/2018](https://dre.pt/dre/detalhe/decreto-lei/83-2018-116734769), deve considerar-se acessibilidade como: “os princípios e técnicas a observar na conceção, construção, manutenção e atualização de sítios web e aplicações móveis de forma a tornar os seus conteúdos mais acessíveis aos utilizadores, em especial a pessoas com deficiência”.

Neste sentido, as aplicações para dispositivos móveis a disponibilizar no âmbito dos serviços da Administração Pública Portuguesa deverão cumprir as normas enunciadas no decreto lei acima referido e deverão ainda usar todas as ferramentas e guias de orientação disponibilizados no site [www.acessibilidade.gov.pt](http://www.acessibilidade.gov.pt/).

## **Partilha de dados e API**

Uma das boas práticas que os serviços públicos devem seguir, é disponibilizar o acesso aos dados e às Application Programming Interfaces (API) dos seus serviços a outras entidades, para que estas possam utilizar os dados e os serviços para construir serviços complementares ou adicionais aos serviços da entidade.

Esta abordagem também pode funcionar se identificar uma necessidade que, por constrangimentos diversos, não possa ser respondida pela sua entidade. Ao disponibilizar o acesso aos dados, pode estar a estimular o mercado a criar um serviço que possa responder a essa necessidade.

Um exemplo desta prática é o Transport of London que abriu o acesso das suas APIs, de forma a que algumas empresas privadas tivessem a possibilidade de desenvolver aplicações relacionadas com a rede de transportes públicos em Londres, como é o caso da aplicação [CityMapper](https://citymapper.com/).