Comprendre - La Programmation Fonctionnelle des Applications Mobiles

Posted on 23 Aug, 2015 by Administrator

La locution latine "Abondance de biens ne nuit pas" ne serait-elle pas en passe de devenir le meilleur ennemi de l'application mobile, ceci qu'elle propose un service réservé aux professionnels ou ouvert à tous, gratuitement ou pas ? Quelques chiffres, quelques évidences pourraient bien plaider en ce sens :

  1. 2007-2009 : commercialisation des premiers smartphones Apple, Android, Blackberry et Microsoft Mobile;
  2. 2009 : total cumulé des téléchargements d'applications mobiles : 2 milliards;
  3. 2015 : total cumulé des téléchargements d'applications mobiles : 200 milliards;
  4. 2017 : total prévisionnel des téléchargements d'applications mobiles : 200 milliards;

Si rien ne nous interdit d'accumuler livres, CD et autres vecteurs physiques qui attisent heureusement notre curiosité, la mémoire de stockage limitée de nos smartphones et tablets nous apprend à contingenter le nombre d'applications et de contenus mobiles que nous entendons y installer et, plus encore, y conserver durablement.

Des stratégies très concrètes se mettent en place : le lecteur de musique en ligne remplace la bibliothèque locale iTunes ; le lecteur de podcasts passe, lui aussi, au streaming en ligne et, plus généralement, les applications qui stockent localement de grandes quantités d'information sont supplantées par celles qui savent puiser en temps réel leurs contenus sur le Web et dans le Cloud.

 

Il y a trois manières de se ruiner, disait le grand Rothschild : le jeu, les femmes - et les ingénieurs. Les deux premières sont plus agréables - mais la dernière est plus sûre. Auguste Detœuf

Les premières applications mobiles pour smartphones et tablets ont souvent connu des destins partagés et de très courtes durées de vie. Des paris techniques aventureux privilégiant la réutilisation trop immédiate de savoirs-faire à priori disponibles (Objective-C, Java, C#), l'intégration plutôt que le développement direct et l'hybridation dans un contexte de grande immaturité des normes du web mobile  (HTML5/CSS3/JS) ont trop souvent porté les premiers clients à se faire les cobayes d'un univers de promesses commerciales et techniques non tenues.

La nature ayant horreur du vide et la pression commerciale ne laissant que peu de place au développement d'un génie logiciel adapté aux besoins propres de la plate-forme mobile, l'offre technique, loin de se stabiliser, a tendu à se faire, marketing aidant, de plus en plus illisible. De très nombreux frameworks Javascript sans contenu technologique propre sont apparus. Ils partagent un objectif commun : concurrencer les langages et les protocoles traditionnels (Objective-C, Java, C#, TCP, HTTP REST,...) en proposant des outils de développement censés porter, à peu de frais, le développement mobile à un niveau d'abstraction favorisant le recyclage du développeur web en développeur mobile.

Or, ce n'est pas parce qu'Objective-C, Java et C# s'avèrent des univers de développement mobile peu flexibles que le pari du 10% Natif/60% Javascript/30% HTML5/CSS3 s'avèrera, selon notre propre expérience directe du développement mobile natif et hybride, plus pertinent.

Le problème clé se situe ailleurs : hors applications mobiles préinstallées, les applications que la plupart des mobinautes plébicitent et conservent durablement sur leurs devices sont habituellement codées par des TPE ou des Indépendants particulièrement talentueux qui, bien conscients des insuffisances des méthodes et des outils de développement mobile "mainstream" ont fait le choix, soit de développer leurs propres outils de GLU (global linkage unit : Android SDK/NDK/JNI/C/C++ sous Android, XCode/C/C++ sous iOS), soit de s'approprier les très rares environnements de GLU déjà disponibles et pleinement exploitables en environnement mobile (Scala/Scaloïd sous Android, Scala/Migeran sous iOS, LiveCode sous iOS et Android).

Le propre des TPE et des Indépendants missionnés pour développer des solutions mobiles est qu'ils ne disposent pas des marges d'erreur que peuvent s'autoriser les grandes ESN et SSII. Si pour ces dernières, il importe avant tout de mobiliser une armée de planteurs de clous (appointés au coup de marteau), David leur préfèrera obligatoirement l'élégance toujours plus féconde, enrichie et renouvelée à l'infini de l'économie de moyens, entendue comme une frontière ouverte. C'est en s'appropriant les méthodologies de modélisation et de coding les plus parcimonieuses en temps de développement, en puissance de calcul et en espace de stockage qu'il s'astreint à une discipline professionnnelle lui permettant d'élaborer des expertises que Goliath ne reprendra - peut-être - que beaucoup plus tard à son compte, dans cinq ou dix ans, quand les trois étapes d'acceptabilité naturelle de l'innovation auront fait leur chemin, de "ridicule", d'abord, à "dangeureuse"ensuite pour, à terme, aboutir à "évidente", naturellement.

 

Quelle Politique de projet "Mobilité"

La question qui se pose, dès lors, est bien de savoir s'il n'est pas en train d'apparaître et de se développer un fossé toujours plus large entre différentes approches possibles de la gestion de projet "Mobilité" :

  1. l'approche des ESN/SSII très focalisée sur la gouvernance des outils "mainstream" et la gestion de flottes de développeurs très fermement tenus en laisse à l'écart des ressources du génie logiciel;
  2. l'approche des TPE et Indépendants pour qui il est, au contraîre, vital de miser sur les meilleures méthodes de modélisation et de coding que propose ce même génie logiciel, ceci à l'effet de pouvoir vivre dans l'ombre de Goliath en adressant les clients qui n'intéressent pas ce dernier, faute de budgets en rapport avec ses capacités d'intervention.

 

Programmation Fonctionnelle et Développement Mobile

La Programmation Fonctionnelle - sous Scala ou Livecode - des composants de GLU du système d'information mobile est la première approche permettant aux TPE et aux Indépendants de constituer des offres performantes et fiables capables de se substituer à la plupart des propositions de Goliath, aussi bien en matière de solutions louées en mode SAAS que de prestation de service, ceci en réservant aux clients le double avantage d'une grande flexibilité des solutions livrées (scalabilité, versioning,...) et d'un rapport "valeur d'usage > valeur d'échange" en moyenne quatre (4) fois plus favorable que ce que Goliath est, pour sa part, en mesure de proposer à performances égales.

 

Programmation Multi-Plateforme et Développement Mobile

La Programmation Multi-Plateforme est le deuxième atout permettant aux TPE et Indépendants de ne pas diviser leurs forces entre plus de modèles et langages de développement qu'il n'en faut pour couvrir l'ensemble des besoins à adresser pour produire un système d'information mobile complet et fiable, soit :

  1. un langage de GLU de codage des clients mobiles iOS et Android (à choisir, en programmation fonctionnelle, entre Scala et Livecode);
  2. un langage de GLU de codage du serveur d'application adressant les clients mobiles iOS et Android (à choisir, en programmation fonctionnelle, entre Scala et Livecode);
  3. un langage de GLU de codage du back-office de messagerie Push (à choisir, en programmation fonctionnelle, entre Scala et Livecode);
  4. un langage de GLU de codage du serveur d'application (Linux) de messagerie Push iOS et Android (à choisir, en programmation fonctionnelle, entre Scala et Livecode);
  5. le langage Javascript, accompagné d'une librairie intégrée (AngularJS, JQuery,...);
  6. les systèmes de balises HTML5 et CSS3;
  7. la parfaite maîtrise du protocle HTTP(S) REST;
  8. la parfaite maîtrise de l'urbanisation des SGBDRO ACID-SQL;
  9. le langage SQL propre au SGBDRO mis en œuvre;
  10. la parfaite maîtrise des environnements de compilation Apple XCode et Android SDK;
  11. la parfaite maïtrise des environnements de publication iTunes Store et Google Play;
  12. le langage de script Bash/Shell Linux;
  13. une parfaite maîtrise des protocoles de messagerie SendMail/PostFix;
  14. une parfaite maïtrise de l'Infogérance de niveau 3 des serveurs Linux (sécurité matérielle, maintenance et sécurité système, cron backups,...) en mode direct ou délégué;

Cette liste reflète directement l'organisation de la chaine de production qui permettra à la TPE ou à l'indépendant d'œuvrer de manière optimale, ceci en opérant un même langage de GLU des § 1 à 4 et en réservant le plus grand soin aux traitements des § 8 à 9 se rapportant à l'urbanisation des bases de données et au coding des requêtes SQL.

C'est de la qualité des traitements modélisés et codés aux § 1 à 4 et § 8 à 9 que dépendra très directement la performance globale du système d'information finalisé, le reste se rapportant, peu ou prou, à des traitements subsidiaires de gestion automatisée en mode "maître-esclave".

On constatera que, dans un environnement de développement multi-plateforme parfaitement conditionné, deux langages seulement (Scala ou LiveCode en langage de GLU, SQL en langage d'adressage du serveur de bases de données ACID-SQL) mobiliseront l'essentiel des missions se rapportant à la modélisation et au coding du système d'information mobile distribué.

 

Programmation Hybride et Développement Mobile

Contrairement à ce qui se dit trop souvent, le développement 100% natif, aujourd'hui très en vogue en réaction aux succès partagés des applications mobiles codées, hier, par mise en oeuvre de frameworks hybrides immatures (Phonegap/Cordova, HTML5/CSS3/JQuery), ne sera probablement jamais une panacée.

L'application native exploitant un webview embarqué HTML5/CSS3/Javascript en mode "maître-esclave" constitue, en effet, le troisième atout permettant aux TPE et Indépendants de proposer à leurs clients des applications mobiles douées d'une bien meilleure fluidité de fonctionnement que celle qui caractérise les applications 100% natives, ces dernières fonctionnant le plus souvent en mode "single-thread" tandis que les applications hybides passent évidemment en mode "multi-thead" à raison de la présence du webview qu'elles embarquent.

La seule question, dès lors encore pendante, consiste à décider si le webview devra savoir afficher des données préalablement chargées depuis le cloud en mode asynchrone et stockées localement dans l'entrepos sandboxé de l'application mobile (mode avion autorisé) ou se contenter de savoir les appeler à la demande en mode synchrone, un simple serveur web distant étant alors chargé de lui répondre. Les deux modèles présentent leurs propres avantages mais le second répond le plus souvent très bien aux besoins de la plupart des solutions mobiles, ceci en limitant la duplication des ressources spécifiquement dédiées à son fonctionnement.

 

 

 

 

Pour aller plus loin :

https://fr.wikipedia.org/wiki/Application_mobile

http://www.technocompetences.qc.ca/sites/technocompetences.qc.ca/files/uploads/industrie/etudes-et-rapports/2013/Etude_mobilite_2013.pdf

https://fr.wikipedia.org/wiki/Téléphonie_mobile