Comprendre la programmation Android

Il y a deux acteurs majeurs dans le monde du mobile : Apple (iOS) et Google (Android). Android est aujourd’hui l’OS sur mobile le plus utilisé dans le monde. Près de 70% des utilisateurs dans les pays occidentaux utilisent cette plateforme. En Afrique ou en Asie, la politique tarifaire d’Apple, fait que les parts de marché Android sont encore plus fortes et continuent à grimper.

Faire de la programmation mobile a un intérêt. L’accès à l’informatique (web ou autre) se fait de plus en plus avec des mobiles et tablettes. Android est devenu l’OS le plus utilisé au niveau mondial tout systême confondu

La mobilité a transformé les devices que nous utilisons. Quand vous êtes sur un PC fixe ou un portable vous avez toujours à peu près les mêmes composants : CPU, carte graphique, disque dur, lecteur carte photo, ports d’entrée/sortie. Sur un mobile vous allez avoir plus de composants pour vous aider dans ce contexte de mobilité : GPS, caméra, appareil photo, accélomètre, podomètre…​ Nous avons de plus en plus de capteurs pour interpréter le contexte d’utilisation du device

La spécificité de la programmation mobile, est de proposer des applications qui récupérent et aggrègent les données émises par les différents capteurs pour répondre à un besoin utilisateur. Quand vous voulez vous interfacer avec ces capteurs, apporter de la réactivité dans vos application, le développement natif est la solution.

Créer une application mobile pour simplement afficher du contenu statique n’a pas de sens. Pour ce besoin, on préférera les applications web responsives (PWA) qui sont beaucoup plus optimales et moins coûteuses. Une application native doit être dynamique et profiter des API et des capteurs exposés par les devices.

Android a été construit sur un noyau Linux. Mais Android n’est pas totalement Open Source. Seule une partie est libre de droit.

Android s’appuie sur les forces de Linux pour fournir un OS stable et fiable : gestion de la mémoire, gestion des processus, sécurité…​

Android définit une couche abstraite pour s’interfacer avec les différents capteurs ou élements de bas niveau d’un device : HAL (Hardware Abstraction Layer). Les différents constructeurs de mobile doivent implémenter cette couche pour que leur téléphone puisse fonctionner. Ils doivent également prouver que leurs téléphones sont capables de répondre aux exigences de tests demandées par Google. Il existe des tests de compatibilités avec une version de l’OS (CTS compatibility test suite) et des d’autres tests complémentaires (VTS Vendor test suite).

Ces développements peuvent être longs et coûteux. C’est pour cette raison, que les constructeurs ne font pas évoluer leurs téléphones. Leur but est de vendre toujours plus de nouveaux devices, et non de maintenir les anciens. Ces problèmes de mises à jour entraînent une grosse fragmentation dans l’utilisation des versions de l’OS. Cette fragmentation liée aux versions du système d’exploitation, est moins présente dans le monde iOS. Comme Apple est à la fois éditeur et constructeur, tout est fait pour que chaque nouvelle version soit supportée par les anciens devices (troll: sauf quand ils introduident de l’obsolescence programmée).

Le coeur d’Android est écrit en C ou C++ et plusieurs librairies natives sont accessibles (NDK Native development kit). Vous pouvez écrire vos applications en C mais pour faciliter la mise en place d’applications, Google a poussé les développeurs à utiliser le langage Java depuis les débuts. Java est parfois verbeux mais il a l’avantage d’être simple et d’amener un cadre de développement.

Comme Android est basé sur un noyau Linux, la plateforme bénéficie de la sécurité implémentée au niveau du noyau.

Quand une application est installée, Android lui assigne un user ID. Chaque application est lancée dans un processus séparé et utilise sa propre instance d’ART (machine virtuel). Les droits d’exécution sont propres à cet utilisateur applicatif. L’application n’a pas de notion de cet ID. Ainsi une application ne peut pas accéder aux données d’une autre application car tout est bouclé par cet artifice. C’est la même chose pour les applications natives.

Chaque application est donc isolée des autres et possèdent ses propres ressources CPU, mémoire…​.

Au dessus de cette sécurité "bas niveau", Android a ajouté au fil du temps un niveau de sécurité plus "haut niveau". Chaque action externe pouvant être demandée par votre application doit être déclarée dans un fichier manifest. Par exemple

Un utilisateur peut choisir de laisser les droits demandés à l’installation, mais il peut aussi choisir d’enlever certains droits. Personnellement je limite le nombre d’application pouvant se connecter au réseau, pouvant utiliser mes contacts, mes fichiers…​. (sur un Android sans surcouche vous devez aller dans les paramètres dans le menu "Appli et notifications", dans les options avancées et sur l’entrée "Autorisation des applications").

Depuis quelques années, Google sort une nouvelle version d’Android par an. Généralement les développeurs peuvent commencer à tester et faire des retours sur le second et troisième trimestre et la version est mise à disposition au dernier trimestre d’une année civile.

Chaque nouvelle version est associée à une lettre (qui s’incrémente à chaque version) et à un dessert (choisi par l’équipe Android).

Vous pouvez voir que certains de ces desserts sont des desserts français. Depuis les débuts, l’équipe Android comprend plusieurs français. Vous connaissez peut être Romain Guy qui est régulièrement présent dans les conférences.

Quand vous démarrez un nouveau développement vous devez faire un choix de version. En fait vous devez faire deux choix

Les statistiques d’utilisation des versions sont publiées régulièrement sur ce tableau de bord qui compile les données remontées par Google Store (la source officielle des applications Android).

Dans le monde du web, vous pouvez utiliser des polyfills pour utiliser les dernières nouveautés du langage dans des navigateurs qui n’implémentent pas encore ces fonctionnalités. Dans le monde Android, Google vous propose aussi d’utiliser des objets particuliers qui gèrent cette rétrocompatibilité. La classe de base pour développer un écran est android.app.Activity, mais dans la pratique nous utiliserons toujours androidx.appcompat.app.AppCompatActivity qui a été développée pour porter les dernières nouveautés sur les anciennes releases Android.

Après les versions, la plus grosse différence entre les devices concerne la qualité et la taille de l’écran.

Pour rappel

Android propose une classification liée à la largeur d’un écran.

Comme dans le monde du web, vous devez adpater votre UI soit en utilisant des composants et layout redimensionnable, soit en utilisant des layouts différents en fonction de la taille (en Android vous pouvez utiliser des fragments)

La densité de pixels est le nombre de points par pouce (dot per inch ⇒ dpi). La densité est importante sur un device. Par exemple si vous affichez une image exprimée en pixel sur 2 écrans de densité différentes vous n’aurez pas le même rendu

Si on affiche les mêmes images exprimées avec l’unité dp (density-independent pixels) vous aurez le rendu suivant

La règle est de ne jamais exprimer des tailles en px dans une application mais toujours en dp (dans le monde du web on utilisera l’unité em). Pour exprimer la taille des polices d’écriture, vous utiliserez plutôt l’unité sp (scalable pixels) qui a l’avantage de grossir en fonction des paramètres d’accessibilité utilisateur.

Vous allez pouvoir créer des ressources différentes en fonction de la taille. Quand vous avez un bel écran avec une bonne résolution, une forte densité, vous attendrez des images de qualité. Ces mêmes images n’ont aucun intérêt sur des écrans qui ne sont pas capables de les afficher.

Nous nous sommes arrếtés sur les 2 plus grosses différences entre device mais on pourrait aller plus loin car vous avez aussi une grosse différence de qualité et de performances au niveau des composants de base d’un mobile ou d’une tablette. Vous n’avez pas les mêmes composants dans les devices d’entrée de gamme et ceux plus luxueux

Pour offrir une bonne expérience utilisateur, vous pouvez appliquer quelques règles simples

Comme vos utilisateurs peuvent et ont pour la plupart des ressources limitées essayer de