So let me introduce the first one.
I needed a multi-users game server. So after some googling to browse OS projects, I decided to build a new one from scratch with Apache Mina 2.0 using my R&D xp.
I choosed to install Ubuntu with Parallels to have an easy workflow with a local test workstation.

At this time, I’ve obtained something basic which works fine. That’s full AMF (using BlazeDS ) and it manages users and rooms.
That’s all based on simplicity. No events, no verbosed implementation or mess with abstract design…

My next step and goals:
- Have something robust.
- Build a graphical chat showcase with text to speech feature.
- Build a game showcase with realtime synchronicity. I read a lot of resources about it, and I’m looking forward to work on this.

But I’m wondering about few things at this time:
- Should I go to open source ?
- Should I mix this implementation with Darkstar project ?
- Should I work on a cheap product ?
Any advice would be welcome !

Here’s a basic echo demo to end this thread and showcase the concept:

import net.tweenpix.pixserver.amf.AMFClient;

	public class EchoAMFClient
	{
		protected var _client : AMFClient;

		public function EchoAMFClient()
		{
			_client = new AMFClient( );
			_client.registerClass( TestVO );
			_client.connect( "10.211.55.4", 9123 );

			_client.addEventListener( "EchoMessage",  onEchoMessage );
			_client.sendRequest( 	"EchoMessage",
								new TestVO( "francis", 38 ),
								new TestVO( "virginie", 35 ) );
		}

		public function onEchoMessage( vo1 : TestVO, vo2 : TestVO ) : void
		{
			// do something
		}
	}

as3svnlib est une surcouche de as3httpclientlib (client http et https) qui implémente deux méthodes (PROPFIND et REPORT) du protocole WebDAV et permet les opérations de lecture standards.

Le code source est disponible ici et le SWC compilé ici.

J’imagine déjà le développement d’une librairie complète (commits, branching, diffs…) interfacée avec un puissant outil collaboratif en AIR… Un joli projet commercial en perspective, non ? A bon entendeur !

Via dougmccune

Si vous vous passionnez pour Alchemy, voici un blog à bookmarker. Mateusz proposera bientôt un tutorial sur GlueGen, générateur de code ActionScript à partir d’un wrapper C/C++, malheureusement encore non documenté sur le labs.

Mike Chambers vient de publier sur l’appStore une application pur geek: ActionScript 3 API Reference for iPhone.
Toute la documentation des classes Adobe AIR 1.5, Adobe Flex 3.2 et Flash Player 10 compilée spécialement pour votre iPhone.
Bonne nouvelle, le poids du contenu a été optimisé pour le smartphone. L’application fait seulement 10 mégas contre 40 pour l’AS3 Language Reference en AIR de Big Spaceship.

Sont disponibles pour les recherches un filtre de saisie et un scroller alphabétique. Aucun vrai moteur lexical à l’horizon pour l’instant !

Vous trouverez plus d’infos sur cette page.
Ceux qui sont pressés peuvent se rendre directement sur iTunes.

Merci Mike, voilà de quoi devenir incollable, … même sous la douche !

Via twitter

La bonne nouvelle, c’est que le code source complet de cette démo (avec toutes ses dépendances) est disponible ici.

Pour finir, voici la démo vidéo qui m’a bluffé et donné envie une fois de plus de tester cette librarie:

AR New Year Greeting Card from Saqoosha on Vimeo.

La librairie est découpée en 3 parties:

- Représentation du modèle de données en mémoire:
Il s’agit d’un arbre découpés en noeuds de différents types: Properties, structures, arrays, qualifiers…
L’API de la librairie s’assure à chaque instant de la validité des données de l’arbre afin qu’elles puissent être sérialisées à la demande. Une exception est lancée dans le cas contraire.

- Parseur (XML, String ou ByteArray) :

var xmpStr: String = "”
+ data + "";
var xmp: XMPMeta = new XMPMeta(xmpStr);

- Sérialiseur (XML, String ou ByteArray):

var xmp:XMPMeta = new XMPMeta(...);
// ... modify metadata
var str:String = xmp.serialize();
var buffer:ByteBuffer = xmp.serializeToBuffer();

On devrait bientôt voir éclore des applications AIR capables de lire (et de réinjecter ?) le metadata d’un fichier CS4.

You have to make direct method calls on the client (as you would with JavaScript library). It returns a responder instance on each call:

var responder : EventDispatcher = client.Friends.get() as EventDispatcher;

To get some request results, you can suscribe listeners (as many as you want) to any responder:

responder.addEventListener(FacebookClientEvent.ON_RESULT, onFriends);
responder.addEventListener(FacebookClientEvent.ON_FAULT, onError);

And guess what, results are encapsulated in events passed as arguments to your callback methods:

public function onFriends( e : FacebookClientEvent ) : void
{
	trace ( e.methodName + " call: " + e.result.length );
}

Clean and easy as I like it.
Last but not least, you got some errors reporting. I had hard time on this part, coz the JS implementation was acting weird. I’m not even sure at this time to have understood the whole error process. I must finalize this part, few errors aren’t caught at this time but every transaction is logged in firebug with Debug.dump JS calls.

public function onError( e : FacebookClientEvent = null ) : void
{
	trace ( "onGetInfoError(" + "method:" + e.methodName
				+ ", error_code:" + e.result.error_code
				+ ", error_msg:" + e.result.error_msg + ")" );
}

Here’s a short demo to end the teasing around this project.
In this example, client retrieves all the name and profile photos urls of a user friends list through 2 API calls.

package
{
	import com.bourre.facebookflashapi.FacebookClient;
	import com.bourre.facebookflashapi.FacebookClientEvent;

	import flash.display.Sprite;
	import flash.events.EventDispatcher;

	public class FacebookClientTest
		extends Sprite
	{
		protected var client : FacebookClient;

		public function FacebookClientTest()
		{
			client = new FacebookClient();

			var responder : EventDispatcher = (client.Friends.get() as EventDispatcher);
			responder.addEventListener(FacebookClientEvent.ON_RESULT, onFriends);
			responder.addEventListener(FacebookClientEvent.ON_FAULT, onError);
		}

		public function onError( e : FacebookClientEvent = null ) : void
		{
			trace ( "onGetInfoError(" + "method:" + e.methodName
						+ ", error_code:" + e.result.error_code
						+ ", error_msg:" + e.result.error_msg + ")" );
		}

		public function onFriends( e : FacebookClientEvent ) : void
		{
			trace ( e.methodName + " call" );

			( client.users.getInfo( {uids:e.result, fields:["name", "pic_big"]} )
			as EventDispatcher).addEventListener(FacebookClientEvent.ON_RESULT, onGetInfo);
		}

		public function onGetInfo( e : FacebookClientEvent ) : void
		{
			for each ( var o : Object in e.result )
				trace ( "Nom:" + o.name + ", Image:" + o.pic_big );
		}
	}
}

I will release the source code under an open source licence when it’ll be a bit more polished for people who want to try it, and maybe I’ll make a video tutorial, who knows !

Avec l’aide de Charles qui m’indiquait l’absence de mes headers (Authorization-Basic), et une bonne dose de patience, j’ai fini par comprendre que cela venait d’une limitation du crossdomain qui interdisait les http request headers venant de l’extérieur du domaine.

Etonnant pour un service web 2.0 dit ouvert ?

Le seul workaround que j’ai trouvé pour l’instant, c’est de builder une appli AIR pour bypasser ces limitations.
Il reste une dernière possibilité (non testée), déployer un proxy server-side pour acheminer les requêtes. Mais bon, c’est pas la panacée pour du développement applicatif.

Au final, je suis un peu déçu, non seulement par les contraintes de l’API pour les développeurs Flash, mais aussi par l’absence de documentation sur le sujet !

Comme la librairie de GreenSock, cette librairie est déclinée en 2 versions. D’un côté la version complète, de l’autre la version light pour les projets à haute contrainte de poids comme les bannières publicitaires.

Shane McCartney nous vante les prouesses de sa librairie en matière de performances avec preuve à l’appui: « J’ai réussi à rendre Tweensy plus rapide que l’ancien tenant du titre AS3: TweenLite/TweenMax. »

Il n’est pas en reste non plus concernant la puissance de l’API de son bébé: « Mais ne pensez pas que Tweensy est juste un moteur de tween efficace de plus, il est aussi conçu pour rivaliser (dépasser à mon humble avis) n’importe quel moteur de tween AS3 existant. S’il manque quelque chose, n’hésitez pas à le demander. »

Concernant cette partie, j’avoue avoir été assez bluffé par l’étendue des possibilités disponibles. La documentation et certaines parties du wiki permettent de se faire une idée du potentiel mis en oeuvre.

En résumé, une librairie à tester de toute urgence pour voir ce qu’elle a dans le ventre en cas pratique !

Via lostinactionscript.com

Merci à Ed Mc Manus pour ce joli travail !
Dommage que Scott Petersen n’ait jamais publié la version qu’il utilise dans ses différents portages (Quake, émulateur Nintendo…).