Salut,
> Je viens de lire l'article sur l'applicationDomain, un grand merci.
> Je sais que zwetan a déjà répondu à cette question au travers d'un
> précédent post en expliquant qu'il utilise un swc, mais en dehors du
> fait qu'il faille charger le swf, quel est l'intérêt du swc sachant
> qu'il augmentera la taille du swf final ?
> Est-ce que l'intérêt se trouve dans le workflow ?
> En utilisant le même applicationDomain le swf s'utilise au final aussi
> simplement que le swc, non ?
> Bon dev à tous
>
alors dans l'ordre
le code est d'abord compilé en ABC (ActionScript ByteCode)
puis selon la cible
1) il est compilé vers un SWF
- ajout des headers propre au SWF
- ajout des symboles graphics / movieclip / etc.
et ce SWF devras etre completement chargé en mémoire poru aceder
au code
2) il est compilé vers un SWC
un SWF c'est comme un SWF, mais avec une difference de structure,
c'est come un zip
SWC
|_ library.xml
|_ library.swf
et une grosse difference qui est que on est pas obligé d'inclure
ou de loader tout le SWC piur en n'utiliser
qu'une petite partie
tu peux tres bien avoir un SWC de 50Mo mais n'utiliser en fait que
5Ko de bytecode
par rapport aux classes que tu veux utiliser dans ton SWF final
quelques ajouts, avec Flex 4, Adobe ajoutera le asdoc dans le SWC,
donc ils seront encore plus gros,
mais pareil ca ne veut pas dire que tout le SWC sera inclu dans le SWF
final, uniquement une partie ou tout le bytecode.
Au niveau du workflow
utiliser Flex Builder, Flash Develop, Eclipse+FDT,
c'est tres bien pour ecrire du code, mais c'est tres pourri pour faire
du design
donc un workflow parmis d'autres (mais qui est pas mal)
est d'utiliser
1) le Flash IDE
tu definis tes symbols, tes anims etc.
le stage reste vide, tout est dans la librairie
et tu coches par symbol
[x] exporter sur la 1ere frame
[x] exporter pour actionscript
en donnant un nom d'export
si ton appli est dans com.monappli
tu peux decider q ue le symbol mcBackground sera exporté en
com.monappli.ui.BackgroundUI
au lieu d'exporte un SWF, dans les params d'exports tu coches en
plus
[x] exporter un SWC
2) dans FB / FD / FDT etc.
tu ajoutes les SWC généré plus haut dans tes libs
et cela te permet de faire des choses comme par ex
package com.monappli.ui
{
public class background extends BackgroundUI
{
//...
}
}
les assets du SWC se comportent comme des classes meme si tu les as
pas defini dans le code mais dans le FLA.
c'est UNE maniere de faire parmis d'autres, mais perso je la trouve
tres pratique
le FLA est ouver peut-etre 1 fois ou 2 pour regenerer le SWC
et le code depuis Flex Builder peut etre compilé des centaines de fois
tout en utilisant ces jolis assets fait dans Flash
alors le SWC, il faut le considéré presque comme un SWF, mais plus
comme un "reservoir"
de classes et symbols, que l'on peut utiliser ou non
et idealement on veut separer ces symbols et classes
en general j'ai
/libs
|_ assets.swc //venant du FLA
|_ nom_de_la_lib.swc //venant de code AS compilé avec compc
si j'ai une lib "toto" et que je dois travailler dessus en meme temps
que l'appli en cours,
cad que je dois modifier le code source constamment
j'aurais plutot
/lib
|_ toto
|_ FooBar.as
/libs
|_ assets.swc
et des que la lib est stabilisee
/libs
|_ assets.swc
|_ toto.swc
et le ApplicationDomain n'a rien a voir avec tout ca :D
dans l'article posté précédemment je parle de chargement de modules
SWF externes
cad que ca, ca se passe au runtime, et ca donne plutot ce genre de
structure
monappli.swf 50K
|_ fonts.swf 20K
|_ login.swf 80K
je pourrais tres bien tout compilé dans un gros SWF (de 150K),
mais voila c'est une application dit modulaire
cad que le SWF principal monappli.swf ne veut pas embeddé les fonts ou
une font,
il veut charger une des fonts dynamiquement
par ex:
if( lang == "en" )
{
load( "en_arial.swf" ); //SWF de 50K
}
else if( lang == "jp" )
{
load( "jp_arial.swf" ); // SWF de 2Mo
}
ou autre exemple, si la page HTML contient deja une session ID, on
retrouve les infos
de login de l'utilisateur et on le met "deja loggé", et on a pas
besoin de loader "login.swf"
les explications sur l'ApplicationDomain servent principalement a
gerer ce genre de choses
par ex une font dans un SWF externe, pour pouvoir faire un
Font.registerFont() il faut absoluement
faire un "import loading", si la class se retrouve definie en
isolation on ne pourra pas la reutiliser
dans toute l'appli
idem pour un module de login, comme login.swf, la l'approche est
differente,
ce SWF est chargé en complete "isolation" et il communique avec le SWF
principal
par le biais de shared events ou de local connection,
on n'isole pas completement mais on isole suffisamment
pour qu'il n'y ait pas de collision avec certaines classes
cela permet au SWF login.swf d'utiliser pureMVC as3corelibs etc.
sans que ces classes viennent polluer la memoire de monappli.swf :D
mais en gros les "modules" ca permet de deleguer le boulot de chaque
dev sur son propre module,
et que tout puisse marcher ensemble meme si les styles de coding
different.
enfin voila, j espere que je ne rends pas tout ca inbitable ;)
zwetan
--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de
Google Groupes.
Pour transmettre des messages à ce groupe, envoyez un e-mail à
l'adresse [email protected]
Pour résilier votre abonnement à ce groupe, envoyez un e-mail à
l'adresse [email protected]
Pour afficher d'autres options, visitez ce groupe à l'adresse
http://groups.google.com/group/FCNG?hl=fr
-~----------~----~----~----~------~----~------~--~---
