Pratiques recommandées – Recommandations sur la création d’applications SWF

La meilleure façon de procéder pour créer une application Animate dépend de l’application en question et de la technologie utilisée.

Une application en ligne permet à un utilisateur d’influencer un site Web du fait qu’il a des interactions avec le site. Par exemple, l’application pourrait recueillir des informations provenant de l’utilisateur (telles que nom d’utilisateur et mot de passe en vue d’une inscription). Celles-ci pourraient être ajoutées au site (par exemple dans un forum) ou bien l’utilisateur pourrait interagir en temps réel avec d’autres visiteurs du site par le biais d’un « white board » (zone de l’écran réservée au « chat ») interactif ou d’un « chat room » (salle de discussion virtuelle). Les résultats provenant du serveur apparaissent le plus souvent dans le fichier SWF selon l’interaction. Ces exemples sont des applications qui impliquent l’utilisateur ainsi que des interactions de types différents avec l’utilisateur. Un site Web qui n’utilise pas des informations ou des données provenant d’un visiteur ne constitue pas une application (par exemple, un portfolio, un dessin animé ou un site international d’information). Les applications Animate consistent en un processus interactif entre l’utilisateur, une application Web et un serveur. Le processus de mise à jour se déroule comme suit :

Vous devez choisir un protocole de transfert de données lorsque vous construisez une application. Le protocole prévient l’application de l’envoi ou de la réception des données, de la nature de leur mise en forme pour le transfert et de quelle façon il traite la réponse du serveur. Une fois que la réception des données est effectuée dans le fichier SWF, ces données doivent être traitées et mises en forme. Si vous utilisez un protocole, vous n’avez pas à vous soucier d’une mise en forme inattendue des données. Vous pouvez vérifier le format des données lorsque vous transférez des données par paires nom-valeur. Vérifiez bien que les données ont été mises en forme correctement pour ne pas recevoir des données mises en forme par XML et que le fichier SWF soit prévenu de la nature des données sur lesquelles il sera amené à travailler.

Collecte et formatage des données

Les applications dépendent de l’interaction de l’utilisateur avec le fichier SWF. Elle dépend fréquemment des données saisies par l’utilisateur dans des formulaires. Animate permet de saisir et de formater des données de différentes façons dans des applications Animate. Cette souplesse existe en raison des fonctionnalités dont vous disposez avec l’animation et le contrôle créatif sur l’interface, ainsi que la détection d’erreurs et la validation que vous permet le code ActionScript.

Vous pouvez développer des formulaires pour recueillir des données à l’aide d’Animate et profiter notamment des avantages suivants :

• Contrôle amélioré de la conception

• Actualisation des pages inutile ou faible

• Réutilisation de ressources communes

   Sauvegardez les informations recueillies auprès de l’utilisateur dans un objet partagé, sur son propre ordinateur. Vous pouvez stocker des données sur l’ordinateur d’un utilisateur par le biais d’objets partagés, ce qui est similaire à l’utilisation d’un « cookie ». Pour plus d’informations sur les objets partagés, voir la classe sharedObject dans le Guide de référence du langage ActionScript 2.0 ou Référence du langage et composants ActionScript 3.0.

Envoi et traitement des données

En règle générale, vous devez traiter les informations avant de les envoyer au serveur pour les mettre en forme de telle sorte que le serveur les comprenne. Quand le serveur reçoit les données, elles peuvent être traitées de façons différentes et renvoyées au fichier SWF dans un format qui lui convient, qui peut varier de paires nom-valeur à des objets complexes.

 Vous devez définir le type MIME de la sortie de votre serveur d’application sur application/x-www-urlform-encoded. Si ce type MIME est manquant, le résultat est le plus souvent inutilisable quand il parvient à Animate.

Dans le tableau suivant, vous pouvez voir plusieurs options pour envoyer des données à un serveur et en recevoir à l’aide d’Animate :

Ajout du chargement et de la validation des données

Vous devez valider toutes les données que vous récupérez avant de pouvoir les envoyer à un serveur. Ceci déleste le serveur distant parce qu’il ne traite pas les requêtes lorsque les utilisateurs ne remplissent pas les champs requis. Vous ne devez pas compter uniquement sur la validation côté client dans une application ; une validation côté serveur est également nécessaire.

Même si vous ne remplissez qu’une simple formule d’inscription ou de « login », assurez-vous que l’utilisateur a fourni son nom et son mot de passe. Vous devez exécuter cette validation avant d’envoyer la requête au script distant côté serveur et d’attendre le résultat. Vous ne devez pas compter uniquement sur la validation côté serveur. Si un utilisateur saisit seulement son nom d’utilisateur, le script côté serveur doit recevoir la requête, valider les données qui lui ont été transmises et renvoyer un message d’erreur à l’application Animate indiquant que le nom d’utilisateur et le mot de passe sont tous deux obligatoires. De même, si la validation n’est exécutée que côté client (dans le fichier SWF), un utilisateur malveillant pourrait s’introduire dans le fichier SWF, contourner la validation et envoyer des données à votre serveur en vue de fournir des données douteuses.

La validation côté client peut être très simple. Vous pouvez vous borner à vérifier qu’un champ de formulaire contient au moins un caractère ou que l’utilisateur a saisi une valeur purement numérique. Pour valider une adresse électronique, par exemple, assurez-vous que le champ de texte dans Animate n’est pas vide et qu’il contient au moins les caractères arobase (@) et point (.). Pour la validation côté serveur, vous devez exercer un contrôle plus complexe et vérifier que l’adresse courriel appartient à un domaine valable.

Vous devez rédiger du code ActionScript pour traiter les données qui proviennent du serveur et qui sont chargées dans le fichier SWF. Après avoir chargé toutes les données dans un fichier SWF, vous pouvez y accéder depuis cet emplacement. Vous pouvez utiliser du code ActionScript pour vérifier si les données sont entièrement chargées. Vous pouvez utiliser les fonctions de rappel pour envoyer un signal indiquant que les données ont bien été chargées dans le document.

Les données que vous chargez peuvent avoir des formes différentes :

• Vous pourriez charger XML ; à ce moment-là, vous pourriez recourir aux méthodes de classe et de propriétés XML pour analyser les données et les utiliser. Si vous utilisez les paires nom-valeur, elles se transforment en variables et vous pouvez les traiter comme telles.

• Vous pourriez recevoir des données d’un service Web ou d’Animate Remoting.

Dans les deux cas, vous pourriez recevoir des structures de données complexes telles que des tableaux, des objets ou des ensembles d’enregistrements que vous devez analyser et associer de manière appropriée.

Traitement des erreurs et débogage

Votre application doit être suffisamment robuste pour anticiper les erreurs et les traiter en conséquence.

L’une des meilleures façons de pratiquer la gestion d’erreurs dans ActionScript 2.0 consiste à utiliser les blocs try-catch-finally qui vous permettent de déclencher et intercepter (« throw and catch ») des erreurs personnalisées. Vous pouvez réutiliser du code partout dans votre application sans avoir à réécrire du code de traitement d’erreurs par la création de classes personnalisées d’erreurs. Pour plus d’informations sur le déclenchement d’erreurs sur commande, voir la classe Error dans le Guide de référence du langage ActionScript 2.0. Pour plus d’informations sur les blocs try-catch-finally, voir try.catch..finally dans le Guide de référence du langage ActionScript 2.0.

Dans ActionScript 3.0, utilisez la classe flash.errors pour intercepter des erreurs.

Pour plus d’informations, voir « Gestion des erreurs de synchronisation dans une application » dans Programmation avec ActionScript 3.0.

Organisation des fichiers et stockage du code

Posez-vous les questions suivantes avant de commencer à organiser vos fichiers et à stocker du code :

• Répartissez-vous le fichier SWF en de multiples fichiers SWF et, dans l’affirmative, comment devraient-ils interagir ?

• Quelles ressources pouvez-vous partager entre fichiers SWF ?

• Quels fichiers chargez-vous dynamiquement ?

• A quel emplacement et de quelle façon stockez-vous le code ActionScript ?

  Lorsque vous développez une application, veillez à stocker dans une structure de répertoire logique votre code côté serveur et vos fichiers, comme c’est le cas dans un progiciel d’ActionScript. Vous devez disposer votre code ainsi pour le maintenir bien organisé et réduire le risque de le voir se faire écraser.

  Pour des applications plus importantes, vous devez encapsuler les communications et services client-serveur dans des classes. Vous pouvez retirer les avantages suivants de l’utilisation des classes :

• Vous pouvez réutiliser le code dans plus d’un fichier SWF.

• Vous pouvez modifier le code à un emplacement spécifique et mettre à jour tous les fichiers SWF en les republiant.

• Vous pouvez créer une API unique qui peut traiter différents éléments de l’interface utilisateur ou bien d’autres ressources qui exécutent des fonctions similaires.

Utilisation du modèle de conception MVC

Le modèle de conception MVC est utilisé pour séparer les informations de la sortie et du traitement des données dans l’application. L’application est composée de trois éléments : modèle, affichage et contrôleur. Chacun d’eux traite une partie différente du processus.

intègre les données et les règles de l’application. La majeure partie du traitement de l’application se déroule dans ce secteur du modèle de conception. Le modèle contient également les composants (tels que CFCs, EJBs et services Web) et la base de données. Les données retournées ne sont pas mises en forme pour l’interface (ou partie frontale) de l’application dans ce secteur du processus. Les données retournées peuvent être utilisées pour différentes interfaces (ou affichages).

traite la partie frontale de l’application (l’interface avec laquelle l’utilisateur interagit) et fournit les contenus du modèle. L’interface spécifie de quelle façon les données du modèle sont présentées et imprime l’affichage pour le compte de l’utilisateur. Elle permet à l’utilisateur d’accéder aux données de l’application et de les traiter. Si le modèle est modifié, l’affichage est mis à jour pour en rendre compte à l’aide de la technologie du pousser-tirer (envoyer ou demander des données). Si vous créez une application Web hybride (par exemple, une application qui inclut l’interaction d’Animate avec d’autres applications de la page), considérez les interfaces multiples comme faisant partie de l’affichage dans le modèle de conception. Le modèle de conception MVC prend en charge divers affichages.

traite les conditions d’utilisation du modèle et de l’affichage pour traiter et afficher les données. Il contient le plus souvent une grande quantité de code. Il appelle une partie quelconque du modèle en fonction des requêtes de l’utilisateur provenant de l’interface (ou de l’affichage) et contient du code qui est spécifique à l’application. Comme ce code est spécifique à l’application, il n’est généralement pas réutilisable. Par contre, les autres composants du modèle de conception sont réutilisables. Le contrôleur ne traite pas et n’imprime pas les données. Il se borne à accueillir la requête de l’utilisateur, à décider quelle partie des composants du modèle ou de l’affichage il doit appeler et à déterminer à quel endroit il doit transmettre ces données et quelle mise en forme s’applique aux données retournées. Le contrôleur s’assure que les affichages disposent d’un accès aux parties du modèle qu’ils doivent exposer. En règle générale, le contrôleur transmet et répond aux modifications qui s’appliquent au modèle et à l’affichage.

Chaque partie du modèle est conçue comme un composant autonome dans le processus global. Si vous modifiez une partie du modèle (par exemple, si vous voulez revoir l’interface), les autres parties du processus ne sont pas affectées le plus souvent, ce qui réduit les anomalies. Si votre modèle de conception est construit correctement, vous pouvez modifier l’affichage sans revoir le modèle ou le contrôleur. Si votre application ne fait pas appel à MVC et que vous apportez des changements n’importe où, cela peut occasionner des répercussions en chaîne dans tout votre code, ce qui demande davantage de modifications que si vous utilisiez un modèle de conception spécifique.

Il est important d’utiliser un modèle MVC pour séparer les données et la logique de l’interface utilisateur. Vous pouvez disposer de plusieurs interfaces graphiques différentes qui utilisent le même modèle ainsi que des données sans mise en forme si vous séparez ces parties du processus. Cela signifie que vous pouvez utiliser votre application avec des interfaces Animate différentes, telles qu’une interface pour le Web, une pour votre ordinateur de poche (« Pocket PC »), une version pour téléphones mobiles et peut-être une version en code HTML qui n’utilise pas du tout Animate. Si vous séparez les données du reste de l’application, cela réduit considérablement les délais de développement, de test et même de mises à jour si vous avez plus d’une interface client. De la même façon, vous pouvez ajouter de nouveaux programmes frontaux pour la même application plus aisément si vous disposez d’un modèle existant.

Vous ne devriez utiliser MVC que si vous montez une application importante ou complexe, telle qu’un site Web de commerce électronique ou une application de formation en ligne. Vous devez planifier et comprendre comment Animate et ce modèle de conception fonctionnent pour utiliser l’architecture. Vous devez réfléchir avec soin de quelle façon les différentes pièces interagissent ; cela demande le plus souvent des tests et du débogage. Si vous utilisez MVC, cela nécessitera des tests et des opérations de débogage plus poussés et complexes que pour des applications Animate classiques. Si vous construisez une application d’une certaine complexité, pensez à utiliser MVC pour organiser votre tâche.

Création d’applications sécurisées

Que vous construisiez un site doté d’un portail simple auquel des utilisateurs peuvent accéder ou sur lequel ils peuvent lire des articles ou bien un magasin électronique important, des utilisateurs malveillants pourraient être tentés de s’introduire dans votre application. Pour cette raison, vous devriez tenir compte des éléments suivants pour rendre votre application plus sûre :

• Transmettez avec le protocole HTTPS les données qui nécessitent une sécurisation. Cryptez les valeurs dans Animate avant leur envoi vers un serveur distant pour traitement.

   ne stockez jamais dans un fichier SWF des informations ou du code auxquels des utilisateurs ne devraient pas avoir accès. En effet, il est facile de désassembler des fichiers SWF et d’exposer leur contenu à l’aide de programmes tiers.

• Ajoutez une stratégie interdomaine pour empêcher les domaines sans autorisation d’accéder à vos ressources.