Flash & Flex
September 22nd, 2009 @ 11:09
In my post a few days ago, I mentioned that that Scott Delap and his team were using the Swiz MVC framework. I decided to try it out, and I have to say it looks quite promising. The Swiz tagline is “Brutally simple micro-architecture for Rich Internet Application development with Adobe Flex”, and it was actually pretty easy to set up. The framework is similar to the way Java Spring works with autowiring, so if you’re familiar with that you’ll probably like Swiz.
I’ve only read the docs and tried the demo out so far, but it’s a very interesting candidate for future Flex projects. It’s quite easy to separate the views and controllers from the business logic and using both MXML and ActionScript views seems to work fine. Swiz really gets the job done.
Seems better than PureMVC
I’ve tested the PureMVC framework earlier and kind of liked it, but developing with PureMVC gets quite repetitive and you produce quite a lot of boilerplate code. I like it better when the MVC framework easily guides you towards a proper structure, without having to do too much work to get there.
Also, there seem to be pretty good community activity in the Swiz Google Code project.
It seems like the best MVC framework candidate so far!
Flash & Flex
September 18th, 2009 @ 15:09
I came across a really interesting presentation from Scott Delap on InfoQ:
Scott Delap shares his experience creating a lobby interface for an online game using Flex&Air. He details on related technologies used, available tooling and frameworks pros&cons, remoting options, unit, functional and load testing approach used.
To sum it up, it’s a good and elaborate presentation from a Java developer’s perspective, with reflections from a online multiplayer game development project. I enjoyed the full hour of watching it! 
They’ve dealt with many of the questions we have and their conclusions are very interesting.
Presentation summary
I’ve summarized the most interesting contents of the presentation. They’re actually notes taken during the presentation, so please forgive any poor language or formatting:
- The Flex Builder WYSIWYG actually works, which isn’t common at all
- MVC in Flex is pretty much MVc, where the controller and view are sort of bundled together
- When choosing an MVC framework, Swiz turned out to be most interesting (among likes of Cairngorm, PureMVC etc). Swiz is similar to Spring with auto-wiring. Also supports Dependency Injection, Command Chains, and has MXML support even for non-views (i.e. for wiring the M:s, V:s and C:s).
Their MVC implementation:
- MXML for the views
- ActionScript for the controllers
- Remoting interfaces + specific back-end implementation
- Swiz wiring it all up
- They found no real reasons to use a “big MVC framework”, whereas Swiz did the job well enough
Remoting
Looked at several candidates, where WebORB, Hessian, XMPP, GraniteDS, Rest not weren’t considered enough for various reasons. Also evaluated BlazeDS, which doesn’t scale and has no NIO support.
Best candidate: LiveCycleDS - supports NIO, RTMP and lots of connections:
- Good for remoting Java <> Actionscript and easy to integrate
- Some Java <> ActionScript translations a bit problematic, i.e. enums and null values
- Some lack of documentation when it comes to messaging
Unit testing
- Evaluated ASUnit, FlexUnit, DpUnit/Fluint
- Chose Fluint, but could just as well have chosen FlexUnit. Unit testing Utilities, Controllers, Remoting Services with Mocks
Functional testing
- FlexMonkey not working properly with AIR and had a bit of lag
- Wrote a stripped-down version of Selenium
Load testing
Currently no good way of performing load testing.
- Hard to simulate 1000:s of users
- No really good tool for load testing at the moment
Final thoughts on Flex
- MXML works as advertised
- Easy to do complex things
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
Flash & Flex
March 6th, 2009 @ 11:03
Objective
Testing the PureMVC framework.
Evaluation
I decided to test using the PureMVC framework in a small application in order to find its pros and cons.
As I had tested setting up the framework once before (in another project), it wasn’t really a big deal installing it and creating my first classes. Also, after having spent a few hours reading the PureMVC documentation and best practices, I already had knowledge on how the system worked.
Result
After completing the application, I’ve found both pros and cons with the implementation of PureMVC.
(Please note that I haven’t taken other pros/cons to consideration here, such as how often the framework is updated, community size etc.)
Pros
- A clear structure for Models, Views and Controllers – the roles of each part is quite easy to understand and make use of.
- Good use of Controller part of MVC, which usually is difficult to put in the AS equation. In PureMVC, the Controller is a “Command” instructing the application on what to do next (i.e. to register Proxies/Mediators).
- Good and clear separation of “true” View and Model via Proxy and Mediator – makes it easier to let the View actually “be a View” and Model “be a Model”. The View component (i.e. an actual MovieClip) is manipulated through the Mediator and the Model (i.e. a data object, such as a Player) is manipulated through a Proxy. This ensures that no logic is misplaced in the View component.
- Nice being able to access Proxies, Mediators etc through the ApplicationFacade from wherever. Allows for Commands to be quite complicated if needed.
Cons
- All Mediators, Proxies and Commands are registered using a unique key. Hence, there are some difficulties keeping track of Mediators/Views (“M-V”) that are unique for the Proxy’s data object, i.e. the M-V of a certain “Player” with a certain “id”. Perhaps M-V:s should only be implemented for functionality that will only require a single instance of its type?
- Could be troublesome to keep track of the dependencies etc in the notification system, although the references can quite easily be searched using an IDE. This is probably an issue no matter which system being used.
Other observations (not necessarily to be considered as either pros or cons)’
- The PureMVC “pattern” needs to be implemented all the way, meaning that the view (component) cannot contain any functionality to affect the world outside of it. A mediator’s “view component” must be completely isolated.
- Setting up a new class requires some manual labor (as some classes needs to be extended/interfaces implemented), i.e. specifying which events to listen to and how it affects the class
What do I need to know to get started?
It takes a little effort to learn the system and understand what its parts do; i.e. what a Mediator is and how it correlates to the actual View. But once you understand the system, it’s really easy to create new classes for your application.
A few vital things that need to be understood before using PureMVC (I’ll try to sum it up, but the official docs are recommended):
- What are Notifications? All Mediators, Proxies and Commands listen to notifications specified by the user. If a certain Mediator should display a message at a certain time, it will listen for a notification of that type.
- What the Mediator is and why it’s being used: it’s basically a layer to the actual View (MovieClip), handling all functionality related to the other parts of the application (i.e. outside of the View)
- What the Proxy is and why it’s being used: works in the same way as a Mediator, but in a more simpler way. Manipulates the “true” model object, which could be a domain object such as a “Player” or “Table” in a card game application.
- Where is the Controller? The controller is implemented as a Command, meaning that it’s invoked when a certain notification is sent. Once invoked, it has no function until the notification is sent again.
Conclusion
In my point of view, PureMVC is a good framework to use for MVC applications. It can get a bit complex with boilerplate code, though.
References