The best way to go is to use LocalConnection. It allows you to call methods from a seperate SWF without having to go through Javascript or a server.
Tip: if you're going to be sending arguments that are greater than about 20KB in size, you will want to split them up in two or more calls. In my experience LocalConnection calls have a limit of around that size for data.
These apply to Flex 2.0.1 with any version of Cairngorm. Since people’s programming background varies in Flex, these are not facts, just my opinions based on my experiences using ARP & Cairngorm for over 2 years. Furthermore, there are alternatives to Cairngorm, I just cannot try them as much as I like. Now that I’m doing product work, I can’t just “try this framework on this new project”. I live in the same code base longer supporting existing clients, and can’t do dramatic re-factoring without getting fired.
1. If Cairngorm looks complicated, don’t worry, it is, and you’re not alone
“Bunch of code on _root vs. all of these classes and conventions? This’ll take forever!”. It takes getting used to. I felt “comfortable with Cairngorm” on my 4th project with it. To this day, I still mod it though, and try different things. As more people come into Flex, there are more cool ideas and techniques floating around.
2. If it feels like it’s taking a long time just to do something in Cairngorm, it does.
“OMFG… 3 classes just to execute what would take me 1 line in Flash? Lamesauce!”. Code gen can help here, at least at the beginning of the project.
3. Only Commands set data on the Model; you can break this, just don’t if you can help it.
In Model View Controller, only the Controller sets data on the Model. In this case, the Commands are the Controller (usually), and as such, setting ModelLocator data is their job, and their job alone. If data is getting f’d up, you immediately know it’s in the Command. You never have to question “who’s setting my data, where, and when?”.
4. Delegates make the server call and parse the data (sometimes in a Factory)
This has only happened once in my career: I was hitting PHP for the back-end, parsing XML, and in the middle of the project, we switched to OpenAMF and Java where I had to parse objects. Using Delegates means you only have to re-code your Delegates, not the rest of your app. The Commands still get the same data.
The only reason I use Factories is because A) parsing can be a lot of code and you don’t want to make your Delegates look more complicated than they are and B) you can share parsing routines easily in the same Factory class.
5. If you see a Command parsing data, it’s coded wrong.
Parsing is differently from filtering, modifying, and assembling. IE, making Value Objects from XML should be done in the Delegate, not the Command. Making associations between ArrayCollections, injecting default values are both ok. Remember, the key here is if the Command is touching raw server data, you’re either not using Delegates correctly, or have AMFPHP/FDS/WebOrb working correctly, hehe.
6. There are 3 ways to use Commands & Delegates. I prefer A because it’s consistent, leads to short class files, and is very explicit.
A) For every use case, you make 1 Command and 1 Event. This can sometimes also mean 1 Delegate. (ie, LoginEvent, LoginCommand, LoginDelegate)
B) For every use case that’s related, you can consolidate them into a package path. So, Login, ChangePassword, and ForgotPassword would all be in the same class. You’d then use constants to determine which one to run. (ie, LoginEvent has LOGIN, CHANGE_PASSWORD, and FORGOT_PASSWORD as String constants. Your LoginCommand has a switch statement which determines which one to run. Your LoginDelegate has 3 methods; login, changePassword, and forgotPassword that your Command can use.
C) Variances on B. Maybe 1 Event and 1 Command, but multiple Delegates. This is not a cop-out bullet item, rather, I’ve seem many derivatives that can all be traced back to “B with mods”.
7. ViewLocators are considered bad practice.
That said, there are developers who still love and use them. The use case, however, is valid: Having a View “know” when something in a Command has occurred. I use callbacks, some set data on the Model to trigger callbacks on the Views (maybe via a setter function), and some use addEventListener in tandem with CairngormEventDispatcher.
8. ViewHelpers are considered bad practice.
That said, there are developers who love the idea of “code behind”. I’ve yet to see a consistent theme on the blogs and mailing lists. There are 2 reasons that are common:
A) They don’t like mixing ActionScript & MXML.
B) They want to separate their View’s from their “View controller code”
Some use the script tag to point to an external file (lame in my opinion; you have to define your controls as member variables and you end up with twice as many View classes). Some use inheritance where you extend your GUI MXML. Others take the reverse, and have the GUI MXML extend the ActionScript ViewHelper. Some will even take the Composition over extending MovieClip approach I’ve seen a lot of coders do in Flash. Instead of their ViewHelper extending a view class, it’ll instead take a UIComponent as a parameter, say in an init method, and use that UIComponent via composition.
To me, you’ll get over it as you get more comfortable with Flex. Code your components in MXML with code up top in a script tag. If you really need efficiency, or start doing some really low-level, abstract type classes, then you can start coding your components in ActionScript. If you want to get stuff done today, use MXML.
9. Don’t use flash.net.Responder, use mx.rpc.Responder instead.
Yes, it’s frustrating because Flex 2.0.1 doesn’t give you the source, but in my opinion, Flex Builder doesn’t handle same-named classes very well. Just go with what Flex uses, and call it a day. If someone requires flash.net.Responder, code a wrapper to bring him into Flex land. “Sir… you need a tie to get into this restaurant. We have one in the back, one moment.”
10.Try not to have View’s use CairngormEventDispatcher (or Events that extend CairngormEvent use event.disaptch()).
Instead, have those deeply nested views dispatch events. Either bubble them up so a master controller View can then fire off Cairngorm events, or bucket-brigade them up. The most common scenario is itemRenderers that are a custom class in DataGrids.
You:
- make the itemRenderer class. If you have something in it that is clickable, dispatch a custom click event. Make it bubble.
- extend the DataGrid that uses your custom itemRenderer, and put the custom event in the metadata up top. Otherwise, the class that houses the DataGrid will only be allowed to subscribe to the event via MXML, only ActionScript. If you use MXML, it’ll fail to compile because the DataGrid doesn’t have that event in it’s source code.
It may feel cool at first to have a LoginForm for example dispatch the LoginEvent, but if you need to use it for a different purpose elsewhere, you’re screwed; it’s hard-coded to use a specific CairngormEvent. This applies to all components. Encapsulate your components and do your best to do what BT does: “bubble it up”.
How do I start using PureMVC? Short answer: Just think in (Pure)MVC! As its named says, PureMVC based on the classic Model-View-Controller design meta-pattern. Using the Facade-pattern you don’t instantiate the core actors directly, but every member of PureMVC has its own and clear defined role:
- Proxies = Model
- Mediator and its ViewComponents = View
- Commands = Controller
A View Component might be a standard UI component (e.g. DataGrid) or a custom component (e.g. a world within a game) or whatever. Don’t use its public methods directly. In order to change its state or behavior create an API.
One of the advantage of PureMVC is to be neutral to the technologies being used. An example: I’ve built a “pure” Flash application based on PureMVC without using the Flex Framework. The same app will be ported to an AIR application for using AIR’s great File system API. The View Components have to be changed using the Flex Framework, but not the Mediators or any other actors of PureMVC.
To coordinate more than one View Component closely, use one Mediator only. In other words: Not all Views need a Mediator. For example: Assume a ApplicationControlBar containing a TextInput , and a Button or something else. Then create just one Mediator for theApplicationControlBar called ApplicationControlBarMediator and refer to the missing components casted as a second, third, etc. View Component.
What happens if you don’t want to use multiple View Components within a Mediator? In order to handle user interactions with multiple View Components let’s bubble Events from the nested children of a View Component up.
For example: Clicking any Button within a View Component will fired up a custom Event which the Mediator is listen to. So the Mediator don’t have to know about the existing Button or about any other child of its View Component, just about the custom Event bubbled up.
Notifications are the “Events” of PureMVC. For communicating between the three tiers Model, View and Controller use Notifications for the following scenarios as often as possible:
(communication from -> to)
- Mediator -> Proxy (via mapped Commands)
- Proxy -> Mediator
- Proxy -> Command
- Commands -> Mediator
Even if it’s possible to retrieve a Proxy from a Mediator, don’t change the Proxy from a Mediator directly rather than sending a Notification using a mapped Command. It’s a bad practice to change a Proxy (Model) from a Mediator (View) directly without using a Command (Controller).
Commands are doing the job at the Controller side: Retrieving and interacting Proxies, communicating with Mediators or executing other Commands. Even if a Command used only once or it has only two lines of code, use it as often as possible. To execute a Command once again anywhere or anytime within your application, you have to send just a Notification. In the future it’s easy to enlarge the Command with more complex actions. And – that’s very important – you always know, who the actor for changing the Proxy (Model) is.
Question: Have you had to execute more than one Command in a particular order? Use MacroCommands to execute multiple SubCommands (which means “simple” Commands) sequentially.
To send and receive data between the application tier use Proxies called Remote Proxies. That’s not a special kind of a PureMVC Proxy, just a location based on a Proxy to organize the server calls such asHTTPServices, RemoteObjects or whatever.
For example: To call a server-side RemoteObject to login a user create Proxy called LoginProxy. The LoginProxy does all the job to communicate with the server-side, which means sending and receiving data. Whenever you’ll change the server-side implementation for the LoginProcess, you’ll have to change one location within your application only – the LoginProxy.
In some cases you don’t use a Mediator and its View Components anymore. Then remove the Mediator usingfacade.removeMediator(MyMediator.NAME); in conjunction with a self created destroy() method to remove the ViewComponent including all listeners, timer, references, etc. for a successful garbage collection.
The place to store data within the Model are the Proxies – that’s right. The View Components have no need to know the Facade and the rest of the PureMVC application – that’s right, too. This means that the View Component has no access to the Model data directly.
To avoid this issue store within the View Component a reference to the data using Value Objects (VO’s). The VO’s are not a core actor of PureMVC and in conjunction with the Data Binding feature of Flex are a powerful way to react changes in the Model data without breaking rules.
Cliff Hall has done an awesome job: You’ll find not only excellent documentations about the “Framework Overview“, “Best Practices” and a “Conceptual Diagram“, also a very, very, very helpfulCourseware. Check it out!
Adobe is active in Open Source projects. The following are a number of our contributions and commitments to open source.
BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe® Flex™ and Adobe AIR™ applications for more responsive rich Internet application (RIA) experiences. Previously available only as part of Adobe LiveCycle® Data Services ES, Adobe is announcing its plans to contribute the proven BlazeDS technologies to the community under the LGPL v3. BlazeDS gives the rapidly growing Adobe developer community free access to the powerful remoting and messaging technologies developed by Adobe.
Home | Downloads | Source | Documentation
Cairngorm is the lightweight micro-architecture for rich Internet applications built in Flex or AIR. A collaboration of recognized design patterns, Cairngorm exemplifies and encourages best-practices for RIA development advocated by Adobe Consulting, encourages best-practice leverage of the underlying Flex framework, while making it easier for medium to large teams of software engineers deliver medium to large scale, mission-critical rich Internet applications. Previously available only as Adobe Consulting releases through labs.adobe.com, Cairngorm is now evolving towards a project that will invite community leaders and enterprise adopters to partner with Adobe Consulting in the ongoing development of Cairngorm.
Home | Downloads | Source | Documentation
Adobe's Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. With XMP, desktop applications and back-end publishing systems gain a common method for capturing, sharing, and leveraging this valuable metadata—opening the door for more efficient job processing, workflow automation, and rights management, among many other possibilities. The XMP SDK is available as open source.
The Flash Ajax Video (FAVideo) component is a small, open source Flash component that you can use to provide video playback within an Ajax application. It exposes all of the formatting and video playback controls necessary to build a video player customized entirely using HTML and Javascript.
Adobe® Flex™ is a cross platform, open source framework for creating rich Internet applications that run identically in all major browsers and operating systems. The Adobe® Flex™ SDK is the foundation of Flex, providing the core Flex compilers, component library and debugger. Using only the free SDK and an IDE of your choice, you can build and deploy rich Flex applications.
Home | Downloads | Source | Documentation
FlexUnit is a unit testing framework for Flex and ActionScript 3.0 applications and libraries. It mimics the functionality of JUnit, a Java unit testing framework, and comes with a graphical test runner.
Generic Image Library (GIL) is a C++ generic library which allows for writing generic imaging algorithms with performance comparable to hand-writing for a particular image type.
Home | Downloads | Documentation
Open Source Media Framework enables developers to easily assemble pluggable components to create high-quality, full-featured playback experiences. The open aspect of the framework enables collaborative development for web video monetization, with lower costs and faster turnaround.
Home | Downloads | Source | Documentation
The Adobe Media Gallery (AMG) is a Flash web photo and video gallery whose appearance and behavior can be customized via XML files.
Home
| Downloads | Source | Documentation
The Adobe Source Libraries (ASL) are a collection of C++ libraries building foundation technology to allow the construction of commercial applications by assembling generic algorithms through declarative descriptions. Updates monthly.
Home | Downloads | Source | Documentation
The Tamarin project, which is based on code contributed from Adobe, is designed to implement an open engine for ActionScript. Tamarin will be used by Mozilla within the next generation of SpiderMonkey, the core JavaScript engine embedded in Firefox®, Mozilla's free Web browser, as well as within the ActionScript™ Virtual Machine within Adobe® Flash® Player. Developers interested in working on Tamarin code in the Mozilla CVS repository via the project page located at www.mozilla.org/projects/tamarin/. Contributions to the code will be managed by a governing body of developers from both Adobe and Mozilla.
The Text Layout Framework is an extensible ActionScript library, built on the new text engine in Adobe Flash Player 10 and Adobe AIR 1.5, which delivers advanced, easy-to-integrate typographic and text layout features for rich, sophisticated and innovative typography on the web. The framework is designed to be used with Adobe Flex or Adobe Flash Professional and is included in Flex 4, code named "Gumbo". Developers can use or extend existing components, or use the framework to create their own text components.
The WebKit library is used to render HTML and execute JavaScript in Adobe® AIR™. Adobe AIR allows web developers to deploy rich Internet applications on the desktop. Our plan is to contribute our changes back to the WebKit community in the near future. We are currently working on getting the code smoothly integrated into the WebKit source tree. We hope to make our contributions included in the WebKit open source project soon.
