Top 10 des erreurs les plus courantes commises par les développeurs Android : un didacticiel de programmation

Android. Qu'est-ce qu'il n'y a pas à aimer sur cette plateforme ? C'est gratuit, c'est personnalisable, ça se développe rapidement et c'est disponible non seulement sur votre téléphone ou votre tablette, mais aussi sur votre smartwatch, votre téléviseur et votre voiture.

Avec la dernière mise à jour de Lollipop, la programmation Android continue de s'améliorer. La plate-forme a beaucoup mûri depuis la version initiale d'AOSP et a placé la barre des attentes des utilisateurs assez haut. Regardez à quel point le nouveau modèle de conception Material est beau !

Il existe des milliers d'appareils différents, avec des tailles d'écran, des architectures de puces, des configurations matérielles et des versions logicielles différentes. Malheureusement, la segmentation est le prix à payer pour l'ouverture, et il existe des milliers de façons dont votre application peut échouer sur différents appareils, même en tant que programmeur Android avancé.

Indépendamment d'une segmentation aussi importante, la majorité des bogues sont en fait introduits à cause d'erreurs de logique. Ces bugs sont facilement évités, tant que nous maîtrisons les bases !

Voici un tutoriel de programmation Android pour résoudre les 10 erreurs les plus courantes commises par les développeurs Android.

Erreur courante n° 1 : développer pour iOS

À mon grand plaisir, cette erreur Android est beaucoup moins courante de nos jours (en partie parce que les clients commencent à se rendre compte que l'époque où Apple établissait toutes les normes de conception est révolue depuis longtemps). Mais encore, de temps en temps, nous voyons une application qui est un clone iOS.

Ne vous méprenez pas, je ne suis pas un évangéliste de la programmation Android ! Je respecte chaque plate-forme qui fait avancer le monde mobile. Mais nous sommes en 2014 et les utilisateurs utilisent Android depuis un certain temps maintenant, et ils se sont habitués à la plate-forme. Pousser les normes de conception iOS vers eux est une stratégie terrible !

À moins qu'il n'y ait une super bonne raison pour enfreindre les directives, ne le faites pas. (Google le fait tout le temps, mais jamais par copier-coller.)

Voici quelques-uns des exemples les plus courants de cette erreur Android :

1. Vous ne devriez pas créer d'onglets statiques, et ils n'appartiennent pas au bas (je vous montre Instagram).
2. Les icônes de notification système ne doivent pas avoir de couleur.
3. Les icônes d'application ne doivent pas être placées à l'intérieur d'un rectangle arrondi (sauf s'il s'agit de votre logo réel, par exemple facebook).
4. Les écrans de démarrage sont redondants au-delà de la configuration/introduction initiale. Ne les utilisez pas dans d'autres scénarios.
5. Les listes ne doivent pas avoir de carets.

Ce ne sont là que quelques-unes des nombreuses autres petites choses qui peuvent ruiner l'expérience utilisateur.

Erreur courante n° 2 : développer pour votre appareil Android

À moins que vous ne créiez une application kiosque/promo pour une seule tablette, il est probable que votre application Android ne sera pas belle sur tous les appareils. Voici quelques conseils de programmation Android à retenir :

• Les pixels indépendants de la densité (dp) sont différents des pixels normaux (px).
• Les ressources sont incluses plusieurs fois pour tenir compte des différentes densités et orientations.
• Les drawables à 9 patchs sont étirés pour s'adapter à l'écran.

Il existe littéralement des milliers de scénarios possibles, mais après un certain temps, vous développez le sens de les couvrir tous avec une poignée de cas.

Vous ne possédez pas des milliers d'appareils ? Pas de problème. L'émulateur Android est super bon pour répliquer des appareils physiques. Mieux encore, essayez Genymotion, il est rapide comme l'éclair et est livré avec de nombreux appareils prédéfinis populaires.

Aussi, avez-vous essayé de faire pivoter votre appareil ? Tout l'enfer peut se déchaîner…

Erreur courante n° 3 : ne pas utiliser d'intentions

Les intentions sont l'un des composants clés d'Android. C'est un moyen de transmettre des données entre différentes parties de l'application ou, mieux encore, différentes applications sur le système.

Disons que vous avez une application de galerie qui peut partager un lien de téléchargement vers certaines images via SMS. Laquelle des deux options semble la plus logique ?

Option 1:

• Demandez l'autorisation SEND_SMS.

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

• Écrivez votre propre code pour l'envoi de SMS à l'aide du SmsManager .
• Expliquez à vos utilisateurs pourquoi votre application de galerie a besoin d'accéder à des services qui peuvent coûter de l'argent et pourquoi ils doivent accorder cette autorisation pour utiliser votre application.

Option 2:

• Démarrez une intention SMS et laissez une application conçue pour les SMS faire le travail

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

En cas de doute, la meilleure solution est l'option 2 !

Cette approche peut être appliquée à presque n'importe quoi. Partager du contenu, prendre des photos, enregistrer des vidéos, choisir des contacts, ajouter des événements, ouvrir des liens avec des applications natives, etc.

À moins qu'il n'y ait une bonne raison de faire une implémentation personnalisée (par exemple, une caméra qui applique des filtres), utilisez toujours les intentions pour ces scénarios. Cela vous fera gagner beaucoup de temps de programmation et AndroidManifest.xml des autorisations inutiles.

Erreur courante n° 4 : ne pas utiliser de fragments

Il y a quelque temps dans Honeycomb, Android a introduit le concept de fragments . Considérez-les comme des blocs de construction distincts avec leurs propres cycles de vie (plutôt complexes) qui existent à l'intérieur d'une activité. Ils aident beaucoup à l'optimisation pour différents écrans, ils sont facilement gérés par leur activité mère, peuvent être réutilisés, combinés et positionnés à volonté.

Lancer une activité distincte pour chaque écran d'application est terriblement inefficace, car le système essaiera de les garder en mémoire aussi longtemps qu'il le pourra. En tuer un ne libérera pas les ressources utilisées par les autres.

À moins que vous ne souhaitiez approfondir le cœur d'Android et lire cet article, plaidant contre l'utilisation de fragments, vous devez utiliser des fragments dans la mesure du possible. Il dit essentiellement que les fragments et les chargeurs de curseurs ont un bon objectif, mais une mauvaise implémentation.

Erreur courante n° 5 : bloquer le fil principal

Le thread principal a un seul objectif : garder l'interface utilisateur réactive.

Bien que la science derrière la mesure de la fréquence d'images que nos yeux/cerveau peuvent percevoir soit complexe et influencée par de nombreux facteurs, une règle générale est que tout ce qui est inférieur à 24 ips avec un retard supérieur à 100 ms ne sera pas perçu comme fluide.

Cela signifie que les actions de l'utilisateur auront un retour différé et que l'application Android que vous avez programmée cessera de répondre. Dépouiller l'utilisateur de son contrôle sur l'application conduit à la frustration, les utilisateurs frustrés ont tendance à donner des commentaires très négatifs.

Pire encore, si le thread principal est bloqué pendant un certain temps (5 secondes pour les activités, 10 pour les récepteurs de diffusion), l'ANR se produira.

C'était si courant dans Android 2.x que sur les versions plus récentes, le système ne vous permet pas de passer des appels réseau dans le thread principal.

Pour éviter de bloquer le thread principal, utilisez toujours les threads de travail/d'arrière-plan pour : 1. les appels réseau 2. le chargement de bitmap 3. le traitement d'image 4. l'interrogation de la base de données 5. la lecture/écriture de SD

Erreur courante n° 6 : réinventer la roue

« OK, je n'utiliserai pas le fil principal. J'écrirai mon propre code qui communiquera avec mon serveur dans un fil d'arrière-plan.

Non! S'il vous plaît ne faites pas ça ! Les appels réseau, le chargement d'images, l'accès à la base de données, l'analyse JSON et la connexion sociale sont les choses les plus courantes que vous faites dans votre application. Pas seulement la vôtre, toutes les applications disponibles. Il y a un meilleur moyen. Rappelez-vous comment Android a mûri et grandi en tant que plate-forme ? Voici une liste rapide d'exemples :

1. Utilisez gradle comme système de construction.
2. Utilisez Retrofit / Volley pour les appels réseau.
3. Utilisez Picasso pour le chargement des images.
4. Utilisez Gson / Jackson pour l'analyse JSON.
5. Utilisez des implémentations courantes pour la connexion sociale.

Si vous avez besoin d'implémenter quelque chose, il y a de fortes chances qu'il soit déjà écrit, testé et largement utilisé. Faites des recherches de base et lisez quelques tutoriels de programmation Android avant d'écrire votre propre code !

Erreur courante n° 7 : ne pas présumer du succès

Génial. Nous avons appris qu'il existe une meilleure façon de gérer les tâches de longue durée, et nous utilisons des bibliothèques bien documentées à cette fin. Mais l'utilisateur devra encore patienter. C'est inévitable. Les colis ne sont pas envoyés, traités et reçus instantanément. Il y a un retard aller-retour, il y a des pannes de réseau, des colis se perdent et des rêves sont détruits.

Mais tout cela est mesurable. Les appels réseau réussis sont beaucoup plus susceptibles que les échecs. Alors pourquoi attendre la réponse du serveur avant de traiter la requête réussie ? C'est infiniment mieux d'assumer le succès et de gérer l'échec. Ainsi, lorsqu'un utilisateur aime une publication, le nombre de likes est immédiatement augmenté et, dans le cas peu probable où l'appel échouerait, l'utilisateur en serait averti.

Dans ce monde moderne, une rétroaction immédiate est attendue. Les gens n'aiment pas attendre. Les enfants ne veulent pas s'asseoir dans une salle de classe pour acquérir des connaissances dont les bénéfices futurs sont incertains. Les applications doivent s'adapter à la psychologie de l'utilisateur.

Erreur courante n° 8 : ne pas comprendre les bitmaps

Les utilisateurs adorent le contenu ! Surtout quand le contenu est bien formaté et beau. Les images, par exemple, sont un contenu extrêmement agréable, principalement en raison de leur propriété de transmettre mille mots par image. Ils consomment également beaucoup de mémoire. Beaucoup de mémoire !

Avant qu'une image ne s'affiche à l'écran, elle doit être chargée dans la mémoire. Étant donné que les bitmaps sont le moyen le plus courant de le faire, nous allons fournir un guide de programmation Android pour l'ensemble du processus :

Disons que vous voulez afficher sur votre écran une image que vous venez de prendre avec votre appareil photo. La mémoire totale nécessaire pour cela est calculée avec la formule suivante : memory_needed_in_bytes = 4 * image_width * image_height;

Pourquoi 4 ? Eh bien, la configuration bitmap la plus courante / recommandée est ARGB_8888 . Cela signifie que pour chaque pixel que nous dessinons, nous devons garder en mémoire 8 bits (1 octet) pour le canal alpha, le rouge, le greed et le bleu, afin de l'afficher correctement. Il existe des alternatives, comme la configuration RGB_565 qui nécessite la moitié de la mémoire que ARGB_8888 , mais perd la transparence et la précision des couleurs (tout en ajoutant peut-être une teinte verte).

Supposons que vous ayez un tout nouvel appareil avec écran Full HD et appareil photo 12 MP. La photo que vous venez de prendre fait 4000x3000 pixels et la mémoire totale nécessaire pour l'afficher est de : 4 bytes * 4000 * 3000 = 48 MB

48 mégaoctets de votre RAM juste pour une seule image !? C'est beaucoup!

Prenons maintenant la résolution de l'écran en considération. Vous essayez d'afficher une image 4000x3000 sur un écran de 1920x1080 pixels, dans le pire des cas (affichage de l'image en plein écran), vous ne devriez pas allouer plus de 4 * 1920 * 1080 = 8.3 MB de mémoire.

Suivez toujours les conseils de programmation Android pour afficher efficacement les bitmaps :

1. Mesurez la vue dans laquelle vous affichez vos images.
2. Mettez à l'échelle / recadrez la grande image en conséquence.
3. Afficher uniquement ce qui peut être affiché.

Erreur courante n° 9 : utiliser la hiérarchie Deep View

Les mises en page ont une présentation XML dans Android. Afin de dessiner du contenu, le XML doit être analysé, l'écran doit être mesuré et tous les éléments doivent être placés en conséquence. C'est un processus consommateur de ressources et de temps qui doit être optimisé.

C'est ainsi que fonctionne ListView (et plus récemment RecyclerView).

Si une mise en page a été gonflée une fois, le système la réutilise. Mais encore, gonfler la mise en page doit arriver à un moment donné.

Supposons que vous souhaitiez créer une grille 3x3 avec des images. Une façon de faire est un LinearLayout vertical contenant 3 LinearLayout avec un poids égal, chacun d'eux contenant 3 ImageViews avec un poids égal.

Qu'obtenons-nous avec cette approche ? Un avertissement indiquant que "les poids imbriqués sont mauvais pour les performances".

Il y a un dicton dans le monde de la programmation Android, que je viens d'inventer : "Avec peu d'effort, toute hiérarchie peut être aplatie" .

Dans ce cas, RelativeLayout ou GridLayout remplaceront efficacement les LinearLayouts imbriqués.

Erreur courante #10 : ne pas définir la minSdkVersion sur 14

Eh bien, ce n'est pas une erreur, mais c'est une mauvaise pratique.

Android 2.x a été une étape importante dans le développement de cette plate-forme, mais certaines choses doivent être laissées de côté. La prise en charge d'appareils plus anciens ajoute plus de complexité à la maintenance du code et limite le processus de développement.

Les chiffres sont clairs, les utilisateurs ont évolué, les développeurs ne doivent pas rester en retrait.

Je suis conscient que cela ne s'applique pas à certains grands marchés avec d'anciens appareils (par exemple, l'Inde), et définir la minSdkVersion sur 14, sur l'application Facebook, signifie laisser quelques millions d'utilisateurs sans leur réseau social préféré. Mais, si vous repartez à zéro et essayez de créer une belle expérience pour vos utilisateurs, envisagez d'éliminer le passé. Les utilisateurs qui n'ont pas les ressources nécessaires ou qui ressentent le besoin de mettre à niveau leur appareil/système d'exploitation ne seront pas incités à essayer une version supérieure de votre application Android et, en fin de compte, à dépenser de l'argent pour celle-ci.

Emballer

Android est une plate-forme puissante qui évolue rapidement. Il n'est peut-être pas raisonnable de s'attendre à ce que les utilisateurs suivent le rythme, mais il est crucial que les développeurs Android le fassent.

Savoir qu'Android n'est pas seulement sur nos téléphones ou nos tablettes est encore plus important. C'est sur nos poignets, dans nos salons, dans nos cuisines et dans nos automobiles. Avoir les bonnes bases est de la plus haute importance avant de commencer à se développer.