Intéressé par le développement sur Palm/webOS, j’ai commencé par faire un petit POC sur la possibilité de développer un petit Solitaire en HTML 5 / JavaScript. Voici quelques remarques (générales) sur le développement de jeux CSS/Html5/JavaScript.

This or That ?

La principale difficultée réside dans la variable this, qui peut prendre n’importe quelle valeur en JavaScript. Dans tout autre language (Java, Cpp,…), this fera toujours référence à l’objet en cours. En JavaScript, ce n’est pas aussi simple: this dépend en fait du contexte d’appel de la méthode, ce contexte pouvant être modifié par l’utilisation de apply.

Comme je sens que vous commencez à tourner de l’oeil, prenons un exemple:

function monConstructeur()
  {
     this.monAttribut = 'yop !';
  }
 
  monConstructeur.prototype = {
     maMethode: function()
     {
        console.log(this.monAttribut);
     }
  }
  var monInstance = new monConstructeur();
 
  // 'yop !'
  monInstance.maMethode();
 
  // undefined
  setTimeout(monInstance.maMethode, 1000);

A 1ère vue, les deux appels devraient tous les deux afficher ‘Yop !’, et pourtant, le 2ème appel affichera undefined, parce que this, dans ce cas précis, fera référence à l’objet global (ie: window), et non pas à notre instance. Mais ?! Pourquoi ?!! La valeur de this dépend en fait de l’invocation.

Il existe en réalité 4 patterns d’invocation de méthode en JavaScript, et la valeur de this en dépend:

1. Le pattern d’invocation de méthode

Dans le cas d’invocation de méthode, this fait référence à l’objet contenant la méthode:

var monObjet = {
     monAttribut: 'yop !',
     maMethode: function() { return this.monAttribut; }
  }; 
 
 // 'yop !'  
 monObjet.maMethode();

2. Le pattern d’invocation de fonction

Dans le cas d’une invocation de fonction, this ne devrait pas être défini, et fait pourtant référence à l’objet global. C’est une erreur de conception du language qui se verra corrigée dans la prochaine version de ECMAscript.

var maFonction = function() { return this.location; }
  // Object
  maFonction();

3. Le pattern d’invocation de constructeur

function monConstructeur(){
  this.monAttribut = 0;
}
 
var monInstance = new monConstructeur();

Lors de l’appel d’une fonction construteur préfixé par new, un nouvel objet est créé, avec un lien masqué vers le prototype de la fonction, et this est automatiquement lié à ce nouvel objet.

4. Le pattern d’invocation avec apply

La valeur de this lors de l’appel d’une fonction étant quelque peu aléatoire, il est possible de forcer la valeur de this à l’aide de apply.

Function.apply(valeurThis, ArrayArguments);

Les frameworks JavaScript fournissent généralement une méthode permettant de facilement modifier la valeur de this pour l’appel d’une fonction. Il est donc facile de régler le problème précédent.

Par exemple, avec le framework Prototype (utilisé dans le framework MVC de Palm: Mojo), on pourrait utiliser bind:

setTimeout(monInstance.maMethode.bind(monInstance), 1000);

Ou, en utilisant jQuery (1.4+):

setTimeout(jQuery.proxy(monInstance.maMethode, monInstance), 1000);

Transitions CSS

Depuis la sortie de l’iPhone il y a 3 ans Apple a introduit et ne cesse de pousser les transitions CSS, beaucoup plus adaptées à la puissance limitée (tout est relatif ) des smartphones. Avant l’arrivée des transitions, pour animer des objets HTML, on utilisait les frameworks tels jQuery. Par exemple, pour déplacer un objet de 100px vers la droite, on peut faire avec jQuery:

$('#foo').animate({left: '100px'}, 1000);

Le problème, lorsque l’on se place dans le contexte des smartphones est que tout est effectué par le processeur. La puissance de ces machines étant relativement limitée, et la batterie de courte durée, cette méthode n’est pas utilisable. Les transitions CSS (disponibles sur tous les navigateurs modernes, ce n’est pas (plus) une exclusivité webKit: Firefox, Opera, webKit) permettent de définir des animations à l’aide des CSS. Quelle est la différence me direz-vous ? La principale différence est que les animations effectuées via des transitions CSS sont accélérées graphiquement et permettent donc de libérer le processeur et, théoriquement, d’utiliser moins de batterie.

Les transitions étant encore en plein développement, les spécifications ne sont pas finales et chaque navigateur les implémente donc à l’aide d’un préfixe: -o- pour Opera, -moz- pour Firefox et -webkit- pour les navigateurs utilisant webkit (Safari, Chrome, OWB,…). Plusieurs manières permettent d’animer un objet à l’aide des transitions.

1. Animation des propriétés
Pour un sélecteur (CSS) donné, il est possible de choisir quelle(s) propriété(s) sera/seront animée(s). Par exemple, pour animer notre bloc #foo, on utiliserait les CSS suivants:

#foo{
   -webkit-transition-property:left;
   -webkit-transition-duration:1000ms;
 
   -o-transition-property:left;
   -o-transition-duration:1000ms;
 
   -moz-transition-property:left;
   -moz-transition-duration:1000ms;
}

La modification de la propriété left de l’objet #foo sera alors automatiquement animée, et de durée 1000ms.

2. Animation
Il est aussi possible de créer des animations relativement complexes, à l’aide de keyframes, par exemple (ici pour webkit):

@-webkit-keyframes 'zoomIn' 
	{
		0%{
			opacity:0;
			-webkit-transform: scale(1.0);
		}
		25%{
			opacity:1;
		}
		100%{
			opacity:0;
			bottom:20px;
			-webkit-transform: scale(3.0);
		}
	}

Ici nous définissons une animation nommée « zoomIn », et 3 « étapes ». Le passage à ces 3 étapes sera automatiquement animé.

Pour utiliser cette animation, il suffit ensuite de faire:

#foo.animate{
   -webkit-animation: zoomIn .4s ease-in;
}

Lorsque l’objet #foo aura la classe ‘animate’, il jouera automatiquement l’animation zoomIn, pendant 0.4sec, en utilisant la fonction ease-in. Cette fonction définit la vitesse de l’animation au cours du temps: ease-in étant la valeur par défaut.

3. aller plus loin
Il est possible d’utiliser le JavaScript pour spécifier des fonctions callback à exécuter à la fin d’une transition. On peut ainsi définir des animations assez complexes, complexes dans tous les sens du terme: le code définir devient vraiment très complexe, et surtout on mélange maintenant simples propriétés d’affichage avec l’animation. Je conseille d’ailleurs, dès le début, de séparer les transitions CSS, des propriétés CSS classiques.

Et j’attends avec impatience le premier SDK permettant de développer ces animations CSS, parce que actuellement, ces transitions, aussi puissantes soient-elles sont très très difficilement accessibles, et totalement impossibles à débugger…

Alors: qui sera le 1er ? Adobe ? Apple ? Google ?

Un WebKit, des WebKit

WebKit, le moteur utilisé actuellement dans Safari (y-compris la version iPhone), Chrome, le navigateur d’Android, le futur navigateur de BlackBerry, etc… n’a pas (scoop ! ) été créé par Apple mais est basé sur le projet KHTML, du groupe KDE. Ce moteur très performant a été adapté sur de nombreuses plateformes et chaque plateforme apporte ses modifications et restrictions. Ainsi, WebKit utilisé dans Safari 5 supporte des fonctionnalités non présentes dans Chrome (exemple: -webkit-backface-visibility), le navigateur de Palm/webOS ne supporte pas les box-shadow ni les gradients, etc…

Contrairement à ce que l’on pourrait donc croire, l’utilisation de WebKit simplifie sans aucun doute le travail des développeurs des systèmes, mais en aucun cas celui des développeurs Web, puisque toutes ces différences doivent être prises en compte pour obtenir un site/une application multi-plateformes.

Attention donc: il existe des WebKit, pas un seul Même si la base est évidemment la même, le résultat final sera probablement différent selon les plateformes.

- Tester et télécharger WarpKlondike
- Télécharger la version webOS pour votre Palm Pré ou Pixi
- Plus d’informations sur les transitions: Apple Developer Site

Wax Tailor  [ Trip-Hop ]
Ambiance: Zen
Albums: The train, leave it, In the mood for life
A écouter: This Train