Forums Développement Multimédia

Les formations Mediabox
Les formations Mediabox



Chat SharedObject partie 01 : Liste d'utilisateur

Compatible ActionScript 2. Cliquer pour en savoir plus sur les compatibilités.

Article écrit le 05/04/2007 12:50.
Par drakini ( Drakini ).

Nous allons créer ici une liste d’utilisateur, qui utilisera un SharedObject pour stocker les différents clients connectés à notre application. L’utilisation est simple. Un utilisateur arrive dans mon application, ce connecte, et son nom s’insère dans la liste des utilisateurs déjà présents. Pour suivre ce tutorial, il est nécessaire de maîtriser les bases de FMS et d’avoir réalisé et compris la manipulation des SO, côté client.

Tutorial SharedObject

Mise en forme de l'application : Nous allons avoir besoin ici, d’un module de connexion, composé d’un champ texte et d’un bouton. L’utilisateur insère son nom et l’envoi au serveur pour validation/connexion. Pour faire simple, nous allons utiliser ici le composant List d’Adobe. Il suffit de glisser une instance de ce composant dans votre application.

Pour le moment, il suffit de créer dans votre dossier application, sur le serveur, un dossier portant le nom que vous voulez donner à votre application. Je vais l’appeler ici userListso. Commençons par nous connecter au serveur.

CODE : Côté client

//-----------------------------------------------------------------
// ***  Utilisateur  ***
var _user:Object = {};
 
// *** Connexion ***
var _nc:NetConnection = new NetConnection();
_nc.onStatus = function(info) {
	if (info.code == "NetConnection.Connect.Success") {
		init();
	}
};
//
login_btn.onPress = function() {
	_user.login = login_txt.text;
	_nc.connect("rtmp:/userListso", _user);
};
//
//-----------------------------------------------------------------

On crée un objet _user, correspondant à l’utilisateur. On crée une instance de notre objet NetConnection, suivi de son événement onStatus, qui nous permettra de vérifier le statut de connexion de notre nouveau client. Lors du click sur le bouton login, on envoi notre requête de connexion au serveur, en lui envoyant notre objet _user en paramètre. L’évènement onStatus de cet instance ce déclenche alors. Si la réponse du serveur est positive, l’on accepte la connexion de ce client, et on appelle une fonction d’initialisation. Plusieurs objets, via FMS possèdent un événement onStatus. La classe NetStream, par exemple. A chaque fois que cet événement est appelé, un objet d’information est renvoyé côté client. Cet objet possèdent plusieurs propriétés qui dépendent de la classe en question. Je vous conseille de parcourir la documentation de FMS sur les objets d’informations.

Nous avons donc envoyé au serveur un objet _user, possédant une propriété login, correspondant au nom de notre client en cours de connexion. Voyons maintenant côté serveur ce qui ce passe. Nous allons ici renseigner un fichier main.asc, qui doit ce trouver dans le dossier de votre application userListso.

CODE : Côté serveur

//-----------------------------------------------------------------
//
application.onAppStart = function() {
	this.userList = SharedObject.get("public/userList");
}
//
application.onConnect = function(nouveauClient, objClient) {
	//
	this.acceptConnection(nouveauClient);
	//
	nouveauClient.readAccess = "public/";
    	nouveauClient.writeAccess = "public/";
	nouveauClient.login = objClient.login;
	//
	this.userList.setProperty(objClient.login, nouveauClient);
}
//
//-----------------------------------------------------------------

L’événement onAppStart de notre instance d’application, est invoqué lorsque l’application est chargé par le serveur. Il va principalement nous servir à initialiser nos différentes propriétés de bases, et notre SharedObject, évidemment. ;-)

Ici, nous allons donc initialiser notre SO, côté serveur. Il va nous permettre de stocker les clients connectés. Nous allons définir comme propriété de notre objet application, un SharedObject. Nous allons l’appeler userList et il sera crée dans un dossier public. Je vous rappel que aussi bien côté serveur que côté client, l’on ne peut pas manipuler un SO, en passant directement par son nom. Nous sommes obligé de passé par une variable référente. Pas besoin de connecter notre SO à l’URI de notre connexion. En effet, côté serveur, les SO sont connecté de base, forcement. Si nous avions voulu que notre SO soit persistant sur le serveur, nous aurions mis en deuxième paramètre true. Par défaut, il est sur false. Le SO est donc temporaire.

Lors de l’appel de connexion, côté client, notre application s’initialise. Le serveur vérifie que le SO userList existe. S’il existe, l’application ce connecte au SO, sinon, elle le crée dans un dossier public.

L’événement onConnect est ensuite appelé. Nous n’allons pas faire de vérification de login, ce n’est pas le but ici. L’idéal serait de vérifier que le login n’est pas déjà utilisé, etc.… Pour le moment, on accepte la connexion du client. Je rappel ici que le premier paramètre de la méthode onConnect, est l’objet client en cours de connexion. Les paramètres suivants sont des variables pouvant êtres envoyées. Ici, nous recevons donc l’objet _user, envoyé précédemment.

Après avoir accepté la connexion, on définit les propriétés de notre nouveau client.

Dans la méthode onConnect, une fois la connexion accepté, nous allons assigner une propriété à notre SO, via la méthode setProperty. Cette méthode ce retrouve uniquement en SSAS (Server Side Action Script). Ici, nous allons assigner à notre SO une propriété qui portera le nom du client, et qui contiendra un objet. Le nouveau client qui vient de ce connecter. Avec ce principe, dès qu’un client arrive sur notre application, on l’insère directement dans notre SO.

Analysons côté client, comment notre liste va pouvoir récupérer ce client connecté à notre application, précédemment insérer dans le SO donc…

CODE : Côté client

//-----------------------------------------------------------------
//
function init() {
	// SO userliste
	var useList = SharedObject.getRemote("public/userList", _nc.uri, false);
	userList.onSync = function(list) {
		trace("--- Synchronisation du SO userList ---");
		grid.removeAll();
		for (var i in userList.data) {
			if (userList.data[i] != null) {
				var clientObj = userList.data[i];
				grid.addItem({label:clientObj.nom, data:clientObj});
			}
		}
	};
	userList.connect(_nc);
}
//-----------------------------------------------------------------

Dans la méthode d’initialisation, qui ce déclenche, après validation de la connexion du client, nous créons donc une référence à notre SharedObject. Ici, si l’objet partagé userList existe déjà sur le serveur, ses données sont chargées, sinon, il est crée. En appelant la méthode getRemote, nous allons donc faire une pierre deux coups. Vérifier l’existence d’un SO sur le serveur, et le créer s’il n’existe pas. Nous pouvons ici voir la différence entre le code côté serveur, et celui côté client, pour générer et/ou vérifier l’existence d’un SO.

Comme je le disais, en AS, nous ne pouvons pas nous référer à notre objet partagé en passant par son nom, c’est pour ceci que nous passons par une référence de ce SO, ici la variable userList. Le second paramètre de la méthode getRemote est l’URI (Uniform Ressources Identifier) de notre instance NetConnection. Le troisième est une booléen définissant si le SO est persistant ou temporaire. Il est primordial de déclaré votre SO de la même façon qu’il a été déclaré sur le serveur. Ici, temporaire. En effet, que ce soit côté client et côté serveur, nous nous rattachons au même SharedObject, userList.

L’événement onSync de notre SO, ce déclenchera à chaque modification / synchronisation de son contenu. Si un client ce connecte à notre application, il sera inséré côté serveur, dans le SO. Côté client, tous les utilisateurs connectés à ce SO, recevront donc la synchronisation nécessaire, et verront ce nouveau client, apparaître dans la liste.

FMS retourne au client un tableau contenant l’ensemble des propriétés de ce SO plus un objet d’information. Par une habile boucle for, nous allons donc fouiller les propriété contenu dans ce SO, soit l’ensemble des objets clients connectés, anciens, comme nouveau. Il suffit ensuite de vider la liste pour la réinitialiser et y insérer les noms de tous ces clients…

Dans notre méthode d’initialisation, il ne faut pas oublier, à la fin, de connecter notre SO, à notre instance NetConnection, connecté au serveur. En effet, côté client, notre SO ne ce connectera pas seul.

Voilà, nous sommes pratiquement au bout. Il ne nous reste qu’une chose à faire. Lors de la déconnexion d’un client, nous allons devoir le supprimé de notre liste d’utilisateur, donc de notre SO.

Revenons donc côté serveur et mettons en place l’événement onDisconnect de notre application.

CODE : Côté serveur

//-----------------------------------------------------------------
application.onDisconnect = function(objClient){
	this.userList.setProperty(objClient.login, null);
}
//-----------------------------------------------------------------

Cet événement est invoqué lorsqu’un client ce déconnecte de l’application. Son paramètre : l’objet client en cours de déconnexion. Ici, il suffit de mettre à jour notre SO. Nous renseignons donc sa propriété objClient.login par null. Nous vidons en quelques sorte cette propriété.

Le SO ce met donc à jour, et la synchronisation sera faite côté client. Le nom de cet utilisateur disparaîtra donc de la liste.

Sources

La deuxième partie de ce tutorial sera consacré, sur cette structure, à la mise en place d’un module de discussion.

En cas de question, n'hésitez pas à poser vos questions sur le forum. ;-)

Drakini