Une semaine avec Titanium, framework Hybride

[chapeau]Parmi nos clients qui cherchent à construire leur stratégie mobile avec une application, beaucoup souhaitent une version iOS et une version Android, étant donné la domination écrasante d’Android sur les chiffres de ventes de smartphones en France ces dernières années.[/chapeau]

Ce sont alors 2 équipes se mettent au travail. Elles réalisent deux applications, pourtant similaires en terme de fonctionnalités, mais sur des plateformes différentes, car les languages de développement sont totalement différent (Objective C pour iOS, Java pour Android). De nombreuses fois, nous nous sommes dit au sein de l’équipe développeur : « C’est dommage de devoir refaire ce module alors que l’équipe iOS l’a déjà fait. » Souvent, seul l’interface diffère légèrement.

C’est là qu’entrent en jeu les outils cross-plateformes, tels Phonegap ou Titanium.

Titanium, un Framework cross-platform conçu par Appcelerator, permet de construire une application Android et iOS en 1 seul projet. Sur le papier, tout est pris en charge : l’interface, les appels réseaux, ou la gestion des ressources quel que soit l’OS. Voyons ce que cela donne en réalité.

Brève introduction à Titanium

Le langage principal du SDK Titanium est le Javascript auquel Appcelerator a ajouté un gros SDK qui permet à ce langage de communiquer avec l’OS sur lequel l’application est exécutée. Par exemple, pour ouvrir un UIViewController d’iOS ou une Activity d’Android il faut créer une Window et faire appel à la méthode open() de Titanium pour l’afficher. De cette manière, on peut s’abstraire de l’OS actuellement en train de faire tourner l’application.

La première différence entre Titanium et d’autres SDK est l’utilisation du Javacript. En effet, que ce soit en Java ou Objective-C, le développeur est habitué à travailler avec un langage orienté Objet ce que le Javascript n’est pas vraiment. De ce fait, la structuration du code change beaucoup ce qui est particulièrement déroutant au début : des choses pourtant simples dans d’autres langages deviennent soudainement complexes.

Évidement, un développeur ayant déjà eu une expérience web devrait retrouver ses marques, mais les autres vont devoir changer leurs habitudes. L’interface de développement (IDE) fournie avec le SDK n’est rien d’autre qu’Eclipse : si le développeur vient de l’univers Android, il devrait pouvoir s’en sortir, mais celui venant de l’univers iOS va être dépaysé !

L’une des forces de Titanium est de proposer un store complet permettant d’ajouter à son application des modules très facilement. On peut en quelques clics ajouter une couche de gestion des beacons, NoSQL ou un lecteur QR Codes. Certains modules sont payants, d’autres gratuits.

Conscient que le Javascript ne pousse pas nécessairement à une organisation claire du code d’interface, Appcelerator a sorti en 2013 une couche supplémentaire pour gérer l’interface nommé « Alloy ». Pour ce faire, on utilise une approche similaire aux technologies web, avec un fichier XML qui représente la structure de la vue, un fichier CSS pour styliser la vue, et un fichier Javascript pour interagir avec la vue. Cette approche permet d’éviter des fichiers Javascript trop longs dans lesquels on instancie et gère tout les éléments qui doivent être affichés à l’écran.

Quelques fonctions du SDK

Du fait que le SDK soit cross-platform, cela implique forcement l’utilisation d’une couche d’abstraction supplémentaire pour accéder à la plupart des fonctionnalités système comme la géolocalisation, les appels réseaux, l’accès aux contacts, le calendrier, etc.

Appel réseau

Du coup, certaines fonctionnalités compliquées peuvent devenir relativement simples avec Titanium. Prenons l’exemple d’un appel réseau sous Titanium :

[javascript]
var client = Ti.Network.createHTTPClient({
      onload : function(e) {
            newsDAOCallback.onSuccess(JSON.parse(this.responseText));
      },
      onerror : function(e) {
            newsDAOCallback.onError(e.error);
      },
      timeout : 15000 // in milliseconds
});
client.open(« GET », « http://date.jsontest.com »);
[/javascript]

En quelques lignes de code, je créé un client, définie les callbacks d’erreur et de réussite, ouvre avec la méthode GET l’URL http://date.jsontest.com. Je lance l’appel, et parse le résultat JSON, tout ceci en seulement 10 lignes de code. Ajouter des paramètres POST se fait aussi simplement, en une seule ligne.

 Géolocalisation

Après un exemple d’appel réseau, tentons désormais de récupérer la localisation de l’utilisateur. Ici nous ne chercherons pas à obtenir la position de l’utilisateur en permanence mais juste faire un simple appel à un moment donné :

[javascript]
Ti.Geolocation.getCurrentPosition(function(locationResult) {
            //Pour avoir les coordonnées : locationResult.coords.latitude
// et locationResult.coords.longitude
});
[/javascript]

Encore une fois, Titanium SDK réussi à se montrer bluffant grâce au niveau d’abstraction qu’il propose. 2 lignes suffisent pour obtenir le résultat.

Mais (il y a un « mais »)

Durant cette semaine avec Titanium, j’ai également eu l’occasion  de mettre en place un menu latéral coulissant (navigation off-canvas). Je ne vais pas détailler le travail que j’ai réalisé sur cette partie mais la gestion des gestes et des animations mettent en évidence la différence fondamentale de gestion des interfaces entre Android et iOS. L’exemple le plus flagrant, sur ce menu, c’est la nécessitée de devoir « lisser » le geste d’ouverture du menu sur iOS.

En effet, pour avoir un résultat satisfaisant sur iOS, il est nécessaire de faire appel à la méthode animate() sur le menu afin qu’il ne s’ouvre pas en « saccadé » au swipe sur l’écran. Par contre, si on laisse l’appel à animate() de cette méthode sur Android, on se retrouve avec un menu « en retard » par rapport au geste de l’utilisateur, qui donne un sentiment de lenteur de l’application. De ce fait, s’il s’agit d’un iDevice, je fais appel à animate(), alors que je ne dois pas y faire appel sur Android.

Avoir recourt à ce genre de technique n’est pas ce qu’il y a de plus naturel pour un SDK cross-platform.

Pour terminer, bien que le menu soit fonctionnel avec du code utilisant l’API Titanium, il s’est avéré que, malgré tout, les performances étaient particulièrement médiocres sur des appareils entrée de gamme ou anciens, comme un Wiko ou un iPhone 4. De ce fait, nous avons eu recourt à une librairie externe qui gère le menu à notre place et qui est codée dans la langage natif afin d’augmenter considérablement les performances. (voir ici). Cet aspect met en valeur l’un des limites du langage Javascript : Ces performances plus faibles que le natif.

Conclusion

Nous voilà déjà en fin de notre première semaine avec Titanium, que pouvons nous conclure ?

Pour commencer, Titanium est un véritable SDK cross-platform, ce qui signifie que l’on peut théoriquement coder sur deux OS, simultanément avec le même code source. Mais notre test souligne cependant les limites de Titanium sur la gestion l’interface utilisateur par 2 OS différents. Comme nous en avons l’habitude avec nos applications natives, il est capital de toujours tester sur les 2 plateformes que tel ou tel ajout fonctionne correctement et qu’aucun effet indésirable ne soit apparu.

Cependant, en dehors de l’interface utilisateur, pouvoir mutualiser la logique métier permet de gagner en productivité et la couche d’abstraction supplémentaire ajoutée par Titanium sur les API systèmes permet de gagner en simplicité et lisibilité.