Armetiz

Adobe Player Flash 10 sort en version 10.1 beta. Il s’agit d’une version mineur. Sauf qu’ici le mineur implique de nouvelles fonctionnalités très intéressantes et attendues.

Au programme du player 10.1

• Gestion des erreurs centralisées. L’utilisation des journaux et des messages d’erreurs sera grandement simplifié !
• Utilisation de l’accélération graphique des GPU.
• Introduction à la mobilité avec la prise en charge des accéléromètres et du multi-touch

Pour Adobe AIR 2, tout avait déjà été annoncé.

• Ouverture d’application externe
• Gestion de la connexion de périphérique externe
• Gestion des processus natifs (miam ?)
• Support avancé de l’IPv6. Utilisation de l’application Adobe AIR 2 comme serveur de socket. Ça sent très bon pour les stations de diffusion vidéo

Pour plus de détail technique, je vous conseil de lire Code moi un mouton.

Suite au commentaire de webstorming sur l’article : Flash – Restreindre l’instanciation d’une classe par un seul objet.

Voici l’implémentation du pattern singleton en Flash.

public class PatternSingleton
{
	private static var _instance : Object;
 
	public function PatternSingleton () : void
	{
		if (_instance)
			throw new Error ("Pattern Singleton : only one instance is permit");
		_instance = this;
	}
 
	public function sayHello () : String
	{
		return "Hello World";
	}
 
	public static function get instance () : PatternSingleton
	{
		if (!_instance)
			new PatternSingleton ();
		return PatternSingleton (_instance);
	}
}

Nous avons donc une class ne pouvant être instanciée qu’une seule fois, et accessible de n’importe où au sein de notre application.

trace (PatternSingleton.instance.sayHello ());

Wikipédia

L’implémentation que l’on trouve sur Wikipédia est différente de celle ci-dessus.
En effet, elle utilise la définition d’une constante globale sans modification du constructeur.
Le problème induit, c’est que l’instanciation multiple n’est pas interdite au sein de l’application. Et la compréhension par un débutant est moins aisée.

public function fooLoop () : void
{
   //Pre traitement
   fooLoop ();
   //Post traitement
}

Voici le corps d’une fonction récursive.

Lorsque la pile est pleine, une jolie erreur du type StackOverFlowError est déclenchée.

Ce qui est intéressant de voir, c’est le comportement du Player et des navigateurs lorsque l’on traite cette erreur pour relancer la fonction récursive.

Voici le code utilisé :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
	layout="absolute">
	<mx:Script>
		<![CDATA[
			private function hack () : void
			{
				hack ();
			}
 
			private function click () : void
			{
				try
				{
					hack ();
				}
				catch (e: Error)
				{
					click();
				}
			}
		]]>
	</mx:Script>
	<mx:Button click="click ()" label="Nuked !" />
</mx:Application>

Avec Windows, en utilisant IE le navigateur monte en charge en utilisant la mémoire. Ce qui a pour conséquence logique de remplir le fichier d’échange. Une fois que la mémoire disponible est sèche, un mécanisme que je n’explique pas libère de la mémoire et le script continu son exécution.

Contrairement à Firefox qui après 400Mo d’utilisation mémoire, se positionne en « Ne réponds pas… » et se freeze de lui même.

Si vous voulez voir ce que cela donne, voici l’application.
Pensez à surveiller l’utilisation de votre mémoire

L’interet

Outre le fait de pouvoir faire joujou, ce script peut-être intéressant pour réaliser des traitements récursifs qui sont justement trop importants.
En, effet, vous pouvez le combiner à une variable statique pour continuer le traitement lorsque l’erreur de débordement est déclenchée.

Comment restreindre l’instanciation d’une classe à une autre classe.

Voici une idée complètement « crazy » au quelle je vais apporter une solution à travers ce billet.
Nous allons utiliser un principe connu par de nombreux framework Web qui permet d’assurer la validité d’un formulaire: Le jeton !

L’intérêt étant de combiner cela avec le pattern Factory.

public class Master
{
	private static var _jeton	: Number	= -1;
 
	public function Master()
	{
	}
 
	public static function createSlave () : Slave
	{
		var _tmpSlave	: Slave;
 
		_jeton		= Math.random() * 500;
		_tmpSlave	= new Slave (_jeton);
		_jeton		= -1;
 
		return _tmpSlave;			
	}
 
	public static function get jeton () : Number
	{
		return _jeton;
	}
}

public class Slave
{
	public function Slave(_pJeton : Number = 0) : void
	{
		if (Master.jeton !== _pJeton && Master.jeton !== -1)
			throw new Error ("Instanciation obligatoire par Master.createSlave");
	}
}

new Slave (); //throw Error
Master.createSlave (); //Retourne un objet du type Slave

Les conventions de nommage font parties de la vie d’un développeur qui souhaite faire du bon boulot.
En effet, cela permet une meilleur compréhension visuelle. Ce qui est pratique pour détecter certains problèmes évidents.

Bref, la convention de nommage concernant les classes est celle-ci :

• 1ère lettre en majuscule
• Mélange de minuscule, majuscule avec la première lettre de chaque mot en majuscule
• Donner des noms simples et descriptifs
• Éviter les acronymes : hormis ceux commum (XML, URL, HTML, …)

Analyse du contexte Flash

var _monText : String = "Hello world";
var _monNombre : int = 42;
var _monGrandNombre : int = int.MAX_VALUE;

En Flash, il existe deux types int et uint tout deux primitifs comme String ou Number. Ces types ont deux constantes de classe (MAX_VALUE, et MIN_VALUE).

Il s’agit donc de Classes, alors pourquoi la convention de nommage n’a pas été respectée ?

Après une recherche – très rapide grâce aux membres de mediabox – il en ressort que int et uint appartient à Number.

Si on analyse le code ci-dessous, on peut se rendre compte que le constructeur d’une variable de type int ou uint est Number.

var n_num: Number = 12.3;
trace(n_num["constructor"]); // [class Number]
 
var n_int: int = 12;
trace(n_int["constructor"]); // [class Number]
 
var n_uint: uint = 12;
trace(n_uint["constructor"]); // [class Number]
 
trace(n_num["constructor"] == n_int["constructor"]); // true
trace (typeof (n_num) + " " + typeof (n_int) + " " + typeof (n_uint)); //number number number

Grâce à cette démonstration par le code, nous pouvons constater que Flash respect bien la convention de nommage sur les classes, car int et uint ne sont que de « simples » appels à Number.

Maintenant, QUID de la gestion mémoire ?

PS: Autre blog, autre temps, troyworks s’est posé la même question sous une autre forme. Assez perturbant tout cela.