Récupérer un Loader depuis un callback de type IOErrorEvent...

« février 2008 »
lun	mar	mer	jeu	ven	sam	dim
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29

« février 2008 »

lun

mar

mer

jeu

ven

sam

dim

Tout le monde aura déjà écrit un code de ce genre :

Ca marche bien. Mais il se trouve que dans mon projet, on a tendance à avoir besoin de beaucoup, beaucoup de loaders. Je me suis donc dit "Allons, Tyn, utilise donc un pool !" Ce qui marche également bien. On a un gain de plus de 1000% en utilisant un pool de Loader plutôt que d'en créer de nouveaux à chaque fois.

Mais qui dit pool dit nettoyage d'objet, et rendu dudit objet au pool après son utilisation. Hors, dans ce cas précis, j'ai un gros soucis: je ne peux pas récupérer mon objet Loader dans mon callback onIOError! C'est quand même très, très con. Ca signifie que je perds un élément de mon pool à chaque URL foireuse, ce qui est un leak inacceptable.

Voici donc un contournement foireux pour récupérer son objet Loader depuis un callback où LoaderInfo.loader n'est pas encore renseigné:

package net.tynambule.exp 
{
	import flash.display.Loader;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.IOErrorEvent;
	import flash.net.URLRequest;
	import flash.utils.Dictionary;
		
	public class IOErrorCallbackWithLoader extends Sprite 
	{
		private var _loaders : Dictionary = new Dictionary(true);

public function IOErrorCallbackWithLoader()
		{
			var ldr : Loader = new Loader();
			ldr.contentLoaderInfo.addEventListener(Event.INIT, onInit);
			ldr.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
			// Feinte ici :
			_loaders[ldr.contentLoaderInfo] = ldr;
			ldr.load(new URLRequest("existe-po.png"));
		}
		
		private function onInit(e : Event) : void
		{
			trace("Trop bien, le fichier existait!");
			// Ne pas oublier d'effacer ma référence, histoire que mon Loader puisse
			// être garbage collecté.
			delete _loaders[e.target];
		}
		
		private function onIOError(ioe : IOErrorEvent) : void
		{
			trace("Le fichier existait pas, mais j'ai toujours mon loader!");
			trace("Le voici :" + _loaders[ioe.target]);
			// Ne pas oublier d'effacer ma référence, histoire que mon Loader puisse
			// être garbage collecté.
			delete _loaders[ioe.target];
		}
	}
}

Et hop. C'est quand même bien crade. Si un gentil développeur de chez Adobe passe par ici (sait-on jamais), c'est quand même con que le Loader ne soit pas accessible depuis l'objet LoaderInfo en cas d'erreur de chargement alors qu'il est disponible avant le chargement. Allez, salut.

Commentaires

1. Le jeudi 13 mars 2008 à 00:21, par okenneko

Bonjour Tynril !

Essaie comme ça

ldr.contentLoaderInfo.addEventListener(Event.INIT, onInit(ldr));

private function onInit(loader):Function
{
return function(e:Event)
{
delete loader;
}
}

ca devrait marcher.

2. Le mardi 25 mars 2008 à 10:23, par LAlex

Utilise-tu les content de ce pool simultanement ou se remplacent-il les uns les autres? Parce que sinon, je suppose que tu dois être confronté au bug du changement de parent du content, dont parle Thibault sur ByteArray: www.bytearray.org/?p=127

++ ^_^

3. Le mercredi 02 avril 2008 à 15:19, par Tynril

okenneko > Jolie feinte. Je vais tenter le coup.

LAlex > En fait, pour parer à la casse, j'utilise les loaders comme DisplayObject également. En gros, je reparente mon objet Loader mais jamais son contenu.

Du coup, le problème se pose pas. C'est plus lourd à traiter (enfin, j'imagine qu'un Loader est plus lourd qu'un simple Sprite par exemple, même si au niveau de la display list ça doit pas changer grand chose), mais vu que j'utilise les loaders pour constituer une scène précalculée que je place ensuite dans un backbuffer (à grand coup de draw()), ça ne coince pas.

Enfin, pas pour le moment. Saleté de bugs planqués, quand même. :p

Trackbacks

Commentaires

Ajouter un commentaire

Recherche:

Rechercher

Catégories:

Tags:

Archives:

Liens:

Contact

Projets

Collègues

Emplois

Divers

Syndication: