Vous êtes ici : Accueil - Ressources Flash - Les bibliothèques partagées.
Parmis les choses difficiles à comprendre et à maîtriser dans Flash, les bibliothèques partagées représentent un gros morceau. Pour ma part, je considère que ce qu'il y a marqué dans la documentation officielle est plutôt obscure. De plus, c'est un des points de Flash où il est très difficile de trouver de la document sur le net. On peut trouver quelques liens intéressant sur des forums, mais cela demande encore des recherches.
Note : il est possible de rencontrer le terme de librairies partagées. C'est exactement la même chose. En anglais, seul le terme de "libraries" est utilisée. En français, il peut se traduire par bibliothèque ou librairie.
Une bibliothèque partagé n'est rien d'autre qu'un fichier swf contenant des objets dans sa bibliothèque accessibles pour d'autres fichiers swf. On peut alors aisément imaginer d'innombrables utilisations : éclatement de projets pour des groupes de développement, skinnage d'API online, portabilité de swf Mac/PC (notemment les polices de caractères sans à avoir à recompiler)...
Bien sûr, suivant les projets, certaines "architectures" sont meilleurs que d'autre. Celle que je propose et que je vais expliquer ici me semble la plus optimisée pour toutes sortes de projets. Mais je tiens à préciser qu'il est tout à fait possible que cette structure ne corresponde pas à votre façon de travailler.
La présence sur la scène principale d'un seul symbol de la bibliothèque partagée suffit à charger cette dernière et à en rendre disponible tous ses symbols liés.
Voici un exemple simple pour illustrer:
À partir de là, tous les clips créés dans la bibliothèque partagée librairie.fla et liés sur le même principe que lien_librairie seront accessibles depuis principal.fla. et pourront être utilisés en AS. L'exemple est en téléchargement ici.
Note : pour la suite de l'article, je ne rentrerais pas dans les détails d'un préchargement des bibliothèques pour qu'elles soient disponibles en mémoire plus rapidement. Il est possible de trouver sur le net (forums et sites particuliers) différents massLoader plus ou moins performant.
L'un des passages les plus fastidieux est la plannification d'un projet dans sa structure : est-ce que cela sera un projet mené par plusieurs développeurs et graphistes? Est-ce que cela sera un projet d'application skinnable à souhait? Tous pleins de questions qui décideront de la forme que prendra un projet.
Procédons par ordre : le projet comportera plusieurs fichiers, il faut donc un script qui télécharge en masse (massLoader) tout ce qui est nécessaire au démarrage. Les bibliothèques partagées étant le but de cet article, les codes sources seront séparées du reste. Dans les bibliothèques partagées, il est bon de prévoir et de séparer ce qui va changer rarement de ce qui va être compilé très souvent. J'ai pris l'habitude de séparer au minimum les polices de caractères, la skin de base et les graphismes d'un projet donné. De la même façon, je sépare le massLoader du reste du code et les graphismes réservés pour celui-ci.
L'architecture des liaisons entre les fichiers prend cette forme là :
massLoader ─ graphisme4massLoader
engine ┬ fonts
├ skin_base
└ graphisme
Pour certains projets, il m'est même arrivé de devoir utiliser des polices venant de Mac et d'autres de PC, tout cela pour un même projet : l'horreur pour la compilation.
Voilà, une petite astuce qui m'a permis bien des tracas. À partir de la bibiliothèque partagée fonts.swf, j'ai ciblé en autant de fichiers que j'avais de de polices. Ce qui au final m'a donné ceci :
massLoader ─ graphisme4massLoader
engine ┬ fonts
│
│
│
│
│
├ skin_base
└ graphisme
┬ fonts_pc1
├ fonts_pc2
├ ...
├ fonts_mac1
├ fonts_mac2
└ ...
Et après une première utilisation, je doit avouer que cela m'a bien soulagé sous plusieurs aspects, surtout en programmation où il a fallu que je modifie tous les noms de liaison pour ne pas avoir de conflit entre eux.
Là où le problème se complique, c'est la déclaration des liaisons entre l'exportation au runtime et l'importation des bibliothèques lorsque les fichiers Flash sont rangés dans différents dossiers pour structurer un projet.
En règle général, le lien d'export ne semble pas avoir d'impact sur la bibliothèque partagée puisqu'importée à partir de n'importe quel fichier Flash, celle-ci dispose ses symbols liés à ces derniers. Mais Flash étant bizarre sur pas mal de point, on est obligé d'indiquer un lien. Seul le lien d'import des bibliothèques déclaré par rapport au fichier flash "embeddé" dans le fichier html est à prendre en compte.
Note : dans la source téléchargeable plus haut, vous pouvez vous amuser à mettre n'importe quoi comme URL pour l'export au runtime dans les propriétés de liaison de lien_librairie de la source librairie.swf. Les autres symbols restent disponible depuis principal.swf. Par contre, en changeant le lien d'import du symbol lien_librairie du fichier principal.swf, plus aucun symbol de la bibliothèque n'est accessible. Flash devrait d'ailleur vous renvoyer une erreur à la compilation parce qu'il n'a pas trouvé la bibliothèque partagée.
La structure des dossiers que je vais développer ici n'est pas forcement la structure idéale pour tout le monde, mais elle me satisfait et semble claire pour tous ceux avec qui je travaille. ( Enfin, j'espère! \*O*/ )
/root ┬ actionscripts
├ librairies ─ fonts
└ datas
Note : Certains développeurs renomme le dossier actionscripts par le namespace de leur nom de domaine. Par exemple pour le mien, cela donnerait /com/roikku/actionscript.as.
Rien de bien compliqué : on place les différents fichiers Flash dans les répertoires correspondant :
/root ┬ massLoader
├ actionscripts
├ librairies
└ datas
┬ graphisme4massLoader
├ fonts
├ fonts
├ skin_base
├ graphisme
└ engine
┬ fonts_pc1
├ fonts_pc2
├ ...
├ fonts_mac1
├ fonts_mac2
└ ...
Et pour finir, il ne nous reste plus qu'à lier tout ce joli petit monde :
La structure de base est fin prète pour démarrer un nouveau projet.
Récemment, j'ai remarqué qu'un swf chargé sur le _root d'un autre n'écrasait pas réellement les occurences du fichier parent. Bien que visuellement, toutes les occurences instanciées sur la scène sont "détruites", il n'en va pas de même avec le scope de Flash. Comme tout téléchargement de fichier swf fait dans un clip conteneur, l'utilisation des symbols de la librairies sont limités au seul conteneur et ne peuvent pas être utiliser en dehors. Idem, de ce clip conteneur, il n'est pas possible d'accéder aux clips du fichier Flash parent.
Mais il nous reste une chose accessible depuis n'importe où : _global.
Si bien que le massLoader que j'utilise ne s'intéresse plus qu'à charger les librairies partagées, le module de programmation engine et à mettre tout cela dans le cache du navigateur. Une fois fait, il télécharge le module engine directement sur le _root. Les symbols du massLoader étant stockés dans graphisme4massLoader, il est tout à fait possible de replacer une occurence de lien_graphisme4massLoader dans engine.
Je me retrouve donc avec une classe massLoader toujours présente dans Flash et accessible par la variable _global, un _root qui me renvoye bien au _root de engine et les bibliothèques de symbols toujours présentes - dans le cache du navigateur.
Note 1 : Pour un projet CD-Rom, j'ordonne juste au massLoader de lancer le module engine sans rien précharger. Tout le reste se déroule de la même façon.
Note 2 : la remarque ci-dessus n'est valable que pour Flash MX. j'ai récemment upgrader un de mes projets vers Flash MX2004 et tous les objects contenus dans _global avait disparu une fois le moteur instancié. (édit: 21/1/2005)