I'd like to be able to understand how to develop a Flex application such that I could provide implementation classes at runtime. In the Java world I'd specify interfaces in an JAR (e.g. myapp-api.jar), the implementation in a separate JAR (e.g. myapp-impl.jar) and package these along with other resources in the application WAR (e.g. myapp.war). Within the code of the application I would instantiate the implementation classes dynamically.
Is this approach possible in Flex? I'm aware that I can instantiate classes dynamically so that's a good start. I'm a bit confused by modules, RSLs and SWCs though.
I was hoping to create a SWF application that had references to an interfaces SWC and an implementation SWC. The idea is that if I need to tweak the application for a specific customer then I could create a new implementation SWC and not have to modify the SWF or interface SWC.
Any ideas?
This is a bit harder to do in flash/flex than it is in java, or at least it is a bit more obscure if you are coming from a java background). I have a couple of pointers for you.
You only have to use RSLs if you really want to have separate libraries of classes at runtime, and especially if you think this library will be used across several projects that the same set of people will be using. (They are mainly intended to decrease download/startup time)
You can also divide your app in several parts yourself - in that case you need to make sure that you don't pack the same info twice - this can be done by generating a linkreport on the first compiled swf and excluding these classes from the second compile. This is how modules work in flex.
SWCs are mainly used as a compile-time library (they are basically a zip containing a swf and a metadata xml file that describes its contents).
If you want to have a separate set of interfaces in a library you could generate a swc with the interfaces and compile another swc with the implementation, you should exclude the interfaces when compiling the implementation classes if you want to avoid having duplicate class/interface definitions. If you compile your final app when linking both the interface and implementation SWCs without excluding the classes you can just use your single final SWF to run the app - if you want to keep it really separate you should look into modules (or plain loading swfs if you are creating a pure actionscript project).
I did use SWCs myself as described above, and am now looking into RSLs and Modules myself for our curren project.
Related
I'd like to know what are the best practices when creanting a complex and big flex modular application? particularly concercing internationalization, performance, remoting(service), skinning, caching, logging.
How to use theses common resources?
Imagine that many developers will work on the same project, but on different 'small' modules each, and they don't have to know how the entire application works. So every developer will create and compile his/her module (swf), and I'll just have to put these swf in their appropriate folders.
What do you think about this approach:
create a common library : myAppLibrary, which manage languages, services, caching, logging, debuging.. For example this library can have these functions : translate(str:String):String, callAmfService(class:String,methode:string,...params), loadCache(cacheKey:String):Object, etc
require that every module(developer) should use this library when handling languages, services etc. Eg within a module, a developper can do : langSingleton::getInstance()->translate('somestring') for example
make modules communicate by events
(sorry if my english's not clear)
Thanks
I'm working on a pretty big application for Flex/Air. We are using GraniteDS and Tide to interact with the model from our Java EE server.
I've been reading about modularization and Modules in Flex. The application has already been built, and I'm figuring a way out to re-design some classes and parts. From what I've read so far, I understand a Module is a different swf which can be dynamically load. Most of the tutorials/documentation are oriented to Flash "programmers" who are using Flex or Air instead of real developers, so that makes online resources harder to get.
What I can't understand - yet - is how to encapsulate ActionScript classes or MXML views under this module.
I've separated some of the code into libraries. For example, the generated code from Granite is in a "server" library. But I would like to separate parts of the logic with its Moderators, Controllers and Views. Are modules the way to go? Is there a "modules for dummies" or "head first Flex Modules for programmers" like tutorial in order to get a better perspective in order to build my architecture? When to choose libraries and when to choose modules?
I'm using Flex 3.5, and a migration to Flex 4 is way far into the future, so no Flex 4 answers please, thanks!
Modules are the answer for encapsulating UI into different sections that do not depend on each other. Think of them like applications inside of applications.
If you want to encapsulate "code", meaning non-ui actionscript, then you really just want classes and packages of classes. You could also package that code into a swc, which is just a compiled version of that code that you can include in multiple projects (I think this is what you meant by libraries).
You wouldn't want to create a module just to contain non-ui code. You wouldn't want to use modules for separating out the model/view/controller in your application.
If you have part of your application, that for the most part runs completely on its own, with no real dependencies on the rest of the application except for maybe a little bit of information passed in, then it makes sense for modules.
Where we use modules mostly is for an application that has different sections to it where you are only working in one section at a time. There is no need for the other sections to be taking up resources, so we have the different sections in modules and load/unload them as necessary.
Does that help?
Edit in reply to the comment below:
By libraries I meant Flex Library
Projects, where you encapsulate
classses and use the swc. Can you have
these libraries inside a Flex Project?
(I use a separate Library Project for
each new library).
Yes, you can use these swc's (Libraries of code) inside of your flex projects. Just drop the swc in the lib directory in your flex/flash builder project and the code is automatically added to your classpath. Just make sure that everything that the code inside a single swc needs is inside that swc. Don't make a swc rely on another swc to function.
I have just started looking into using Modules in Flex and would like to know how you all go about developing them. I understand how to use them (load, unload, application domains, shared classes, etc.), but I'm wondering what a good workflow is in creating them and using them in multiple applications.
If I were building reusable application components (text editor, image cropper, compass, whatever), and I wanted to reuse them in many different applications, it seems like I would:
1) Create an Application specifically for one of those modules
2) Create a Module inside that Application
3) Develop the Module by itself, make it work right
4) Link shared libraries to it somehow (like library projects I would use between all of the modules)
5) ... then I'm unclear what's next. I now have lets say 10 Module/Applications, and I want to start mashing them together into usable applications. What's the best way to do this? I would like to not have to copy-paste code and swfs, using something like git submodules if an equivalent is possible.
Thanks so much
I think you're looking for SWC files.
I am planning on a Flex project that involves incorporation of a lot of features.
Each 'feature' can be a component / module.
Which is preferred and what is the difference between a module and a component?
Thanks
The short answer is that it depends.
If you going to use all, or most, of your components during regular execution of the application - components would be alright.
By the sounds of things though, modules might be the better bet for your project.
Modules allow you to group components into external libraries (RSLs). These libraries can be embedded into your application (through project settings) or can be loaded dynamically at runtime (as separate files).
Modules would give you some benefits
Only loading the libraries needed (as needed) instead of all modules everytime.
Load only core modules initially to speed up the initial load time.
Changes to a component do not require you to recompile the application/
Find out more about creating modules here.
I am trying to create a large flex project. This Project consists of a CORE application, and other sub-applications.
The CORE application should contain information that will be shared by all other projects (e.g., link to database, data manager which loads data from the database, application information like height width colors fonts... etc.).
The sub-applications each has a certain task. Each sub-application is a large project by itself so I don't think its a good idea to put all code inside one HUGE project.
The CORE project should run the main application, and through a navigation menu, I should be able to click and run other sub-applications.
Is there a way to created the CORE application to reference those sub-applications so that I can run them inside of the CORE. At the same time, those sub-applications should reference the CORE applications to get the NetConnection to the database and other important information that they might share?
What is the best way to structure this project?
Thanks,
There's two factors to consider.
Where does the code live
Where does the compiled output of that code live.
It likely is a good idea to have all of the source code live in a single code tree. It's way easier to maintain like that. You could put each sub-application in a separate AS3 package.
It's also likely a good idea to separate the compiled output of that code. Make your core application the main flex application, and then make each sub-application a Flex module. The core app can load modules and manipulate them like any other AS3 based class. A great thing about this, is during debug time you can choose to only build the limited set of modules that you care about at the time.
I would highly suggest building your releases through some kind of automated ANT build script and not through Flex Builder.
We have one project that exceeds 150k lines of code that is managed exactly like this. That's not huge in terms of software-engineering, but it's pretty big in the Flex world.
Your best bet would be to put the CORE stuff you're suggesting into a library project. Keep the front end of the application in a Flex Application Project, but all of the data and methods that need to be shared would be easily available to the main application and all of the other modules or applications.
Then in the project settings for your main app and the other applications, you can link to the library project.
If you're planning on using a framework you can also look into the PureMVC Multicore library. It's a bit more complicated than the solution I provided above, but is built specifically to allow the sharing of data and notifications between separate applications.
It sounds like you want to use Flex modules to keep your sub-applications self-contained but still able to interact with the core application.
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
This will allow you to keep your core application SWF fairly small and load the subapplications on demand.
Typically modules are stored in the same project as the main application but each app / module is compiled into a separate SWF either by Flex Builder or an automated build tool such as Ant or Maven.