Os 10 erros mais comuns que os desenvolvedores Android cometem: um tutorial de programação

Android. O que há para não gostar nesta plataforma? É gratuito, personalizável, está crescendo rapidamente e está disponível não apenas no seu telefone ou tablet, mas também no seu smartwatch, TV e carro.

Com a atualização mais recente do Lollipop, a programação do Android continua a melhorar. A plataforma amadureceu bastante desde o lançamento inicial do AOSP e definiu a barra de expectativas do usuário bastante alta. Veja como ficou bom o novo padrão de design de materiais!

Existem milhares de dispositivos diferentes, com diferentes tamanhos de tela, arquiteturas de chip, configurações de hardware e versões de software. Infelizmente, a segmentação é o preço a pagar pela abertura, e existem milhares de maneiras pelas quais seu aplicativo pode falhar em diferentes dispositivos, mesmo como um programador Android avançado.

Independentemente de uma segmentação tão grande, a maioria dos bugs são realmente introduzidos devido a erros de lógica. Esses bugs são facilmente evitados, desde que tenhamos o básico certo!

Aqui está um tutorial de programação Android para abordar os 10 erros mais comuns que os desenvolvedores Android cometem.

Erro comum nº 1: desenvolvendo para iOS

Para meu grande prazer, esse erro do Android é muito menos comum hoje em dia (em parte porque os clientes estão começando a perceber que os dias em que a Apple definia todos os padrões de design já se foram). Mas ainda assim, de vez em quando, vemos um aplicativo que é um clone do iOS.

Não me interpretem mal, eu não sou um evangelista de programação Android! Eu respeito todas as plataformas que movem o mundo móvel um passo à frente. Mas estamos em 2014 e os usuários usam o Android há algum tempo e se acostumaram com a plataforma. Empurrar os padrões de design do iOS para eles é uma estratégia terrível!

A menos que haja uma boa razão para quebrar as diretrizes, não faça isso. (O Google faz isso o tempo todo, mas nunca copiando e colando.)

Aqui estão alguns dos exemplos mais comuns desse erro do Android:

1. Você não deve fazer abas estáticas, e elas não pertencem ao fundo (estou apontando para você Instagram).
2. Os ícones de notificação do sistema não devem ter cores.
3. Os ícones de aplicativos não devem ser colocados dentro de um retângulo arredondado (a menos que seja seu logotipo real, ex. facebook).
4. As telas iniciais são redundantes além da configuração/introdução inicial. Não os use em outros cenários.
5. As listas não devem ter acentos circunflexos.

Estas são apenas algumas das muitas outras pequenas coisas que podem arruinar a experiência do usuário.

Erro comum nº 2: desenvolvendo para seu dispositivo Android

A menos que você esteja criando um aplicativo de quiosque/promocional para um único tablet, é provável que seu aplicativo Android não fique bom em todos os dispositivos. Aqui estão algumas dicas de programação Android para lembrar:

• Os pixels independentes de densidade (dp) são diferentes dos pixels normais (px).
• Os recursos são incluídos várias vezes para levar em conta diferentes densidades e orientações.
• Os drawables de 9 patches são esticados para caber na tela.

Existem literalmente milhares de cenários possíveis, mas depois de um tempo você desenvolve um senso de cobrir todos eles com um punhado de casos.

Você não possui milhares de dispositivos? Não é um problema. O Android Emulator é super bom na replicação de dispositivos físicos. Melhor ainda, experimente o Genymotion, é muito rápido e vem com muitos dispositivos predefinidos populares diferentes.

Além disso, você já tentou girar seu dispositivo? Todo o inferno pode se soltar…

Erro comum nº 3: não usar intents

As intenções são um dos principais componentes do Android. É uma maneira de passar dados entre diferentes partes do aplicativo ou, melhor ainda, diferentes aplicativos no sistema.

Digamos que você tenha um aplicativo de galeria que pode compartilhar um link de download para algumas imagens via SMS. Qual das duas opções parece mais lógica?

Opção 1:

• Solicite a permissão SEND_SMS.

   <uses-permission android:name="android.permission.SEND_SMS" />

• Escreva seu próprio código para enviar SMS usando o SmsManager .
• Explique aos seus usuários por que seu aplicativo de galeria precisa de acesso a serviços que podem custar dinheiro e por que eles precisam conceder essa permissão para usar seu aplicativo.

Opção 2:

• Inicie um SMS Intent e deixe um aplicativo projetado para SMS fazer o trabalho

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

Caso tenha alguma dúvida, a melhor solução é a opção 2!

Esta abordagem pode ser aplicada a quase tudo. Compartilhar conteúdo, tirar fotos, gravar vídeos, escolher contatos, adicionar eventos, abrir links com apps nativos, etc.

A menos que haja um bom motivo para fazer uma implementação personalizada (por exemplo, uma câmera que aplica filtros), sempre use Intents para esses cenários. Isso economizará muito tempo de programação e removerá o AndroidManifest.xml de permissões desnecessárias.

Erro comum nº 4: não usar fragmentos

Há um tempo atrás no Honeycomb, o Android introduziu o conceito de fragmentos . Pense neles como blocos de construção separados com seus próprios ciclos de vida (bastante complexos) que existem dentro de uma atividade. Eles ajudam muito na otimização para várias telas, são facilmente gerenciados pela atividade dos pais, podem ser reutilizados, combinados e posicionados à vontade.

Iniciar uma atividade separada para cada tela do aplicativo é terrivelmente ineficiente, pois o sistema tentará mantê-los na memória o máximo que puder. Matar um não liberará os recursos usados ​​pelos outros.

A menos que você queira se aprofundar no núcleo do Android e ler este artigo, advogando contra o uso de fragmentos, você deve usar fragmentos sempre que possível. Basicamente, diz que fragmentos e carregadores de cursor têm um bom propósito, mas uma implementação ruim.

Erro comum nº 5: bloqueando o thread principal

O thread principal tem um único propósito: manter a interface do usuário responsiva.

Embora a ciência por trás da medição da taxa de quadros que nossos olhos/cérebro possam perceber seja complexa e influenciada por muitos fatores, uma regra geral é que qualquer coisa abaixo de 24 fps com atraso maior que 100 ms não será percebida como suave.

Isso significa que as ações do usuário terão um feedback atrasado e o aplicativo Android que você programou deixará de responder. Tirar o controle do usuário sobre o aplicativo leva à frustração, os usuários frustrados tendem a dar um feedback muito negativo.

Pior ainda, se o encadeamento principal estiver bloqueado por um tempo (5 segundos para atividades, 10 para receptores de transmissão), o ANR acontecerá.

Isso era tão comum no Android 2.x, que nas versões mais recentes o sistema não permite que você faça chamadas de rede no thread principal.

Para evitar o bloqueio do encadeamento principal, sempre use encadeamentos de trabalho/fundo para: 1. chamadas de rede 2. carregamento de bitmap 3. processamento de imagem 4. consulta de banco de dados 5. leitura/gravação de SD

Erro comum nº 6: reinventar a roda

“OK, eu não vou usar o thread principal. Vou escrever meu próprio código que se comunica com meu servidor em um thread em segundo plano.”

Não! Por favor, não faça isso! Chamadas de rede, carregamento de imagens, acesso ao banco de dados, análise JSON e login social são as coisas mais comuns que você faz em seu aplicativo. Não apenas o seu, todos os aplicativos disponíveis. Há um caminho melhor. Você se lembra de como o Android amadureceu e cresceu como plataforma? Aqui está uma lista rápida de exemplos:

1. Use gradle como um sistema de compilação.
2. Use Retrofit / Volley para chamadas de rede.
3. Use o Picasso para carregar imagens.
4. Use Gson/Jackson para análise de JSON.
5. Use implementações comuns para login social.

Se você precisa de algo implementado, é provável que já esteja escrito, testado e usado amplamente. Faça uma pesquisa básica e leia alguns tutoriais de programação Android antes de escrever seu próprio código!

Erro comum nº 7: não assumir o sucesso

Excelente. Aprendemos que existe uma maneira melhor de lidar com tarefas de longa duração e estamos usando bibliotecas bem documentadas para essa finalidade. Mas o usuário ainda terá que esperar. É inevitável. Os pacotes não são enviados, processados ​​e recebidos instantaneamente. Há um atraso de ida e volta, há falhas de rede, pacotes se perdem e sonhos são destruídos.

Mas tudo isso é mensurável. As chamadas de rede bem-sucedidas são muito mais prováveis ​​do que as malsucedidas. Então, por que esperar pela resposta do servidor antes de processar a solicitação bem-sucedida? É infinitamente melhor assumir o sucesso e lidar com o fracasso. Assim, quando um usuário gosta de uma postagem, a contagem de curtidas é imediatamente aumentada e, no caso improvável de a chamada falhar, o usuário é notificado.

Neste mundo moderno, o feedback imediato é esperado. As pessoas não gostam de esperar. As crianças não querem se sentar em uma sala de aula obtendo conhecimento que tem uma recompensa futura incerta. Os aplicativos devem se adaptar à psicologia do usuário.

Erro comum nº 8: não entender bitmaps

Os usuários adoram conteúdo! Principalmente quando o conteúdo está bem formatado e com boa aparência. As imagens, por exemplo, são conteúdos extremamente agradáveis, principalmente pela propriedade de transmitir mil palavras por imagem. Eles também consomem muita memória. Muita memória!

Antes de uma imagem ser exibida na tela, ela deve ser carregada na memória. Como os bitmaps são a maneira mais comum de fazer isso, forneceremos um guia de programação do Android para todo o processo:

Digamos que você queira exibir uma imagem na tela que acabou de tirar com a câmera. A memória total necessária para isso é calculada com a seguinte fórmula: memory_needed_in_bytes = 4 * image_width * image_height;

Por que 4? Bem, a configuração de bitmap mais comum/recomendada é ARGB_8888 . Isso significa que para cada pixel que desenhamos, precisamos manter 8 bits (1 byte) para o canal alfa, vermelho, ganancioso e azul na memória, para exibi-lo corretamente. Existem alternativas, como a configuração RGB_565 que requer metade da memória do que ARGB_8888 , mas perde a transparência e a precisão da cor (embora talvez adicione uma tonalidade verde).

Vamos supor que você tenha um aparelho novinho em folha com tela full HD e câmera de 12 MP. A foto que você acabou de tirar tem 4000x3000 pixels e a memória total necessária para exibi-la é: 4 bytes * 4000 * 3000 = 48 MB

48 megabytes de sua RAM apenas para uma única imagem!? Isso é muito!

Agora vamos levar em consideração a resolução da tela. Você está tentando mostrar uma imagem de 4000x3000 em uma tela que possui 1920x1080 pixels, na pior das hipóteses (exibindo a imagem em tela cheia) você não deve alocar mais de 4 * 1920 * 1080 = 8.3 MB de memória.

Sempre siga as dicas de programação do Android para exibir bitmaps com eficiência:

1. Meça a visualização em que você está mostrando suas imagens.
2. Dimensione / recorte a imagem grande de acordo.
3. Mostre apenas o que pode ser exibido.

Erro comum nº 9: usando a hierarquia de visualização profunda

Os layouts têm uma apresentação XML no Android. Para desenhar o conteúdo, o XML precisa ser analisado, a tela precisa ser medida e todos os elementos precisam ser colocados de acordo. É um processo demorado e de recursos que precisa ser otimizado.

É assim que o ListView (e mais recentemente o RecyclerView) funciona.

Se um layout foi inflado uma vez, o sistema o reutiliza. Mas ainda assim, inflar o layout deve acontecer em algum momento.

Digamos que você queira fazer uma grade 3x3 com imagens. Uma maneira de fazer isso é um LinearLayout vertical contendo 3 LinearLayout s com peso igual, cada um deles contendo 3 ImageViews com peso igual.

O que obtemos com esta abordagem? Um aviso de que “pesos aninhados são ruins para o desempenho”.

Existe um ditado no mundo da programação Android, que acabei de inventar: “Com pouco esforço, toda hierarquia pode ser achatada” .

Neste caso, RelativeLayout ou GridLayout substituirá eficientemente os LinearLayouts aninhados.

Erro comum nº 10: não definir a minSdkVersion como 14

Bem, isso não é um erro, mas é uma má prática.

O Android 2.x foi um grande marco no desenvolvimento desta plataforma, mas algumas coisas devem ser deixadas para trás. O suporte a dispositivos mais antigos adiciona mais complexidade à manutenção do código e limita o processo de desenvolvimento.

Os números são claros, os usuários seguiram em frente, os desenvolvedores não devem ficar para trás.

Estou ciente de que isso não se aplica a alguns grandes mercados com dispositivos antigos (ex. Índia), e definir o minSdkVersion para 14, no aplicativo do Facebook, significa deixar alguns milhões de usuários sem sua rede social favorita. Mas, se você está começando do zero e tentando criar uma bela experiência para seus usuários, considere eliminar o passado. Os usuários que não têm os recursos, ou sentem a necessidade de atualizar seu dispositivo/SO, não terão o incentivo de experimentar uma versão superior do seu aplicativo Android e, finalmente, gastar dinheiro com isso.

Embrulhar

O Android é uma plataforma poderosa que evolui rapidamente. Pode não ser razoável esperar que os usuários mantenham o ritmo, mas é crucial que os desenvolvedores do Android o façam.

Saber que o Android não está apenas em nossos telefones ou tablets é ainda mais importante. Está em nossos pulsos, em nossas salas de estar, em nossas cozinhas e em nossos automóveis. Acertar o básico é de extrema importância antes de começarmos a expandir.