Titanium API

Nous voici au troisième billet qui fera office de résumé des deux premières semaines (et de changement d’hébergement pour moi…). La plateforme de travail que je dois utilisée, Titanium, a été un peu plus prise en main et j’ai mieux compris à quoi elle servait.

Avec encore quelques difficultés à la cerner entièrement toutefois, j’arrive maintenant un peu mieux à comprendre son utilité et son fonctionnement, ainsi que celui de sa documentation (les premières approches avec de véritables API ne sont jamais bien simples…).

Pour les intéressés, je ferais bientôt un article sur cette plateforme, mais plongeons-nous d’abord sur la surface et mon stage.

Je n’utilise pour le moment que la partie « moteur web » qui se base sur WebKit (moteur de Safari). On se retrouve donc avec les mêmes capacités qu’un navigateur web du genre de Safari, c’est à dire : le (x)HTML et CSS pour la mise en forme, ce qui simplifie grandement la tâche de ce côté là. Bien évidemment, nous avons également l’accès à toutes les librairies JavaScript (pour ma part, ce sera MooTools qui semble rester une des plus rapides) et surtout l’accès hyper simple à une base SQLite, qui permet de stocker ses données en local autrement que dans un fichier texte… On peut ainsi voir immédiatement la portée de l’application RIA qui a pour but de fonctionner en ligne mais aussi hors-ligne si jamais la connexion est perdue.

On possède, en plus de ce moteur web, le moteur de Titanium lui même qui permet, pour sa part, d’intervenir avec le système sur lequel il est installé : création de nouvelles fenêtres indépendantes, récupération d’informations, prise de screenshot, création de notifications, la possibilité d’exécuter du code Ruby et Python ( :D ) et enfin une possibilité d’intéragir avec une base de données (disponible seulement dans la prochaine version, la 0.4).

En gros, nous avons la possibilité d’intéragir avec la machine en locale et d’exporter tout ça sur un beau gros serveur sur le Net. On peut travailler sur le net avec les capacités d’une machine locale. Vous me direz que l’on peut faire tout ça avec une application cliente classique (un peu comme EBP Comptabilité, ou autres). Oui, mais alors comment se passe la mise à jour d’un parc ? Un par un ? Un système lourd à la Microsoft Updates ? Il serait plus intéressant d’être capable de mettre à jour directement les fichiers sur le serveur pour l’application cliente (Titanium app) suivent cette mise à jour, non ?

Nous voici donc avec des applications légères, faciles à déployer, low-cost… et qui semblent répondre à la nouvelle « mode » sur le marché. Preuve en est avec Adobe AIR.

Revenons en à mon projet donc, qui lui est simpliste en fait puisque je n’ai que 6 semaines (malheureusement) pour le réaliser : une application gérant des contrats avec des adhérents, le tout sur une base SQLite. J’en suis là pour le moment. Bien évidemment, ce n’est pas aussi simple, puisque l’on m’impose des listes déroulantes multiples, une modification « à la volée » (on ne recharge pas entièrement l’interface), etc… Et puis je ne maniais pas très bien le JavaScript avant… j’ai donc dû apprendre sur le tas le fonctionnement de Titanium et ses limites, MooTools et réviser mon JavaScript.

Je pense, si je trouve le temps, refaire tout ça en Orienté Objet, mais ce ne sera pas simple puisque je n’ai simplement jamais encore vu ça : expérience à tenter ? :D

Pensez-vous que les applications RIA (à base de AIR ou Titanium) s’inscrivent dans la demande des clients actuelle ? Y a-t-il un moyen de créer cette demande ?