S’adapter à la plateforme
Pourquoi décliner l’interface pour une plateforme ?
La promesse du développement multiplateforme est de n’avoir à produire qu’un seul code source pour adresser tous les grands systèmes mobiles actuels. Le développeur se doit donc de créer un code source le plus générique possible et ne décrocher sur du code natif qu’à travers des plugins, là aussi accessibles via une interface unifiée.
Pourquoi serait-il nécessaire dans ce contexte de prendre en compte la plateforme native sur laquelle l’application va s’exécuter, si la technologie fait tout son possible pour s’en abstraire ? Tout simplement car les utilisateurs ont des habitudes, et ces habitudes sont très souvent liées au système qu’ils utilisent. Par exemple, les smartphones tournant sur Android proposent un bouton retour que les iPhones n’ont pas. Ces derniers positionnent les onglets en bas alors qu’ils sont positionnés en haut sur Android. Les titres sont centrés sur certains systèmes et alignés à gauche pour d’autres. En résumé, même si l’approche de Ionic, et du développement multiplateforme en général, est de se détacher le plus possible de ces problématiques, il est nécessaire de se plier aux habitudes des utilisateurs...
Ionic et l’adaptation à la plateforme
Plusieurs composants Ionic s’adaptent naturellement à la plateforme native sans intervention spécifique du développeur. C’est le cas par exemple des headers, des onglets, des checkbox ou encore l’animation lors de la transition entre deux écrans. Ces comportements peuvent être surchargés pour offrir un rendu homogène entre toutes les plateformes ou pour limiter les efforts d’adaptation. C’est typiquement le cas des onglets, dont la position est souvent forcée en bas, même si les bonnes pratiques d’ergonomie d’Android indiquent de les placer en haut.
À l’inverse, il peut être choisi d’adapter le comportement d’une directive personnalisée, d’un traitement métier, d’un composant visuel ou ergonomique, en fonction de la plateforme. Ionic propose alors plusieurs moyens pour déterminer quel est le système qui exécute l’application et offrir au développeur le soin de prendre les décisions qui s’imposent.
1. Marqueurs de la plateforme
a. Spécifications de la plateforme dans la vue
Ionic ajoute une classe CSS au conteneur body pour indiquer sur quelle plateforme l’application s’exécute. Cela peut être particulièrement intéressant pour écrire des règles CSS spécifiques. Grâce au mécanisme de cascade du CSS, il est possible de spécifier qu’une classe est appliquée, si et seulement si une autre classe est appliquée à l’un des parents.
Par exemple, pour appliquer uniquement la classe titre, si la plateforme courante est iOS :
platform-ios .titre {
text-align: center;
}
Ionic propose la liste de classes CSS suivantes pour donner des informations sur la plateforme d’exécution :
-
platform-browser : l’application s’exécute sur un navigateur classique par exemple en développement.
-
platform-cordova : l’application s’exécute sur un smartphone par opposition à platform-browser.
-
platform-ios : l’application s’exécute sur un système d’exploitation iOS (iPhone et iPad).
-
platform-ipad : l’application s’exécute sur un iPad (s’ajoute...
Adaptations pour Android
1. Rappel des adaptations natives
Ionic met en place de nombreuses adaptations, que ce soit sur des composants CSS ou des composants JS, destinées à rapprocher l’expérience utilisateur de celle rencontrée dans une application native. Le tableau suivant récapitule les ajustements faits par Ionic sur certains composants, pour les adapter au look and feel d’Android :
Composant |
Adaptation |
select |
Lors du clic sur une liste déroulante de type select, une fenêtre native est ouverte affichant tous les choix possibles sous forme d’une liste native. |
ion-header-bar ion-footer-bar |
Dans les barres de header et de footer, les titres sont alignés à gauche sur Android. Ce comportement peut être modifié en précisant la valeur center ou right dans l’attribut align-title (pour une seule barre) ou à l’aide du service $ionicConfigProvider.navBar.alignTitle. |
ion-nav-back-button |
L’icône du bouton retour est similaire à l’icône native Android. Ce comportement peut être surchargé en ajoutant l’icône à la main ou à l’aide du service $ionicConfigProvider.navBar.backButton.icon. |
ion-nav-buttons |
Les boutons de navigation peuvent être positionnés de part et d’autre du titre en précisant s’ils sont du côté primary ou secondary. Sous Android, les deux côtés primary et secondary se positionnent à droite du titre. |
nav-transition |
Par défaut, les transitions entre deux écrans imitent celles d’une application native Android. Il est possible de modifier ce comportement pour une vue à l’aide de la directive nav-transition ou globalement à l’aide du service $ionicConfigProvider.views.transition. |
ion-spinner |
L’animation de chargement imite par défaut celle d’Android. |
Onglets |
Les onglets apparaissent en haut de l’écran. Ce comportement peut être modifié globalement grâce au service $ionicConfigProvider.views.tabs.style. L’onglet courant est mis en valeur. Ce comportement peut être modifié globalement grâce au service $ionicConfigProvider.views.tabs.position. |
Pour n’affecter qu’un seul système d’exploitation...
Adaptations pour iOS
Le tableau suivant récapitule les ajustements faits par Ionic sur certains composants, pour les adapter au look and feel d’iOS :
Composant |
Adaptation |
select |
Lors du clic sur une liste déroulante de type select, une fenêtre native est ouverte affichant tous les choix possibles sous forme d’une roue que l’utilisateur doit tourner. |
ion-content |
L’attribut padding définit si une marge doit être mise en place entre le haut de l’écran et le contenu. Sous iOS, cette option est activée par défaut, pour compenser la place prise par la barre de statut qui s’affiche en surimpression sur l’application. L’attribut has-bouncing indique si un effet de rebond doit être présent lorsque l’utilisateur arrive à la fin du défilement d’une page. Sous iOS, cette option est activée par défaut. |
ion-header-bar ion-footer-bar |
Dans les barres de header et de footer, les titres sont centrés sur iOS. Ce comportement peut être modifié en précisant la valeur left ou right dans l’attribut align-title (pour une seule barre) ou à l’aide du service $ionicConfigProvider.navBar.alignTitle. |
ion-nav-back-button |
L’icône du bouton retour est similaire à l’icône native iOS. Ce comportement peut être surchargé en ajoutant l’icône à... |
Fichier config.xml
Ionic apporte plusieurs outils qui permettent de spécialiser le comportement d’un bouton, d’une vue ou d’un traitement, en fonction de la plateforme. Ces manipulations effectuées à haut niveau permettent au développeur de gérer les spécificités de la plateforme directement dans le code JavaScript, ce qui entraîne un grand confort en matière de développement et présente de bonnes vertus pour ce qui est de la maintenabilité et de la lisibilité du code.
Cordova propose également de pouvoir spécialiser certains comportements, mais en agissant cette fois à bas niveau. Tout projet Cordova (et par extension tout projet Ionic) possède à sa racine un fichier config.xml. Ce fichier est créé et maintenu par Cordova tout au long du cycle de développement (ajout de plateforme ou de plugins par exemple).
1. Structure du fichier config.xml
Le fichier config.xml d’un projet est un élément fondamental pour tout projet Cordova car il contient toutes les informations nécessaires pour initialiser, construire et packager l’application.
Le fichier est découpé en plusieurs sections. Chacune d’entre elles peut faire référence à l’application globale ou à une plateforme en particulier. Par défaut, il existe une seule section qui paramètre globalement l’application.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<widget
id="com.ionicframework.enilivreionic"
version="0.0.1"
xmlns="http://www.w3.org/ns/widgets" ...