WWDC 2016 : Bonnes pratiques pour améliorer son application Apple

wwdc16 bonnes pratiquesAvec l’ensemble des changements induits par les nouveautés annoncées lors de la WWDC 2016, une session a été dédiée pour rappeler ou présenter quelques bonnes pratiques faciles à mettre en place pour améliorer ses applications, que ce soit sous iOS, macOS, tvOS ou encore watchOS.

Comment réduire la dette technique

La dette technique existe aussi dans le mobile, car au fur et à mesure des nouvelles versions des OS elle ne cesse de s’alourdir. Pour une application iOS, le premier point à savoir est d’avoir un support à partir de la version N-1. En effet, les études montrent que les personnes sous les OS Apple passent rapidement aux versions supérieures proposées. Finalement, le pourcentage des utilisateurs sous des versions plus anciennes est minime (voir ci-dessous).

déploiement iOS bonnes pratiques

Par exemple, avec iOS, nous sommes aujourd’hui en version 9.3, il suffit donc de cibler la version 8.4 (la dernière version d’iOS 8).

Le deuxième point consiste à réduire les warnings dans un projet. Ce point est particulièrement important, notamment pour les développeurs Swift, car certains avertissements concernent des méthodes dépréciées. Pour éviter de laisser passer les warnings, il est désormais possible avec Swift et Xcode 8 de mettre les warnings en erreurs, ce qui force à les corriger.

Troisième point, qui peut parfois sembler anodin, est le support de l’accessibilité. Heureusement, il est très facile grâce à Xcode et Interface Builder de résoudre cela (voir ci-dessous).

bonne pratique accessibilité

Quatrième et dernier point, qui aide à l’internationalisation d’une application, est l’utilisation des APIs locales. On retrouve par exemple des APIs pour les dimensions, pour le calendrier, les dates, les nombres, etc. Il ne faut donc pas hésiter à s’appuyer dessus, et ne pas chercher à réinventer la roue.

Tirer parti des actions du 3D Touch sur iOS

Avec l’arrivée de l’iPhone 6 et ses nouvelles gestures liées à la pression du doigt, de nouvelles possibilités se sont présentées pour les développeurs. Les utilisateurs possédant un iPhone 6 ou plus récent ont maintenant l’habitude d’utiliser les gestes de Peek, Pop et Quick. Il est donc très agréable pour les utilisateurs lorsqu’une application gère ces gestes.

Utiliser le Catalogue d’Assets

Il est encore fréquent aujourd’hui de voir qu’un projet gère ses images à l’ancienne. Si les développeurs sont encore timides pour changer leurs habitudes, Apple incite pour que ceux-ci passent à l’utilisation du Catalogue d’Assets, un outil qui facilite vraiment la vie des développeurs et intégrateurs.

Le Catalogue d’Assets se base sur la copie des fichiers, ce qui permet de ne pas avoir de référence sur la localisation de base. Dans un projet existant et comportant déjà des images stockées « à l’ancienne », il est possible d’importer ces images dans le catalogue. Celui-ci affichera les images éligibles au mapping, effectué en fonction de la taille des images, vers trois formats : 1x, 2x et 3x.

L’import d’images

Lors de l’import d’images, le catalogue d’Assets va pouvoir intelligemment mapper les trois dimensions grâce au nommage des fichiers (exemple : logo@2x.png, logo@3x.png). Il est important de fournir le plus souvent possible toutes les dimensions demandées, car si une de ces tailles n’est pas présente, l’image sera étirée ou rétrécie selon les dimensions de base. Cette opération se fait au runtime, ce qui impacte directement la qualité finale des images dans une application, ainsi que les performances.

Les assets peuvent être représentés de multiples façons, sur une plateforme ou plus (à chaque plateforme ses dimensions à respecter). Non seulement la plateforme visée peut-être différenciée, mais aussi certaines caractéristiques comme la mémoire ou la version supportée de Metal.

Une application peut évidemment avoir plusieurs catalogues en cas de besoin, pour plus de lisibilité.

Les formats d’image possibles

Pour faciliter le travail, il est possible de travailler avec deux formats d’images. Ces formats sont le PNG, qui fonctionne avec le système de scale expliqué plus haut, et le format PDF. Le format PDF est vectoriel, et une option dans Xcode permet au scale de s’effectuer au buildtime selon le besoin, ce qui simplifie la construction du catalogue d’Assets.

Côté code, c’est le chargement des images qui change. Il est plus concis et utilise maintenant le cache après le premier chargement de l’image.bonne pratique chargement d'image

Astuces boutons arrondis

Nous l’avons vu, la fonction première du catalogue d’Assets est de gérer les images d’une application. Mais ce n’est pas tout : elle possède un éditeur d’Assets, qui s’avère lui aussi très utile.

C’est le cas pour avoir à partir d’une image un bouton arrondis, dont la taille s’adaptera à l’écran. Auparavant, il fallait passer du côté du code, et définir l’arrondi avec la propriété image.stretchableImage.

Maintenant, grâce à l’éditeur d’Assets, il est possible de diviser son image en différentes parties : c’est l’Asset Slicing. En définissant des zones sur l’image en question à ne pas modifier (typiquement, les bords arrondis), et des zones à répéter, l’Asset saura s’adapter selon l’effet voulu.

Être actif dans la communauté

Depuis l’annonce de Swift, devenu Open Source, et une réelle ouverture d’Apple vers la communauté des développeurs, ces derniers sont mis à contribution. Dans ce sens, les équipes d’Apple encouragent fortement les développeurs à soumettre les bugs qu’ils rencontrent en Swift. Une adresse pour cela : BugReport.apple.com. Sans que ce soit réellement une bonne pratique, il est bénéfique pour tous de participer à la communauté.

Rendre son application plus adaptive avec l’injection de dépendance

Si le principe d’injection de dépendance est généralement connu pour les développeurs .NET, il l’est à priori un peu moins pour les développeurs Swift ou Objective-c. C’est pour cela que les équipes d’Apple souhaitent mettre ce pattern en avant. Le but premier de l’injection de dépendance est de rendre une application plus adaptive, notamment pour les vues. L’idée est de rendre les différents ViewControllers indépendants les uns des autres, afin de pouvoir changer facilement l’enchainement selon l’expérience.

Profiter du playground

Pour les développeurs qui travaillent avec Xcode, le playground est devenu un outil très utile. Comme son nom l’indique, il permet d’expérimenter du code façon « bac à sable », et ce de façon très simplifiée et légère.

Il présente malheureusement quelques limites qui demandent encore d’utiliser un projet de test et le simulateur dans certains cas.

Avec l’arrivée proche d’Xcode 8, le playground se voit amélioré. Il va supporter :

  • Le live Playground : un affichage en temps réel d’éléments graphiques
  • Un accès au fichiers ressources de l’application
  • Une gestion des tâches asynchrones (activation d’une variable pour que le playground tourne à l’infini)

Utiliser le cache lors de l’appel à des webservices

Lorsqu’une application utilise des webservices, le cache devient un grand allié du développeur. Le principe est d’avoir de base un fichier en cache qui contient déjà des données. S’il n’y a pas de connexion internet, ce fichier va être utilisé pour avoir des données à afficher. Sinon, la requête au webservice va vérifier si les données ont changé, auquel cas le fichier de cache est mis à jour avec les nouvelles données. Cela évite des appels répétitifs parfois lourd si beaucoup de données transitent.

Cette bonne pratique est un basique dans le développement mobile, mais il est intéressant de la rappeler.

Respecter les guidelines UI sur chaque plateforme

La multiplicité des plateformes proposées par Apple (iOS, macOS, tvOS, watchOS), et l’hyper connectivité entre celles-ci offre d’autant plus d’opportunités aux développeurs d’applications. Mais il ne suffit pas de cibler toutes les plateformes pour faire de son application un succès. A chaque plateforme correspond son expérience propre. Si Apple pousse les créateurs d’application à être présents sur toutes leurs plateformes, il est conseillé de respecter leurs différentes guidelines.

Une des principales astuce consiste à utiliser les directives de code pour adapter celui-ci en fonction de l’interface sur laquelle il tournera. Mais il faut tout de même se rapporter aux documents de guidelines. Il existe d’ailleurs sur le site d’Apple des guides rapides pour chaque plateforme :

Le mot de la fin

Nous avons vu dans cet article un ensemble de bonnes pratiques mises en avant par les équipes d’Apple à la WWDC 2016. Tous ces conseils ont pour but de favoriser l’adoption des applications par les utilisateurs, ou d’améliorer leur pérennité. Que ce soit côté développement ou design, les bonnes pratiques présentées sont aisément applicables.

Alors n’attendez plus pour créer ou améliorer vos applications !

Lien

Les mystères d’AutoLayout

A la WWDC 2015, qui s’est déroulée au mois de juin, Apple a annoncé des nouveautés comme iOS 9, Apple Music, ou encore OS X « El Capitan ». Voilà la majeure partie de ce que la plupart des gens auront retenu cette année. Mais pour les développeurs, cet événement aura aussi été une vraie mine d’or en termes de conférences techniques, et pour faire suite à mon précédent article sur les bases du storyboard, nous allons rester sur le même sujet et passer au niveau supérieur.

Accrochez vos ceintures, car dans cet article nous allons lever le voile sur certains mystères liés aux interfaces utilisateurs sous iOS, dont une grande partie a été traitée lors de cette WWDC 2015. Les nouveautés et astuces abordées, qui sont pour certaines cocasses, peuvent apporter une aide conséquente pour les développeurs qui travaillent avec Interface Builder ou directement depuis le code, qu’ils soient débutants ou plus expérimentés.

Accéder à l’article sur le blog de Soat