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

Titanium Mobile est un framework de développement mobile cross-platform que nous utilisons très fréquemment, mais qui suscite régulièrement des critiques assez acerbes de la part de certains développeurs. Certains lui reprochent la qualité de la documentation, d’autres la stabilité du produit, tandis que les derniers dénoncent la promesse non tenue du “cross-platform”. Évidemment, les nombreux articles qui exposent ces problèmes sont écrits à l’encre de la déception, les espoirs initiaux étant balayés par les difficultés rencontrées par des développeurs qui pensaient que leur projet se serait passé plus simplement.

Il nous semble nécessaire de rendre justice au framework, aussi avons nous décidé d’écrire ce billet, première partie d’une série de trois articles qui résument la situation actuelle du framework. Nous présenterons dans cette série les concepts de Titanium, ses possibilités et limites actuelles, et nous terminerons par une analyse du futur annoncé de cette (belle) plateforme.

Section intitulée partie-1-la-genese-et-les-concepts-du-frameworkPartie 1 – la genèse et les concepts du framework

Revenons au début. De quoi parlons nous ? Appcelerator Titanium Mobile, un framework de développement d’applications mobiles natives, cross-platform, et qui s’appuie sur des langages ouverts et très répandus. Tous les termes ont leur importance dans cette définition :

• Les application développées avec Titanium Mobile sont bien des applications natives. Outre le fait qu’elles peuvent donc être proposées sur l’Apple Store ou le Play Store, elles proposent un niveau de rendu et de qualité en tout point similaire aux applications “standard”, développées uniquement avec les SDK d’iOS ou d’Android. Elles sont aussi rapides, proposent des widgets réellement natifs (et pas des “imitations” stylées avec des feuilles de styles CSS) et permettent d’accéder à l’ensemble des APIs matérielles des téléphones et tablettes.
• Un framework “cross-platform” : l’idée est qu’une même base de code puisse permettre de proposer une application indifféremment sur plusieurs plateformes, et ainsi éviter de devoir développer la même application en plusieurs exemplaires, à chaque fois dans des langages différents. Plus précisément, Appcelerator présente cet aspect cross-platform non pas comme “nous voulons supporter toutes les plateformes”, mais plutôt comme “nous voulons proposer le maximum de réutilisabilité du code entre plateformes sur lesquelles il est possible de créer de la valeur ajoutée”. Ainsi, seuls Android (téléphones et tablettes) ou iOS (Iphone, Ipad) sont supportés actuellement de manière correcte, tandis que BlackBerry, partiellement supporté, reste une plateforme en fin de vie, sur laquelle les développeurs mobiles ne souhaitent plus investir (voir par exemple le rapport de la dernière enquête menée auprès des utilisateurs du framework). Windows 8, de son côté, propose déjà une solution de développement d’applications natives à base de HTML et d’APIs javascript¹. L’intérêt d’utiliser Titanium dans ce cas serait assez faible, et la dernière communication faite par Appcelerator à ce sujet indique que la plateforme est à l’étude, mais qu’aucune décision n’a été prise pour le moment

    “Appcelerator aims to support all mobile platforms on which developers have an opportunity to create compelling mobile apps. We are currently evaluating Windows native support and will let our community know as our plans develop.”

    C’est pourtant clairement un sujet à suivre, pas mal d’utilisateurs réclamant le support de Windows Phone 8…

• Des langages ouverts : c’est là le charme de la plateforme : Titanium permet de développer ces applications natives cross-platform en utilisant un langage très répandu dans le milieu des développeurs Web : Javascript.

Section intitulée mais-comment-ca-marche-ce-machinMais comment ça marche, ce machin ?

Une solution de développement mobile natif, cross-platform et en javascript attise forcément la curiosité, sinon la méfiance. Le fonctionnement interne du framework est très souvent méconnu, mal appréhendé, et est une vraie source de confusion pour les novices.

Dissipons tout de suite quelques doutes : le code javascript n’est pas transformé en Objectif-C ou en Java pour être ensuite compilé. Au lieu de ça, il est transformé en bytecode au moment de la compilation, et interprété par le moteur d’exécution js embarqué dans l’application – il en résulte donc, habituellement, des applications qui font un minimum de 2 à 3 Mo². Le code javascript écrit par le développeur est donc bien interprété sur le téléphone, mais la réalisation des opérations natives, elle, est déléguée aux parties compilées du framework.

C’est cette astuce qui permet à Titanium de proposer des performances incomparables dans le domaine des frameworks de développement cross-platform, tout en conservant la souplesse de Javascript. En revanche, cet avantage majeur a ses mauvais côtés : le framework doit maintenir une correspondance entre objets du monde javascript et objets natifs. De mauvaises pratiques dans la gestion des objets peuvent donc avoir des conséquences graves sur la stabilité de votre application – damn yeah, on développe pour un média mobile ayant une mémoire et des performances limitées, pas pour une instance Quadruple Extra Large d’Amazon EC2…

Section intitulée genese-d-une-plateforme-pleine-de-promessesGenèse d’une plateforme pleine de promesses

À la base, Titanium est une plateforme pleine de promesses alléchantes pour le développeur Web qui ne connaît ni Objective-C, ni Java : sans apprendre de langage supplémentaire, il est possible, avec quelques connaissances de javascript, de créer des applications dynamiques, natives et ayant accès à toutes les capacités du téléphone. Cela comprend évidemment tous les éléments d’UI, mais aussi l’accès aux fonctionnalités natives, qu’une WebApp ne pourra pas mettre en oeuvre : base de données locale, prise de photos ou vidéos, lecture de médias issus de la librairie de médias, etc.

Le tutoriel de création d’un “Hello World”, ou même la lecture rapide du code de KitchenSink, l’application exemple fournie par Appcelerator, et qui recense (presque) toutes les possibilités de Titanium, peuvent laisser penser que le développement va être simple, rapide, efficace, et sans douleurs.

Une fois Titanium Studio³ téléchargé, il est en effet extrêmement simple d’utiliser les modèles de projet disponibles pour créer un HelloWorld basique, qui pose ainsi les bases de votre application. Plusieurs templates d’application sont disponibles : application à base de TabGroup, en fenêtre unique, à navigation latérale (TableView), etc.

Titanium Studio est apparu assez tard (seulement au bout d’un an et demi après la publication des premières versions de Titanium), mais offre des outils extrêmement pratiques pour le développeur : auto-complétion, documentation, outils de compilation et de simulation intégrés, et, surtout, un debugger javascript qui permet de placer des points d’arrêt ou de travailler en mode pas à pas sur le simulateur. Il est ainsi extrêment aisé de comprendre le comportement de son application, et même de procéder à l’évaluation “à la volée” des variables présentes dans le contexte d’exécution javascript de l’application, directement sur le téléphone. Un peu comme si on pouvait mettre une caméra à l’intérieur d’un moteur pour comprendre comment tournent les pistons…

Section intitulée la-suite-mais-quelle-est-la-suiteLa suite, mais quelle est la suite ?

Nous touchons à la fin de ce premier billet, qui a permis de bien planter le décor et d’éclaircir les idées sur le fonctionnement de Titanium et l’outillage disponible. Tous les profils trouvent un intérêt à Titanium. Le développeur aura compris que le concept du framework est très plaisant, car il rend accessibles un grand nombre de fonctionnalités au travers d’APIs javascript simples : sa productivité va donc s’améliorer sur les opérations de base, et il va pouvoir se concentrer sur les détails. Le chef de projet, lui, comprend que Titanium peut l’aider à atteindre plus aisément ses objectifs, dans la mesure où le langage (javascript) est bien plus répandu et mieux maîtrisé que Java ou Objective-C. Le client ou le product owner, enfin, y trouve lui aussi son compte, dans la mesure où la facture qu’on lui présente est largement allégée sans pour autant sacrifier le fonctionnel.

Dans le prochain billet, nous verrons de manière plus concrète comment se déroule un cycle de développement avec Titanium et, surtout, quelle est la source de désillusion pour la plupart des développeurs déçus par le framework. Stay tuned!

PS : En attendant le prochain billet, vous pouvez venir assister au prochain Meetup Titanium du groupe d’utilisateurs parisiens de Titanium. J’y ferai une présentation du framework Alloy.