Bleue comme une Orange

suite à l’appel au peuple lancé par Michael chaize, je me suis décidé à tenter une application Air pour facebook.

Au passage, j’ai découvert plein de choses sur le httpservice, les urlloader et les htmlloader : par exemple si on fait un POST avec des paramètres qui contiennent des underscore dans leur nom (genre msg_id), les paramètres seront passés avec le _ transformé en %5F (soit msg%5Fid dans l’exemple). La manipulation des entetes (cookie, userAgent, connection, etc…) promet aussi de bonnes rigolades pour ceux qui veulent choisir le keep-alive ou le close.

Du coté Facebook j’ai découvert qu’il n’aime pas flash ou air comme UserAgent, qu’il encode son unicode en utf8 et qu’il utilise le 302 pour faire des redirect.

Si avec tout ca, fairtalk fonctionne on se rapproche de la zone miracle, ou plutot pour citer un célèbre architecte : “le systeme risque de tomber en marche” (pour les détails de l’histoire, voir la page en anglais sur ce site).

Comme c’est une alpha, le feedback est le bienvenue. Pour cela une adresse email : fairtalk.app@gmail.com

ChangeLog :

version 0.5

* Integration du design de Michael
* Welcome screen affiche la version
* Ajout d’une logTarget de type LocalConnectionTarget

version 0.4

* Correction : multifenetre indexe maintenant la bonne fenêtre
* passage des fenêtres de chat en chromeless
* modification du look des ChatWindow
* Ecriture d’un mock pour simuler une connection

version 0.3

* Correction : fonctionnement avec les caractères accentués
* Ajout de messages dans la status bar
* Refactoring des classes RPC

version 0.2

* avec tout plein de morceaux de bug dedans. (ne fonctionne pas à travers un proxy)

Mise à jour du CodeTester disponible au même endroit

J’ai inclus :

• une version modifiée de FleSpy qui prend en charge les event-listeners
• l’utilisation du logger avec en target l’application AIR logBook
• La lib flexUnit pour les test unitaires avec un exemple et une view pour lancer les test
• Une petit refactoring pour séparer les sources du projet et les sources des “bouts de code à tester”

Read the rest of this entry »

- Traduction de l’article No 2 dans la série composants de Peter Ent. (Voir l’article original) -

Dans l’article précédent je vous ai montré comment faire un composant basé sur un composant MXML existant, le HBox. Dans cet article nous regarderons comment réaliser le même composant en ActionScript. Je pense que c’est un exercice intéressant car il vous montrera comment les composants MXML et ActionScript sont similaires.

Read the rest of this entry »

il m’arrive fréquemment de vouloir tester un “bout” de code pour comprendre comment fonctionne un composant ou une librairie. Généralement, c’est parceque je pense que je vais en avoir besoin dans mon projet en cours. Dans le pire des cas, je cree un nouveau composant dans mon projet et je fais un lien a partir d’une autre vue. Dans le meilleur des cas je fais un nouveau projet et je colle le sample dedans. Problème, je me retrouve avec plein de projets qui servent pas a grand chose et je me souviens jamais dans quel projet j’ai testé tel ou tel truc. Au final je me retrouve avec plein de projets appelés samples# ou test# voir avec un workspace entier rempli de ces trucs la.

Read the rest of this entry »

Suite à ma conversation avec yann (cf post sur les tontons) Il fallait bien commencer par quelque chose alors j’ai choisi un article de Peter Ent pour m’essayer à la traduction. Bien que j’ai des doutes sur certaines phrases car je pense avoir un ‘accent’ déjà bien marqué quand je parle. Ma femme ne comprenant pas quand je lui explique que “depuis que j’ai changé les properties du build du sample, mon run a un drole de display dans le player”. Pourtant, c’est clair!

Read the rest of this entry »