Titanium mobile : genèse, principes et aléas d’une solution de développement mobile Cross-Platform (2/3)

Ce billet constitue la deuxième partie de notre série d’articles au sujet de Titanium, après le premier article, qui abordait les concepts clé du framework et de la plateforme d’Appcelerator.

Cette fois-ci, nous allons nous attacher à comprendre pourquoi Titanium cristallise parfois les critiques de développeurs débutants sur le framework, et comment contourner les écueils qui sont à la racine de ces critiques.

Section intitulée partie-2-titanium-en-pratique-aka-quot-devenir-adepte-de-la-rigueur-quotPartie 2 : Titanium en pratique, aka. « devenir adepte de la rigueur »

Section intitulée le-cycle-de-developpement-classiqueLe cycle de développement classique

Mettre sur pieds une application mobile correspond en réalité à un cycle projet bien plus vaste que le simple développement technique de l’application. Il est ainsi nécessaire de connaître les contraintes d’ergonomie des différentes plateformes, d’appliquer les guidelines fournies par les éditeurs de SDK – Apple ou Google en tête – mais aussi de bien définir la cible du produit (des personas adaptés doivent être établis), sa cinématique de navigation (des mockups sont incontournables AVANT le début du développement) ou encore l’origine des données manipulées. Si, par exemple, l’application doit présenter à l’utilisateur des données issues de Web Service, ou si elle permet de réaliser des opérations transactionnelles à l’aide de Web Services issus d’un site Web, vous devez vous assurer que ces Web Services sont stables avant d’entamer le développement mobile – sinon mener deux projets en parallèle (ie., le développement des Web Services et de la librairie de consommation) sera très coûteux et, souvent, source de problèmes et d’erreurs d’architecture.

Reprenons notre application que nous avons laissée au niveau d’un simple « HelloWorld ». Nous allons naturellement vouloir l’enrichir des fonctionnalités de notre choix. C’est généralement à ce niveau-là que les débutants peinent un peu à choisir comment architecturer leur application.

Titanium est en effet un framework, mais un framework assez lâche. En fait, si on souhaite simplifier, il s’agit presque d’un environnement d’exécution javascript enrichi par le biais des APIs natives Titanium et… ça s’arrête là ! Pas de MVC qui force à une structure d’application bien conçue, un outillage somme toute assez restreint, et une grande liberté d’organisation pour le développeur, qui n’a à sa disposition que Ti.include() et require() pour permettre le découpage de l’application en plusieurs fichiers.

Avec un peu de pratique et de l’expérience, vous apprendrez progressivement à contourner les obstacles et à adopter les bons patrons de conception – création de contrôleurs, isolation de librairies dans des modules CommonJS, ou encore utilisation d’un ORM pour le traitement de vos données locales (promis, pas d’auto-promo là dedans).

Section intitulée les-racines-du-mal-ou-les-raisins-de-la-colereLes racines du mal ou les raisins de la colère

Les promesses de la plateforme sont brillantes, et très alléchantes. Même si elles sont vraies – on peut aisément développer des applications parfaitement fonctionnelles avec Titanium – elles peuvent aussi conduire assez facilement à des désillusions plutôt cruelles – fuites de mémoire, plantages aléatoires, APIs javascript capricieuses, comportements incompréhensibles. Généralement à ce point, le développeur qui s’obstine sans chercher à comprendre ce qui ne va pas a des chances de parvenir en quelques semaines à un niveau d’énergie comparable à ça :

On trouve quelques témoignages de développeurs déçus par Titanium. Nous auditons régulièrement des applications existantes, et dans la très grande majorité des cas, les situations complexes ou aléatoirement instables sont associées à un manque de structuration de l’application, ou à des erreurs naïves (inclusion d’un très grand nombre de librairies au bootstrap de l’application, déclaration de variables globales, manque de compréhension du fonctionnement de CommonJS, etc.).

Ces réactions négatives sont à tempérer, mais pas à ignorer complètement : sans méthode et sans prendre le temps de prototyper, tester, re-factoriser et packager proprement les modules de son application, Titanium est un framework difficile à aborder.

Section intitulée etre-productif-avec-titaniumÊtre productif avec Titanium

Une fois les notions de base de la conception d’applications Titanium comprises et maîtrisées, développer des applications devient un vrai plaisir : vous pouvez profiter de (presque) tout l’écosystème logiciel de javascript : librairies de manipulation de chaînes, de dates, d’objets graphiques, ORMs, etc… Le champ d’action est réellement vaste : vous trouverez certainement votre bonheur du côté de npm ou microjs !

Nous avons déjà réalisé une vingtaine d’applications Titanium, certaines présentant une interactivité réellement bluffante. Un développeur productif sur Titanium pourra avancer très vite, à condition qu’il ne cherche pas à brûler les étapes, et qu’il reste très rigoureux sur la qualité du code qu’il produit. Développer avec Titanium, c’est un peu comme le Tetris : c’est simple et productif, mais si on n’aligne pas les blocs avec beaucoup d’attention, on fait vite un Game Over…

Un bon exemple d’application réalisée en deux jours est l’application « GouvCamp mobile », que nous avons développée et Open-Sourcée en mars 2012, en marge de notre engagement au sein de Démocratie Ouverte (dont on vous parlera prochainement sur ce blog). Deux jours, c’est même ce qu’il faut pour avoir le temps de peaufiner les détails, parce qu’en une journée le plus gros du travail était posé. Cette application fait appel à plusieurs Web Services, dispose d’un cache local sous la forme d’une base de données, et fonctionne parfaitement sous Android et iOS. Du point de vue de sa conception, l’approche utilise la stratégie « diviser pour régner » : en abusant de CommonJS, il est possible de créer des composants réutilisables, dont les contextes d’exécution sandboxés favorisent la stabilité. Cette application utilise également des librairies existantes, et adopte pour chaque fonctionnalité une logique vue-contrôleur ne laissant pas (trop) de place à l’improvisation.

Depuis Septembre, Appcelerator a publié alloy, un framework « RAD » qui s’appuie sur nodejs, Backbone.js et d’autres outils sympas du monde javascript. Nous avons déjà fait une présentation d’alloy à l’occasion de la 2e rencontre du groupe de Meetup Titanium Paris, et nous parlerons plus longuement de ce nouvel outil de productivité dans la troisième partie de cette série de billets !