Android : L'interaction avec les appareils

Aborder la fragmentation

Testez gratuitement nos 1300 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Découvrez comment gérer les problématiques de la fragmentation sur Android 7. Vous aborderez également l'AppCompatButton, les différentes tailles d'écran et les densités.
07:26

Transcription

Dans cette séquence, je vais vous parler des problèmes de fragmentation que l'on rencontre lorsqu'on est développeur Android, et vous donner quelques bonnes pratiques pour les résoudre. Sur cet écran, on peut voir qu'au 03 Avril 2017, il y a encore beaucoup de versions différentes d'Android, ayant au moins 1 % d'utilisation. Jelly Bean qui est une version ayant bientôt 5 ans totalise quand même 10 %. Il existe deux évolutions majeures, la première avec la version 4, apparaît pour les tablettes et qui a ajouté les fragments, mais aujourd'hui, les nouvelles applications n'étant rétro-compatibles que jusqu'à Jelly Bean, on n'a plus besoin de prendre en compte, si notre application est exécutée avant ou après cette version. Et la deuxième, avec la version 5 Lollipop qui amène énormément de nouveautés sur les interfaces graphiques, dont certaines ne sont pas rétro-compatibles. Je vous en montrerai quelques unes et comment on doit les gérer durant cette formation. Tout de suite, un premier exemple avec la couleur des boutons. Ici, un émulateur sous Nougat, donc après Lollipop, on peut voir un bouton rose, un deuxième bouton rose. Le deuxième n'est pas un bouton classique, c'est un APPCOMPATBUTTON, c'est-à-dire un bouton provenant de l'AppCompat Library qui est fournie par Google pour permettre la rétro-compatibilité. Maintenant, un deuxième émulateur. Le premier était sur un Nexus 7, c'est-à-dire environ 7 pouces de diagonale, le deuxième sur un Nexus 5, on peut voir déjà que le rendu est différent, celui sur le Nexus 5 est sur KitKat, c'est-à-dire avant Lollipop, et on peut voir que notre bouton classique qui a bien son animation, lui, n'est plus rose, pourtant, c'est le même code qui a été exécuté derrière. Cependant, mon APPCOMPATBUTTON possède toujours notre couleur rose. Regardons comment fonctionne l'APPCOMPATBUTTON. Dans notre XML, au lieu d'utiliser un bouton, nous utilisons un APPCOMPATBUTTON, pour le reste, c'est identique. Notre bouton classique peut indiquer sa couleur de fond en utilisant « backgroundTint. » Si je laisse mon curseur dessus, il m'indique que c'est pour la version minimum à 21, c'est-à-dire Lollipop. Alors, si je laisse comme ça, je ne verrai pas la différence, j'aurai un bouton grisé. Je vais pouvoir dynamiquement modifier mon « backgroundTint » sur mon APPCOMPATBUTTON. Ici, je récupère mon APPCOMPATBUTTON et je lui applique un ColorStateList. Ce ColorStateList, c'est quoi ? C'est les deux états de mon bouton pressé ou normal, je lui donne une couleur pour le normal et une couleur pour le pressé. Alors, la couleur normale, c'est celle qui est générée sur les template Android, pour passer à la couleur pressé, je me contente de diminuer l'Alpha, je passe de FF à DD pour donner le côté plus sombre lors du clic. Ceci est une façon de gérer les couleurs des boutons sans perdre la petite animation qui existe. Il existe une autre façon qui consiste dans le thème, à rajouter l'attribut colorButtonNormal qui va colorer tous nos boutons de toute notre application de cette couleur-là. Si on souhaite, sur un nouvel écran, utiliser un nouvelle couleur pour nos boutons, on peut surcharger le thème et changer cette valeur. Cela impose quand même d'avoir un écran avec tous les boutons de la même couleur. Voilà les deux façons de procéder en fonction du besoin. Un deuxième problème rencontré, au niveau de la fragmentation, après devoir testé sur différentes versions d'Android, nous avons la taille des écrans et la densité des écrans, ici représentées par ces petits graphiques. Nous avons vu que sur le Nexus 5 et sur le Nexus 7, le rendu n'est pas le même. Sur le site de la documentation d'Android, sur cette page, il existe de nombreuses astuces pour gérer le multi-écran. Plus loin dans la page, nous pouvons voir ce qui se passe si pour une même taille d'écran, nous ne gérons pas les différentes densités. Nous voyons que pour une même taille d'écran, nos éléments, en fonction que la densité augmente, deviennent de plus en plus petits. Si nous gérons bien les différentes densités d'écran, notre rendu sera identique pour une même taille d'écran. Pour cela, nous allons utiliser des dp au lieu des pixels. J'ai attribué à mon premier bouton une largeur de 200 dp, ce qui indique que quel que soit la densité de l'écran ou la taille de l'écran, le rendu, si je le mesure physiquement sera le même pour tous les appareils. Comment gérer maintenant un rendu différent sur une tablette ou phablette, et sur un téléphone. Pour cela, nous allons procéder comme pour la gestion des langues, c'est-à-dire nous allons créer un répertoire propre pour une certaine taille d'écran. « New Android resource directory », nous allons sélectionner un layout, « Smallest Screen Width » et nous allons mettre 600 dp. 600 dp représente à peu près une phablette de 7 pouces de basse qualité ou un téléphone 6 pouces de haute qualité. Je vais dupliquer mon layout, juste pour montrer l'exemple, je lui donne le même nom. Dans le premier, je vais marquer normal et laisser 200 dp. Dans le deuxième, je vais marquer 600 dp et ici, je vais multiplier par 1,5. Je vais donc relancer mon application. Nous avons donc à gauche sur le Nexus 5, qui ne fait pas 600 dp sur la plus grande de ses largeur-hauteur, donc ici, c'est la hauteur, nous utilisons le layout normal. Par contre sur le Nexus 7, ayant une hauteur de plus de 600 dp, nous nous retrouvons à utiliser le layout de 600 dp. Ce qui nous donne un rendu à peu près similaire en terme de largeur. Pour une tablette, il suffirait de multiplier par deux, et donc nous aurions 400 dp. Ici, j'ai dupliqué directement le layout, ce qui me permettrait d'avoir deux layouts différents pour la tablette et pour le téléphone, tout en ayant les mêmes composants graphiques à l'intérieur. Mais pour notre cas, si j'ai juste changé une largeur, il est plus simple de passer par les « values », donc faire exactement la même chose, « New Android resource directory », « Smallest Screen Width », 600. Je vais créer un nouveau dossier que je vais appeler « dimens » pour dimension. Dans la version normale, je mets 200. Dans la version phablette, ou tablette, je mets 300, on peut en créer un troisième avec 800 dp, donc « values-sw800dp » qui représente plus les tablettes, donc environ 10 pouces, ou ici je mettrai une largeur de 400. Et cette valeur-là, il ne me reste plus qu'à l'utiliser dans mon XML et à supprimer ce layout-là. Voilà, nous avons donc le même résultat que précédemment, sans avoir à dupliquer tout le fichier. Il faut savoir qu'à cause de cette fragmentation entre les différentes tailles d'écran possibles, les différentes densités et les différentes versions d'OS, il faut environ 30 % de temps en plus pour réaliser une application Android comparée à une application iOS. Voilà pour les principaux problèmes de fragmentation existants sur Android.

Android : L'interaction avec les appareils

Exploitez les outils mis à disposition par le kit de développement Android. Améliorez l’expérience utilisateur de vos applications​ mobiles​ avec les composants et les animations.

1h58 (23 vidéos)
Aucun commentaire n´est disponible actuellement
 

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !