A fragmentação do Android é a maior dificuldade que os desenvolvedores têm para lançar um aplicativo no mercado. O Android está longe de ser uma plataforma unificada, com poucos dispositivos como o iOS.
Alguns números sobre fragmentação
Para se ter uma ideia de como o Android está dividido, podemos ver um caso de uso real. Existem várias empresas que publicam aplicativos amplamente utilizados e posteriormente coletam dados de uso. Um deles é o OpenSignal, que publicou recentemente seu último estudo.
Os números são devastadores:
- 18.796 dispositivos Android diferentes vistos este ano, contra 11.868 no ano passado (até 58%).
- Samsung é o fabricante líder destacado com 43% dos dispositivos. O restante é distribuído por mais de 80 fabricantes diferentes.
- Existem 6 versões diferentes do sistema operacional ativas com um número grande o suficiente de usuários para serem ignorados.
- Há também um grande número de resoluções e tamanhos de tela diferentes. E, claro, com diferentes relações entre altura e largura.
A esses dados devemos adicionar diferentes elementos de hardware, como um conjunto de sensores que podem variar de um dispositivo para outro, ou um processador gráfico diferente que faz com que os desenvolvedores de jogos OpenGL tenham que cobri-los todos.
Em suma, um pesadelo, que se não controlarmos adequadamente pode nos custar mais do que um desprazer. Não é incomum encontrar projetos no Android em que após terminar a primeira versão, acaba gastando mais tempo na portabilidade para os diferentes modelos do que na própria primeira versão. Pode ser muito frustrante.
Enfrentando a fragmentação
Embora seja uma tarefa complicada, se seguirmos uma certa disciplina no desenvolvimento podemos alcançar um bom resultado em um tempo razoável. Para isso, começaremos com algumas considerações preliminares.
Trabalhe com fragmentação desde o início
Criar primeiro uma versão específica para um celular específico e depois transferi-la é um erro frequente. É comum cair no conforto de olhar apenas para o dispositivo que temos em mãos, mas se vamos lançar nosso aplicativo para um mercado amplo, deixar a fragmentação para o fim nos obrigará a fazer alterações caras em nosso projeto. Vamos demorar mais e cometer mais erros. Por exemplo, se não projetarmos nossas visualizações para serem flexíveis para acomodar vários tamanhos de tela, teremos que refazê-las mais tarde. Algo semelhante ao que aconteceu com localização de recursos.
Nesse sentido, há uma série de perguntas que podemos nos colocar antes de começar, e que nos ajudarão a ter um roteiro.
- Qual versão do sistema operacional eu desejo oferecer suporte? Apenas celulares recentes ou quero que meu aplicativo funcione com modelos mais antigos?
- Desejo oferecer suporte apenas a celulares, apenas tablets ou ambos?
- Em quais países desejo publicar meu aplicativo? Quais idiomas eu desejo oferecer suporte?
Com a primeira pergunta, podemos nos perguntar qual funcionalidade queremos incluir em nossa aplicação. Se oferecermos suporte a versões antigas, teremos que escolher entre sacrificar a funcionalidade das novas versões do Android ou lançar versões diferentes de nosso aplicativo. Minha recomendação pessoal é a primeira opção, a menos que você tenha recursos e desenvolvedores suficientes para trabalhar com duas versões diferentes do mesmo produto.
Com a segunda, seremos claros sobre como teremos que desenvolver nossas visões, sem perder de vista as diferentes versões de nossos recursos gráficos. Por fim, além da localização dos textos, deve-se levar em consideração que dependendo do país onde publicarmos nosso aplicativo, haverá celulares mais antigos ou mais modernos.
Suponha que nem todos os celulares podem ser cobertos
Com tanta fragmentação, sempre haverá casos "raros" que não valeremos a pena cobrir. Sempre haverá um modelo com problemas para gravar ou reproduzir som, ou executar um determinado formato de vídeo ... ou qualquer outra possibilidade. O fato de o Android ser um sistema gratuito permite que cada fabricante implemente o sistema operacional de acordo com sua preferência, o que inevitavelmente nos fará ter modelos difíceis de cobrir.
Aqui, um bom pragmatismo é essencial. Cobrir alguns dispositivos que são usados por um número muito pequeno de usuários não é viável, vai levar mais tempo do que cobrir dispositivos comuns. A melhor estratégia é proteger os dispositivos com mais presença no mercado no momento, o que por sua vez nos ajudará a fazer com que a maioria dos outros também funcione. Continuaremos a refinar nosso aplicativo até obter uma cobertura razoavelmente boa - um aplicativo bem desenvolvido facilmente excede 80% de cobertura.
Com tudo isso podemos começar a trabalhar. Embora já tenhamos citado algumas técnicas úteis, agora as revisaremos em detalhes.
- Nossas opiniões sempre serão flexíveis. Nunca usaremos valores absolutos para tamanhos de pixel, muito menos um AbsoluteLayout. Todas as nossas medidas serão em pixels ou dp dependentes, e usaremos proporções e medidas relativas sempre que possível.
- Testaremos nossas visualizações em diferentes tamanhos de tela. Para não ter que tentar todos eles, uma boa abordagem é tentar um dos maiores dispositivos, outro dos menores e um intermediário.
- Faremos o possível para ter todos os recursos gráficos disponíveis para todas as densidades de tela, o que nos tornará mais fácil ter visualizações 100% flexíveis.
- Certificar-nos-emos de ter textos de código separados para apoiar a internacionalização.
- Escolheremos a versão mais baixa do sistema operacional com o qual trabalharemos e desenvolveremos apenas com ela, se possível. Do contrário, criaremos diferentes versões para diferentes sistemas operacionais, embora quanto menos, melhor. Às vezes, encontraremos bibliotecas de terceiros que implementam funcionalidades de versões recentes sem ter que usá-las diretamente, é uma alternativa interessante a se considerar.
- Nós iremos testar inevitavelmente. No mercado existem empresas que se dedicam exclusivamente a testes, e com preços bastante razoáveis podemos obter testes automáticos para uma ampla gama de dispositivos.
- E, finalmente, não excluiremos relatórios de erro do usuário, que inevitavelmente chegarão até nós. Com eles certamente descobriremos detalhes que perdemos.
