Armetiz

Avec un simple message, Adobe donne le ton aux utilisateurs iPhone qui souhaitent installer le player Flash. Et montre que tout est de la faute à Apple si Flash n’est pas présent.

Voici une traduction :
Apple restreint l’utilisation des technologies requises par les produits comme Flash Player. Tant que Apple ne supprimera pas ces restrictions, Adobe ne pourra pas fournir Flash Player pour l’iPhone ou l’iPod Touch.

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