\tIl est essentiel de th\u00e9sauriser l’exp\u00e9rience acquise lors d’un d\u00e9veloppement, de consigner l’exp\u00e9rience des essais-erreurs commises au cours du cycle de cr\u00e9ation d’une application par exemple. Evidemment, cet imp\u00e9ratif est int\u00e9gr\u00e9 dans la m\u00e9thode agile sous la forme d’un rituel nomm\u00e9 “R\u00e9trospective d’it\u00e9ration”. Ce dernier a pour fonction d’exprimer un retour sur l\u2019it\u00e9ration qui a eu lieu en pointant toutes les erreurs\/difficult\u00e9s auxquelles l’\u00e9quipe a pu \u00eatre confront\u00e9e.
\n\tPointer les erreurs est une chose, isoler les solutions en est une autre… Et que dire d’une synth\u00e8se digeste rapprochant les deux points de vue. A premi\u00e8re vue indispensable mais rarement produite. C’est pourtant l’objet m\u00eame ce billet : existe-t-il un corpus de bonnes pratiques sur le d\u00e9veloppement mobile tant sous iOS que sous Android pour les mois pr\u00e9sents et \u00e0 venir ?<\/p>\n
\tEh, bien disons qu’un tel document existe, c’est une chose assez rare mais pas introuvable. Une recherche rapide sur le web permet de d\u00e9couvrir un certain nombre de documents nous en avons s\u00e9lectionner deux qui donnent une liste de bonnes pratiques tant pour Android que pour iOS.<\/p>\n
\tEn voici les sources en anglais et ces recommandations sont prescrites par une entreprise qui fait disons plut\u00f4t autorit\u00e9 en mati\u00e8re de d\u00e9veloppement : Futurice http:\/\/futurice.com\/<\/a>.<\/p>\n \tGrosso modo, le seul \u00e9l\u00e9ment manquant dans la liste des bonnes pratiques est l’utilisation de cette outil indispensable pour la livraison en continu dans les deux environnements : iOS et Android. Source : https:\/\/fastlane.tools\/<\/a><\/p>\n On se contentera dans un premier temps d’\u00e9num\u00e9rer les bonnes pratiques concernant iOS. Celles concernant Android feront l’objet d’un autre billet.<\/b><\/p>\n \tLe texte est r\u00e9dig\u00e9 comme un quasi manifesto, pas de gras juste des injonctions courtes et justifi\u00e9es sur les meilleures choses \u00e0 faire pour assurer un peu de p\u00e9rennit\u00e9 au code d’un application iOS et de s\u00e9r\u00e9nit\u00e9 au PO comme au chef de projet ! Je vous invite \u00e0 lire le tout en d\u00e9tail et \u00e0 vous en impr\u00e9gner au point d’en faire un mantra. J’ai s\u00e9lectionn\u00e9 ici les meilleurs points ne privil\u00e9giant les aspects les moins techniques disons-le.<\/p>\n \t1. Utiliser git et le fichier \t2. La gestion de d\u00e9pendances<\/b> \t3. Structure du Project<\/b> \t4. Localization ou traduction <\/b> Pour des traductions plus complexes notamment la gestion du pluriel, il vaut mieux utiliser le format \tSource : https:\/\/speakerdeck.com\/hasseg\/localization-practicum<\/a> <\/p>\n \t5. Constants ou variables globales<\/b> \t6. Version en branche<\/b> \t7. Pr\u00e9requis sur la version minimale de iOS <\/b> Il existe un certain nombre de ressources pour s\u00e9lectionner la version minimale de iOS souhait\u00e9e en fonction des usages que vous allez cibler Une ressource officielle :<\/b><\/p>\n Des ressources tierces mais riches d’enseignements :<\/b><\/p>\n Utiliser une librairie en vue d’ajouter une fonction est \u00e0 double tranchant. En effet, m\u00eame si cette librairie r\u00e9sout le probl\u00e8me dans l’imm\u00e9diat, l’ajout d’une librairie additionnelle peut se r\u00e9v\u00e9ler probl\u00e9matique en terme de maintenance ou lors du passage \u00e0 une version sup\u00e9rieure de iOS. Il est aussi tout \u00e0 fait possible que la fonctionnalit\u00e9 souhait\u00e9e, rendue possible par la librairie, deviennent une fonctionnalit\u00e9 du code officiel d’Apple. <\/p>\n Toujours penser \u00e0 r\u00e9soudre le probl\u00e8me en utilisant en priorit\u00e9 le framework natif d’Apple.<\/p>\n Voici une liste des librairies dont l’objectif est de r\u00e9duire le code redondant ou de permettre la r\u00e9solution de probl\u00e8mes complexes et r\u00e9currents la calcul de la date par exemple. Bien sur plus la maitrise du code natif Apple est grande moins le recours \u00e0 des librairies additionnelles est sans doute n\u00e9cessaires.<\/p>\n En tous les cas, voici la liste des librairies les plus usuelles.<\/p>\n 8.1. AFNetworking<\/b> Source : https:\/\/github.com\/AFNetworking\/AFNetworking<\/a><\/p>\n 8.2. La librairie DateTools<\/b> Source : https:\/\/github.com\/MatthewYork\/DateTools<\/a><\/p>\n 8.3. Auto Layout Libraries<\/b> Fort heureusement, la version disponible pour iOS 9 donne des sp\u00e9cifications plus concises en mati\u00e8re de contraintes, la class Si vous \u00eates bloqu\u00e9 sur une version d’iOS ancienne, ne disposant que du traditionnel Source: Masonry\/SnapKit<\/a><\/p>\n Pour le Swift, Il existe aussi Cartography, qui fournit un compl\u00e9ment puissant au langage natif. Pour les d\u00e9veloppeurs plus conservateurs, FLKAutoLayout offre un wrapper compl\u00e9mentaire \u00e0 l’API natif de Apple, sobre et efficace mais pas magique pour autant !<\/p>\n Voici les premiers points essentiels de ce recueil des bonnes pratiques gracieusement fournies par Futurice. On vous invite vivement \u00e0 prolonger la lecture de ce document sur si vous souhaitez acqu\u00e9rir une expertise de Lead Dev en iOS ! Les points sont nombreux et plut\u00f4t pr\u00e9cis : Architecture, gestion des Assets, des recommandations de de pr\u00e9sentation de code (Coding Style)… bref une vue d’ensemble.<\/b><\/p>\n Nous y ajoutons un sur la liste nomm\u00e9 KSCrash qui gagne \u00e0 \u00eatre connu. Il existe aussi des solutions pour analyser ces logs. A premi\u00e8re vue, un outil comme GoAccess https:\/\/goaccess.io\/<\/a> ou comme The Log File Navigator http:\/\/lnav.org\/features\/<\/a> pourrait faire l’affaire ou un outil comme le Log Parser 2.2 de microsoft<\/a>.<\/b><\/p>\n Une fois que vous avez s\u00e9lectionn\u00e9 et impl\u00e9ment\u00e9 l’outil de crashlog, il y a s’assurer que vous faites une sauvegarde de l’archive Xcode (.xcarchive)<\/i> de chaque build que vous publiez. L’archive contient le binaire de l’application et le symbole du d\u00e9bogage (dSYM)<\/i> qui vous sera n\u00e9cessaire pour avoir les rapports de crash pour chaque version en particulier. <\/p>\n En conclusion : les recommandations c’est bien ! Encore faut-il qu’elles soient partag\u00e9es par tous, \u00e9ventuellement discut\u00e9es mais jamais impos\u00e9es ! On a d\u00e9lib\u00e9r\u00e9ment pass\u00e9 sous silence les recommandations en mati\u00e8re d’\u00e9diteur ou de coding style, de nomenclature des variables… On esp\u00e8re souvent, parfois \u00e0 tort, que l’\u00e9quipe de d\u00e9veloppement est d\u00e9j\u00e0 d\u00e9positaire des bonnes pratiques. Sans \u00eatre chien avec les d\u00e9vs, c’est souvent l\u00e0 qu’est l’os, rat que je suis !<\/b><\/p>\n \tMerci \u00e0 alaeddine ouertani pour ces ressources<\/b><\/p>\n Il est essentiel de th\u00e9sauriser l’exp\u00e9rience acquise lors d’un d\u00e9veloppement, de consigner l’exp\u00e9rience des essais-erreurs commises au cours du cycle de cr\u00e9ation d’une application par… <\/p>\n\n
Notre petite touche personnel pour iOS comme pour Android<\/h4>\n
\n\tL’outil se marrie en effet sans probl\u00e8me avec CocoaPods et Gradle.<\/p>\nLes bonnes pratiques sous iOS selon futurice<\/h4>\n
.gitignore<\/code><\/b>
\n\tPour chaque projet iOS, d\u00e9pos\u00e9 sur git, qu’il soit Swift ou en Objective-C, le mieux est de placer en racine un fichier .gitignore<\/code> afin d’\u00e9viter d’int\u00e9grer des donn\u00e9es inutiles ou sensibles (param\u00e8tres utilisateurs, fichiers temporaires etc.)<\/p>\n\n
.gitignore<\/code> pour un projet en Swift<\/a><\/li>\n.gitignore<\/code> pour un projet en Objective-C<\/a><\/li>\n<\/ul>\n
\nLa gestion des libraires tierces peut vite tourner au casse-t\u00eate et cela peut potentiellement hypoth\u00e9quer vos chances de publication sur l’apple store. Il est donc imp\u00e9ratif de g\u00e9rer pr\u00e9cautionneusement ces d\u00e9pendances \u00e0 l’aide notamment de CocoaPods, facile \u00e0 int\u00e9grer et grandement utile.<\/p>\n
\nVu le nombre de fichiers qui ne manqueront d’\u00eatre cr\u00e9es, il est fortement conseill\u00e9 d’adopter une structure de projets en fonction de votre architecture.<\/p>\n\r\n\t\u251c\u2500 Models\r\n\t\u251c\u2500 Views\r\n\t\u251c\u2500 Controllers (or ViewModels, if your architecture is MVVM)\r\n\t\u251c\u2500 Stores\r\n\t\u251c\u2500 Helpers\r\n\t<\/pre>\n
\n\tLorsque vous concevez une application multilingue, il est imp\u00e9ratif de consigner toutes les chaines \u00e0 traduire dans un fichier de localisation. Il est alors facile de retrouver les chaines si elles doivent \u00eatre corrig\u00e9es et de compiler ensuite l’application dans une langue ou dans une autre en passant l’argument de la langue.<\/p>\n-AppleLanguages (Spanish)<\/pre>\n
.stringsdict<\/code> que le fichier localizable.strings<\/code><\/p>\n
\n\tIl est souhaitable de limiter au maximum la port\u00e9e des variables globales ou Constants de vos applications. Si certaines de ces constantes sont malgr\u00e9 tout utilis\u00e9es \u00e0 travers de toute l’application, il est l\u00e0 aussi pr\u00e9f\u00e9rable de les conserver au m\u00eame endroit dans le code. <\/p>\n
\nBien s\u00fbr, on ne dira jamais assez l’importance de g\u00e9rer des versions de l’application via des branches sur Git afin d’isoler les \u00e9volutions dans des branches s\u00e9par\u00e9es.<\/p>\n
\nIl est important de d\u00e9finir pr\u00e9alablement la version minimale sur laquelle votre application doit tourner. C’est un \u00e9l\u00e9ment essentiel pour estimer la charge de travail n\u00e9cessaire \u00e0 la conception de votre application et des fonctionnalit\u00e9s possibles ou non. <\/p>\n
\nUse these resources to gather the data necessary for making this choice:<\/p>\n\n
https:\/\/developer.apple.com\/support\/app-store\/<\/a><\/li>\n<\/ul>\n\n
http:\/\/iossupportmatrix.com<\/a><\/li>\n
https:\/\/david-smith.org\/iosversionstats\/<\/a><\/li>\n
https:\/\/mixpanel.com\/trends\/#report\/ios_frag<\/a><\/li>\n<\/ul>\n8. Librairies usuelles<\/h4>\n
\nLa gestion du “Multithreading and Queues” voil\u00e0 ce \u00e0 quoi sert cette librairie. A n’en pas douter, c’est la base de toutes les applications modernes et “api-centric”.<\/p>\n
\nPas la peine de r\u00e9inventer la roue, il existe fort heureusement une librairie qui couvre tous les besoins de choix dans la date.<\/p>\n
\nSi vous souhaitez coder vos vues directement, il y a de fortes probabilit\u00e9s que vous soyez confronter \u00e0 la syntaxe complexe propre \u00e0 Apple – le corpus traditionnel du NSLayoutConstraint<\/code> ou tout ce que comprend le language “Visual Format” qui d\u00e9finit les contraintes, les dimensions et l’espacement standard… etc.
\nSource : Visual Format Language<\/a><\/p>\nNSLayoutAnchor<\/code>.
\nSource : NSLayoutAnchor<\/a><\/p>\nNSLayoutConstraint<\/code>, voici la librairie Masonry\/SnapKit peut-\u00eatre une solution pour parer aux principaux d\u00e9fauts de NSLayoutConstraint<\/code>.<\/p>\n\n
Un dernier point : les Crash Logs<\/H4>
\nC’est un \u00e9l\u00e9ment essentiel pour oeuvrer \u00e0 l’am\u00e9lioration de votre application, une sorte “feedback loop” automatis\u00e9e. Le principe en est simple, tous les crash de vos applications qui surviennent sont consign\u00e9s sur un serveur dans des fichiers de log auxquels vous avez bien \u00e9videmment acc\u00e8s. Il est possible d’impl\u00e9menter manuellement ce type de fonctionnalit\u00e9 en utilisant par exemple PLCrashReporter et de l’interfacer avec votre propre “backend” mais il existe des solutions cl\u00e9s-en-main type Crashlytics ou HockeyApp, payante certes mais bien plus confortables.<\/p>\n\n
http:\/\/www.crashlytics.com<\/a><\/li>\n
http:\/\/hockeyapp.net<\/a><\/li>\n
https:\/\/www.crittercism.com<\/a><\/li>\n
https:\/\/mint.splunk.com<\/a><\/li>\n
https:\/\/instabug.com\/<\/a><\/li>\n
https:\/\/www.plcrashreporter.org<\/a><\/li>\n
https:\/\/github.com\/kstenerud\/KSCrash<\/a><\/li>\n<\/ul>\nEn savoir plus<\/h2>\n
\n
https:\/\/github.com\/futurice\/ios-good-practices<\/a><\/li>\n
https:\/\/github.com\/futurice\/android-best-practices<\/a><\/li>\n
http:\/\/fr.slideshare.net\/jldavid\/ios-coding-best-practices-12969046<\/a><\/li>\n
http:\/\/www.alexruperez.com\/ios-coding-best-practices<\/a><\/li>\n
http:\/\/blog.octo.com\/mon-projet-est-il-agile\/<\/a><\/li>\n
https:\/\/github.com\/smartnsoft\/droid4me<\/a><\/li>\n
https:\/\/github.com\/smartnsoft\/ios4me<\/a><\/li>\n
https:\/\/github.com\/Azure\/azure-mobile-engagement-app-android<\/a><\/li>\n
https:\/\/github.com\/Azure\/azure-mobile-engagement-app-ios<\/a><\/li>\n
http:\/\/code4app.net\/<\/a><\/li>\n
https:\/\/iosdev.tools\/<\/a><\/li>\n
http:\/\/iosdevelopertips.com\/<\/a><\/li>\n
http:\/\/nshipster.com\/<\/a><\/li>\n
https:\/\/www.raywenderlich.com\/tutorials<\/a><\/li>\n
https:\/\/github.com\/kstenerud\/KSCrash<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"