I'm preparing to reorganize & refactory a Flash Builder application. The goals of the reorg are 1.) keep compile times for the part of the project I'm working on as fast as possible, 2.) keep the unrelated parts separate for code reuse. Goal #1 trumps goal #2 if there's a trade-off.
Currently, the app has assets in one project, core functionality AS3 in another project, and the MXML in a third project that links to the other two.
Would moving resources/code into swc libraries help compile time? What about compiling assets into an swf and embedding that into the main application? Any other techniques?
We had the same problem, application compile time was more than 1 minute.
Here is our solution:
There is a Core Library that contains class Core with static properties like: Core.resourceManager:IResourceManager, Core.stringManager:IStringManager, etc.
Main application project includes Core Library and provides implementation for all Core.someProp. This can be done via some hidden method like Core.setImpelentation().
There are unlimited number of Modules that use Core Library to contribute their display / logic to the application. Important:
Each Module is a separate Flash Builder project
Module link Core Library as external (it's included in Main App)
Module has XML-file that describes it, example it's name and icon in application control bar. It allows not to load all modules at start.
User should be able to choose which modules he would like to use. This will also help you in development.
You can optionally create Lib Library and include in it all classes that are common between modules and can be implemented using Core Library.
The result is incredible - you application becomes low-coupled, open/compile time decreases, APIs become more clear. Profit!
Modules are definitely the way to go here, as Maxim has described. Further to his advice, which is all solid, here's some other tips:
Extract styles out to a separate project, and compile the .css to a SWF. Load the SWF at runtime.
Structure your packages by business function first, MVC role second,
Eg: Rather than com.myapp.model.userconfig.UserOptions, use com.myapp.userconfig.model.UserOptions. Enforce that packages can only reference their siblings, or com.myapp.core.*.
This way, each package is a self contained module, which only references itself, or the core library.
Consider the Hellfire Compiler, which can farm your compilation over several CPU's in parallel
If not already, consider moving to the Flex 4 SDK, which has several compiler performance improvements, especially around compiling multiple SWC's.
Related
can any one help me that where is the SWC or run time library for the flex controls exist in the system?
Or can we provide our own library by using the controls in the dir
C:\Program Files\Adobe\flex_sdk_3.2\frameworks\projects\framework\src\mx
It is not very obvious what are you trying to ask but I'll try to guess :)
So the SWC with Flex controls is located here {Flex.SDK.root}/frameworks/libs/framework.swc and the corresponding RSLs are located here {Flex.SDK.root}/frameworks/rsls.
What about providing your own library to replace Flex controls I think it is not the right way. The best practice is not modify Flex SDK installation to have possibility to build your project on every computer with different environments (on a different developers computers or on client site).
And you should take in mind there are 4 standard ways to use code in Flash application:
Compile your code into SWF.
Use Runtime Shared Library aka RSL (which is SWF too).
Use SWZ which is signed and can be cached by Flash Player.
Use modules which are SWFs.
None of these ways doesn't suppose using Flex SDK in runtime. Flex SDK is being used only in process of building of your application.
So the best way to use some custom controls is to build them with your application using one of the ways I described above (excluding SWZ's which can be produced only by Adobe).
Just leave Flex SDK installation without changes and place classes/SWCs with custom controls in your project's classpath.
Hope this helps.
I'm developing a module based applications in Flex and I was thinking about moving all my Value Objects (VOs) into a library project and I was wondering if any thinks this is a bad idea or have any alternative suggestions.
Current Structure:
I have a project that consist of a shell application and 3 modules. The modules contain about 10 custom components in each that are dynamically loaded at run time. My problem is component A ( in module A) needs to pass data to component B (in module B). So when this happens I move the VO that component A was using to a common folder. I then pass the VO and have component B pick that up and do what ever it needs to do with it.
So what I was thinking was using an existing library project and adding all my VOs to it. This way I'll never have to move a VO from the module to a common folder so both module A and module B can access it. The basic idea is I want to be able to complete abstract any module from shell into its own widget or Air app with out depending on any other modules.
Does anyone think this is bad practice? If so, why? and do you have any alternatives?
Thanks!
Your approach makes sense and is more or less what the library projects were designed for. You can compile the SWC directly into your main application SWF or even externalize the library as a RSL. Unless you have a lot of VO's (hundreds) it will probably make more sense to compile them directly into the main SWF.
I tend to skip the whole VO system and use native objects (Object). It's not quite as self-documenting, but it is more convenient and portable. And you can easily serialize it with the JSON library. Probably doesn't at all help you with your problem though.
For a normal Flash/Flex application I would include my Unit Tests in my application project (perhaps in a tests source folder alongside my main src folder). I'd then have two application entry points: the app, and it's tests.
How are people doing this for their Flex Library Projects? You know, the kind that produces a SWC file. As far as I can tell, you can't set an executable entry-point for these projects (to run the tests).
Normally, Flash Builder only allows you to use the debugger from a Flex/AIR application, not a library project. So best thing to do here is load the library into a Flex application and write+debug tests there.
Here are step-by-step instructions to be able to test your library project, with debugging/stepping enabled:
Create a Flex Library project that you want to test + debug
Create a normal, empty Flex Application. We will write the tests in this dummy Flex Application so we can utilise the debugging features.
Set the library's build-path to the 'libs' folder of the Flex Application so it builds most recent code into a swc loaded by the Flex Application.
Optionally, set the
Flex Application to 'reference'
the library project in Project
Properties->Project References, this
ensures the library code is built first.
Write your tests in the Flex
Application
Debug and run your tests: you
should be able to step through your library
source code! Nice.
Optionally, once you're satisfied your tests are all good
copy your tests back into the
library project to keep all the library's associated code together in one project. Make sure you're not including the test classes in the actual library swc.
This is how I do it anyway.
If we assume that you need an mx:Application entry point to run the unit tests, then it would seem to make sense to generate a separate application project solely to run the tests.
Would you really want to include the unit tests in the compiled SWC anyway? (For an application this wouldn't be a problem since they're, presumably, not referenced, but for a SWC library I think they'd be compiled in if they're in the folder hierarchy somewhere)
In Flash Builder Beta 1 onwards itself, you can write and execute Flexunit tests from a library project.
You can use the IDE integration feauture of FlexUnit, and select the project, folder , class or method from the context menu and use "Execute Flex Unit Tests". This will create the application file of the required syntax, run the application and show the results in the FB. You can even select from the result and run the tests are requried.
There isn't currently a way to test a library project. You must have an application as the entry point to the tests. This would be a great feature request for Flash Builder 4.
I'm using Flexbuilder as an IDE, and I'm working on automating the process of building my application.
In the process of setting up the ant build file, I noticed that there's no way to call the project using the list of dependancies that Flex builder stores - each library or library project has to be added to the flex compiler commands manually. This creates an enormous burden on the developers to update the build scripts, and makes the build process very uncomfortably fragile.
Is there an option or third party project that addresses this? Failing that, is it possible to build using Flex builder's process via command line?
This answer might be of use.
automating component libraries
My team builds reusable libraries for other (internal) software development teams. We use FlexBuilder 3 as our development environment. Our SCM standards state that these projects must include test harnesses and a unit test runner, and (of course) we want to be able to use the debugger. For that reason, all the projects are Applications.
Our build scripts (used primarily by the CI system and for release deployment) build our actual libraries which works great. This approach is used so that FlexBuilder is not required to actually build our production artifacts (on the command line).
The problem is this - in order to have add a FlexBuilder Project to the Library Path for an Application it must be a Library Project. I have tried adding a nature to the project that we want included, but haven't gotten it to work yet. You would want to do that if you wanted to debug source files in another project.
A simple (yet annoying) work around is to include the source folder of the "library project" as a source folder in the "application project." It's annoying because it takes multiple steps to swap between a swc of the "library project" and the source folder of the project itself.
I would also suggest breaking this up into 2 projects. Have 1 library project and 1 application for the tests and the testrunner.
On a sidenote: FlexBuilder 4 will have support for running FlexUnit tests in the IDE, for both Flex applications and Flex library projects. So you won't have to maintain an application just for the sake of running the tests.
Assuming it is possible, I'd suggest adjusting your SCM standards to allow test harnesses and unit test runners to exist in other projects. Simply mandate that any library project must include a companion test project.
I don't know that this is going to make it any easier, but I would actually make the library and the testing harness seperate projects. This would allow you to source control each and would solve your problem with flexbuilder. Its not going to make it easier to work with, but it will be cleaner and the easiest to update.
I didn't totally understand the description of your situation, but if it's helpful, I'll describe how we have organized our Flex projects. The majority of our application code is contained within a SWC ("library") project. We then create two SWF ("application") projects - a "shell" application which represents the final output SWF, and a test harness FlexUnit 2 application. Both of these SWF projects reference the SWC project using a source path. Using this approach has made it trivial to enable unit testing for the application codebase in the SWC.