Alors que les applications mobiles sont devenues incontournables d’un point de vue marketing pour nos clients, elles sont aussi de plus en plus complexes.

Au temps passé à développer une application riche, il faut dorénavant ajouter le temps à la porter sur différents systèmes d’exploitation. En effet, si la plupart des applications concernaient les plateformes IOS, il y a aujourd’hui une forte demande pour des applications android; ce qui est cohérent avec la courte avance qu’a pris android sur IOS récemment.

C’est dans ce contexte que plusieurs solutions de développement multiplateforme ont émergé. Titanium est l’une d’elles et propose donc de développer dans le même langage (javascript) une application pour IOS, Android et Blackberry (béta).

L’installation

L’outil est gratuit avec un support payant. L’enregistrement ne prend que quelques minutes et l’IDE s’installe sans rien faire de particulier sur mac ou PC. Afin de tester l’application sur le simulateur IOS ou pour la lancer sur un iphone, il faudra disposer d’un mac comme plateforme de développement. Toujours pour IOS, il faudra un compte développeur si l’on veut déployer sur iPhone ou iPad.

Une documentation de base (vidéos, exemples d’applications) est disponible mais rapidement c’est dans le forum de l’éditeur que l’on trouvera les réponses à ses questions ou des exemples de code. Le forum est assez vivant et la plupart des problèmes y sont déjà adressés.

L’IDE

La prise en main de l’outil est immédiate lorsque l’on connaît eclipse; on retrouve les fonctionnalités les plus couramment utilisées comme la détection des erreurs de syntaxe, la complétion automatique, le lancement des applications ou encore le debugging.

Depuis l’IDE on peut donc lancer les émulateurs ou bien directement le code sur les appareils. Il subsiste quelques différences entre les deux mais c’est globalement très satisfaisant pour tester sereinement.

Les concepts de développement

L’outil ne propose pas de WYSIWYG pour faire ses interfaces graphiques. Il faut donc créer programatiquement tous les écrans en donnant les paramètres de chaque composant visuel. Les différents composants “s’emboîtent” les uns dans les autres afin de créer le rendu final.

Il n’existe que 2 layouts différents: vertical et horizontal. C’est un peu juste pour décrire tous les types d’écran. C’est bien sûr suffisant mais parfois cela rajoute de la complexité et du code pas très intéressant à écrire.

Le langage

Entre Objective C et Java il y a un pas que beaucoup de développeurs n’ont pas franchi. En revanche, pour un développeur java il est courant d’avoir déjà manipulé du javascript ou de se faire rapidement aux concepts de base.

Ainsi, il est tout à fait possible et même recommandé de reconstruire son modèle objet, tant pour les objets métiers que pour les composants graphiques customisés.
Le gros bémol est qu’il n’est pas possible d’hériter directement des composants natifs fournis par Titanium. Il faut donc passer par un mécanisme d’encapsulation.

En revanche c’est un véritable plaisir de pouvoir passer des fonctions en paramètre d’autres fonctions, ce qui rend beaucoup plus aisé l’écriture de code ‘technique’ générique.

L’API et les librairies tierces

L’API proposée est très riche. D’un point de vue IHM, pour répondre aux besoins exprimés par les designers, nous avons pour le moment trouvé tous les composants graphiques nécessaires ou au moins les briques élémentaires qui nous ont permis de créer ce qui n’existait pas.

Techniquement, rien à redire non plus. Des appels HTTP pour faire du REST à la lecture de médias (vidéos) en passant par la localisation sur une carte ou la persistance des données dans une base SQLite beaucoup de choses sont proposées. L’éditeur vend également des composants supplémentaires (paypal, QR codes, facebook, …).

Tout ou presque. Presque parceque cet algorithme de cryptage que vous venez de créer il n’est pas dans l’API Titanium. Vous vous en servez déjà sur votre serveur node.js ? Il suffira de l’intégrer aux sources de votre application mobile! C’est donc toutes les librairies javascript que vous pouvez intégrer !

Depuis les dernières versions du SDK, titanium supporte la norme commonJS ce qui permet encore une plus grande réutilisabilité du code.

A savoir (bonnes pratiques,  recommandations, …)

Malheureusement, parfois l’API ne fonctionne pas comme cela devrait, du moins sur une des plateformes cibles (il est rare qu’une fonctionnalité ne passe ni sur android ni sur iphone). Il faut donc utiliser des solutions de contournement des problèmes et surtout être un peu inventif ! Pour contourner les problèmes, nous avons préféré faire des workarounds qui fonctionnent sur les 2 OS cibles plutôt que de faire du code spécifique pour chacune des 2 plateformes avec dans un cas le code ‘classique’ et dans l’autre le contournement. Les commentaires dans le code sont alors de rigueur pour expliquer pourquoi l’API n’a pas été utilisée comme attendue.

Par exemple le composant de barre de navigation pour l’iphone n’apparaît pas correctement lorsque l’on souhaite mettre une image en arrière plan (corrigé dans le sdk 1.7.3!) Ce composant étant en plus spécifique iPhone, nous avons choisi de le redévelopper.
C’était assez simple car ce n’est qu’une vue que l’on place en haut de l’écran, toujours de la même taille, sur laquelle on peut ajouter des boutons, des libellés et évidement une image de fond. Et nous voilà avec notre barre de navigation maison, dont on pourra en plus se servir pour notre version android.

Si l’on a choisi Titanium pour son aspect multiplateforme, il est primordial de développer et de tester en même temps sur les différents OS. En effet, avec les adaptations dues aux contraintes techniques (bugs), il y a sans cesse des allers-retours pour valider que la solution mise en place est bien fonctionnelle sur tous les environnements.

Si on s’attaque par exemple à la réalisation de la version Android après avoir fini l’application sous IOS (ou réciproquement), à moins d’avoir une très bonne expérience sur Titanium, c’est sans exagérer l’assurance de passer autant de temps à développer sur chacune des plateformes et parfois même encore plus de code spécifique pour chacun des OS. Le gain (en temps) par rapport à un développement avec les langages natifs serait donc nul.

Une question importante à se poser est la gestion de l’affichage sur les différents appareils android. Nous avons fait le choix de traiter les 2 résolutions les plus courament utilisées en laissant de coté les plus petits écrans (sur lesquels l’expérience utilisateur ne serait de toute façon pas satisfaisante) et les tablettes (pas la cible d’utilisateurs).
Chaque résolution à gérer signifie un jeu d’image en plus à adapter.

La gestion de la mémoire

Lorsque l’on parcourt les documents sur la gestion de la mémoire, on trouve rapidement 2 méthodes pour implémenter son application tout en s’assurant que les besoins de mémoire n’explosent pas et forcent la fermeture de l’application.

La gestion la plus simple et visiblement celle qui avait été pensée au départ est très bien démontrée dans l’application KitchenSink (l’application de démo).
Le concept de base est que chaque écran existe dans un contexte différent et que ce contexte est détruit lorsque l’on ferme son écran. Des mécanismes très simples aident à ouvrir et fermer les écrans et donc à bien gérer sa mémoire disponible.
On aboutit donc à une hiérarchisation d’écrans que l’on pourrait représenter avec un arbre.
Un écran est maintenu en mémoire tant qu’il est affiché ou qu’un de ses sous-écrans est lui-même actif. Le point d’entrée de l’application (racine) connaît ses écrans et c’est à elle que l’on donne l’ordre d’en ouvrir un ou d’en fermer.

C’est ce choix que nous avons retenu pour notre application et cela fonctionne pour le moment avec la vingtaine d’écrans que nous avons.

Une gestion plus complexe est souvent expliquée à l’aide de l’application tweetanium. L’idée est de se passer du mécanisme offert par l’API et de tout charger dans un seul et même contexte. Il faut donc écrire à la main le code qui permet d’instancier en mémoire ou bien de libérer les écrans chaque fois que l’on en a besoin.
Ce mécanisme sans doute plus fin car complètement géré par le développeur est sans doute meilleur mais nécessité un coût de mise en oeuvre non négligeable,  surtout quand on est pas habitué au développement avec Titanium.

Les développements spécifiques

Ce serait mentir que de dire que les applications développées avec titanium ne contiennent pas de code spécifique. D’ailleurs, ce n’est pas du tout ce que vend l’éditeur.

Dans certaines partie du code technique (non UI), il faut gérer différemment les OS. Par exemple pour gérer les droits d’accès à la géolocalisation du téléphone, l’enregistrement pour les messages Push (notifications), la navigation d’une page à l’autre, …

Au banc d’essai

La première question à se poser, mais indépendante de titanium est de savoir si on a envie de développer la même application pour android et ios. En effet, les utilisateurs android ont ils envie de retrouver une barre de navigation propre à l’iphone ? Titanium permet de lever certains points en faisant par exemple un type de rendu différent pour le gestionnaire d’onglet android et IOS.

Pour aider à répondre à cette question, l’équipe de titanium propose de faire le choix entre une application que les utilisateurs sauront immédiatement prendre en main (car s’inscrivant complètement dans les codes de développement de chaque OS) et une application avec une identité visuelle et ergonomique forte mais communes aux différents appareils mobiles.

Pour des raisons de délais (et donc de coûts) , nous avons plutôt misé sur une identité typique à l’iphone et (très) légèrement déclinée pour android. Ceci dans le but de mutualiser le plus de code possible.

Si il reste un nombre non négligeable de bugs, on parvient dans la plupart des cas à trouver des contournements pour arriver à ses fins. C’est bien sur plus coûteux en temps, notamment quand une fonctionnalité est correctement implémentée sur un système mais qu’elle comporte des dysfonctionnements sur l’autre. C’est là que l’expérience des développeurs sur la façon de traiter telle ou telle problématique permet de gagner énormément de temps en étant efficace dès la première implémentation.

Utiliser Titanium pour créer par exemple une application uniquement pour iPhone alors qu’on ne connaît pas Objective C est aussi une utilisation possible, surtout pour une application simple.
La première semaine de développement laisse une impression incroyable de simplicité et de productivité. Les “ennuis” ne commencent réellement que lorsque l’on souhaite peaufiner son interface utilisateur.

Pour une application avec énormément d’écrans, de données manipulées et stockées, il sera plus judicieux de développer en natif sous peine de se confronter à des problèmes supplémentaires (gestion plus difficile de la mémoire, des bugs sur certains composants, les tests unitaires sur des calculs en local, … ).

Le point le plus décevant restera tout de même l’abscence d’un framework de tests (unitaires et intégration). Si la tache est théoriquement faisable, la complexité de mise en place est rédibitoire.
Ainsi titanium propose pour le moment de s’appuyer sur des frameworks comme QUnit en attendant que l’éditeur ne sorte l’outillage adéquat. Mais si le test du code javascript reste accessible, c’est le rendu visuel et la navigation qui couteront le plus cher à mettre en place dans une usine logicielle.

Nous avons constaté que l’exécution est parfois moins fluide sous Android. L’éditeur promet de régler ce problème en utilisant V8 plutôt que Rhino. Les performances seraient au minimum 2x meilleures avec dans la plupart des cas une amélioration de 10x à 15x. Ceci sera disponible “dans le SDK 1.8, avant la fin de l’année”…

Valtech a choisi Titanium pour développer la 2ème version d’une application iphone qui a été téléchargée plus de 120 000 fois et pour lancer en même temps la version android qui n’existait pas jusqu’alors.

La deuxième journée commença avec la présentation de Thomas Janzcuk intitulé : “High density server side JavaScript“.
Thomas travaille chez Microsoft, notamment sur le portage de node.js sous Windows.
Il y adressa la question de l’hébergement d’applications “légères”, dans le sens applications non professionnelles et n’étant pas extrêmement sollicités.
Depuis quelques années, la réduction des coûts d’hébergements est passée par les machines virtuelles, permettant de mutualiser le matériel.
Pour baisser encore les coûts, Thomas propose de descendre encore plus bas, en isolant par processus.
(more…)

Ce week-end a eu lieu à Berlin la 3ème édition de ls JsConf.
Y ayant passé un très bon moment l’année dernière (confère mon compte-rendu), j’ai réitiré l’expérience cette année.

(more…)

Vous ne le savez peut-être pas mais, depuis octobre 2010, un Groupe d’Utilisateurs du langage JavaScript se réunit à Paris tous les derniers mercredi du mois.

Ce groupe très dynamique s’intitule ParisJS et rejoint les groupes d’utilisateurs existants, qu’il soit Européens (Berlin, London, Vienne, Cologne, Amsterdam), Canadiens (Montréal, Toronto, Vancouver), Australiens (Sydney, Brisbane) ou, bien sûr, Américains (Boston, Baltimore, Colombus, Portland, Atlanta, Los Angeles, New York, Brooklyn, Austin, Dallas, Las Vegas).

On présente au ParisJS généralement 4 ou 5 sujets de 15 à 30 minutes par soirée, comme par exemple des frameworks et librairies (node.js, backbone, Raphael), des frameworks de tests (QUnit), des bases NoSQL (CouchDB), on traite de l’amélioration des performances (chargement asynchrone, how to be faster than JQuery) et on présente des démos technologiques (Kinect dans le browser, Inside Globe Tweeter, Pacmaze : un Pacman en WebGL).

Cette liste n’est pas exhaustive, vous la trouverez plus complète sur le site officiel du ParisJS.

Ce mois-ci, Valtech offre son auditorium pour la session du mercredi 29 juin. Nous vous y attendrons à partir de 19h30 à l’adresse suivante : 103 rue de Grenelle 75007 Paris.

Seule formalité pour participer, s’inscrire sur eventbrite.

Ryan Dahl, le créateur de nodejs, sera présent le mercredi 8 juin à une soirée organisé par JoliCloud sur ce thème.

nodejs est un framework / serveur JavaScript permettant d’écrire des applications offrant d’autres paradigmes que ceux habituellement utilisés dans nos applications Java ou .Net : programmation fonctionnelle, I/O asynchrones, boucle d’événements.

L’approche est intéressante, aussi, je vous invite à vous inscrire à cette soirée si le sujet vous intéresse.

Avec la croissance fulgurante ( à 3 chiffres annuel ) des ventes aussi bien sur iPhone que sur Android, les demandes en application mobile natives sont fortes.

Le développement natif a l’avantage d’ une interface utilisateur fluide. Néanmoins la montée en compétence exige au moins quelques mois d’expérience pour des projets relativement courts (en semaines ). Chaque plateforme est spécifique, une expérience sur iPhone n’est pas forcément transférable sur Android et vice versa.

L’ idéal pour le développement multi-plateforme reste l’HTML5 rendu sur le navigateur de l’OS : webkit pour iOS et Android, Firefox pour Meego, Internet Explorer Mobile pour Windows Phone 7. HTML5 reste une solution universelle pour le front-end . Les coûts sont factorisés par le nombre d’OS ciblé.

Il existe des solutions multi plateforme tel que PhoneGap, App Titanium qui mimiquent l’interface utilisateur natif . A la différence de ces outils ,  ce tutorial vous laisse libre sur le choix de votre librairie JavaScript. Les librairies utilisées sont  iUI Project de Joe Hewitt , iWebKit de Jonathan Stark , JQTouch de David Kaneda .

Tutorial

Ce tutorial expose comment utiliser un “wrapper” de l’HTML5 sur Android. En d’autres termes , ce projet embarque de l’ HTML5  dans une application Android .

Commencez un nouveau projet Android sous Eclipse à partir d’android 2.0 ( SDK API >=5 ). Vous disposez déjà d’une application web qui tourne sans serveur. Déposez le dans le répertoire “assets” , c’est ici où tout le site web se trouve avec ses références JavaScript, CSS …

Créez un  nouveau layout “main” où on va introduire une webview . Le layout réprésente la view dans le modèle MVC . Cette webview sera la fenêtre d’entrée pour notre application HTML5 .

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
 
<WebView    android:id="@+id/webview"
android:layout_width="fill_parent"
android:layout_height="fill_parent"    />
 
</LinearLayout>

Dans le code source , créez une classe NaviRay qui hérite d’ Activity . Si vous n’êtes pas familier avec la notion d’activity,  je vous recommande de comprendre son cycle de vie .
La méthode  onCreate initialise le layout “main”  . La  webview pointe dans le dossier assets vers la page index.html

public class NaviRay extends Activity{
 
	private WebView browser;
 
	/** Called when the activity is first created. */
 
	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.main);
		browser  = (WebView) findViewById(R.id.webview);
		browser.getSettings().setJavaScriptEnabled(true);	
		browser.loadUrl("file:///android_asset/index.html");
	}
}

Dans le manifest , rajoutez la permission android.permission.INTERNET

Ca y est, on peut maintenant accéder à notre site web en local.

Options

Cette application ne comporte qu’une seule Activity . Dans le code source ,  la gestion de l’historique du bouton “back” et le menu sont inclus .

Appels natifs

L’une des restrictions de l’HTML est sans aucun doute l ‘ impossibilité d’utiliser des fonctions natives (GPS , accélèromètre , contacts … ) . Quoi que on peut toujours appeler.
Sans utiliser d’intent , il est possible de passer un appel téléphonique ou d’envoyer des SMS juste avec de l’HTML ( testé sous iPhone et Android )

Pour téléphoner vers

<a href="tel:33-123-456-7891">

Pour envoyer un SMS

<a href="sms:12345678">

Pour envoyer un email

<a href="mailto:ray@ray.com?cc=ex@x.com,lisa@x.com&amp;subject=Sujet HTML5 sur Android!&ampbody=Je viens de tester!">

Code source

Le code source de l’application est disponible à cette url http://code.google.com/p/navray/source
Note : le source est géré sous Mercurial Hg . Pour ceux qui ne l’utilisent pas , le source peut être téléchargé à partir de navray_src_01.zip http://code.google.com/p/navray/downloads/list

Vous pouvez utiliser à différentes expérimentations, il ne reste plus qu’à modifier le contenu du dossier “assets”.

Si vous publiez une application à partir de ce source,  merci de modifier le nom de package Java. En effet le package sert d’identifiant pour une application publiée sur l’Android market.

Il est aujourd’hui inconcevable de ne pas utiliser Ajax et autres comportements dynamiques à base de JavaScript dans vos applications.
Cependant, souvent, cela se fait au détriment de la gestion du bouton précédent / suivant, et plus globalement de l’historique du navigateur.
Par ailleurs, cela pose également problème si l’utilisateur clique sur un lien JavaScript via l’action “ouvrir dans un nouvel onglet” ou “ouvrir dans une nouvelle fenêtre”.

J’ai voulu adresser ce problème dans un projet personnel de type carnet d’adresse et je vous propose une solution dans la suite de cet article.
(more…)

Ce billet est la 2ème partie du compte-rendu de la JsConf 2010.

J’y aborde PhoneGap, un tour d’horizon de HTML5 par Google, l’importance des standards du web et de l’accessibilité, les secrets derrière l’émulateur JSNES. Je parlerais également de JavaScript côté serveur utilisé par de larges boutiques en ligne, de Nodejs, CouchDB et de SocketIO pour ensuite conclure cet événement.

(more…)

La JsConf 2010 a eu lieu le week-end dernier, samedi 24 et dimanche 25 septembre à Berlin.

C’est un excellent événement, à ne pas rater si vous portez de l’intérêt à JavaScript.

Bien qu’étant une conférence assez jeune avec cette 2ème édition, j’ai été surpris par l’organisation sans faille, la qualité des interventions ainsi que l’originalité de la cuisine Berlinoise.

Ce fut également l’occasion de rencontrer les différents acteurs de la communauté JavaScript, ainsi que de voir se dégager les tendances actuelles que j’évoquerai en conclusion, dans le second article.

Dans la suite de cet article, vous trouverez la vision du web par les fondateurs d’Ajaxian, un tour d’horizon des API HTML5, un retour d’expérience sur la manipulation graphique en JavaScript, Cloud9IDE, la présence de Microsoft, l’introduction des proxys et le résultats du concours JS1K…

(more…)

J’ai eu mercredi dernier l’occasion d’animer un cours du soir sur Apache CouchDB.
CouchDB est une base de donnée “NoSQL“, orientée document et dont la particularité est d’être très orienté vers le web (données au format JSON, accès REST donc via HTTP, écriture des vues en JavaScript). Ces différents points ont été abordés lors de cette soirée.

Si ce sujet vous intéresse, je vous invite à parcourir la présentation en ligne.
Utilisez les flèches de votre clavier pour naviguer dans cette présentation HTML (construite sous S5 d’Eric Meyer).