Showing posts with label flex. Show all posts
Showing posts with label flex. Show all posts

Wednesday, August 5, 2009

Flex and Pure MVC

I learned PureMVC for Flex about a month ago, and was able to successfully migrate all of my Flex projects at work to this new framework. Of course, these projects are relatively small (appx 5000 lines of code at best) but it was the best move I could have made.

Though PureMVC doesn't necessarily guarantee good design and separation of concerns in a project, it certainly provides a nicely decoupled way of utilizing the MVC design scheme.

PureMVC uses what's called a Facade to act as a broker for forwarding notifications from various components. View components (MXML and the ActionScript needed to drive them) are provided to "Mediators" which communicate via the Facade. These mediators translate any events from the UI (e.g. users clicking buttons to load information from a server) into "notifications" which are sent via the Facade to the respective Controller objects.

These Controller objects are known as "Commands". Commands receive the notification from the Facade (and any data passed from the View components) and then use "Proxies" to request data and perform the majority of the business logic for the application.

Sound complicated? It's really not. The typical project may be organized like this:

src
|- controller
|- model
|_ view

Under the "controller" directory, Commands are kept which receive notifications. These commands invoke "Proxies" which are stored in the "model" directory. These proxies request information from remote objects (e.g. servers) and relay data back to the appropriate location. The "view" folder contains two different types of objects: view components and mediators. The view components are simply the user-visible forms and controls in which the user interacts. These have absolutely no connection to any PureMVC components; rather, they are passed (at runtime) to a "Mediator". The mediator listens for events from the view components and then relays the event to the Facade as a notification.

Frankly, it sounds a lot more complicated than it is. Future posts should have some examples for how to assemble a simple User-form in PureMVC

Friday, June 12, 2009

Dependency Injection and Flex

So, a quick note on the progress I've made with Flex. First of all, I wanted a tool to highlight text. So...I spent 3 weeks working through tutorials and examples from some brilliant coders who have already paved this way, worked with several different libraries, and finally found that all my work was for naught; enter, FlexLib. It not only had a great highlighting class, but also contained some moveable Panels, and a nice extensible Tab Navigator...sigh..all that work down the drain.

Anyway, I've heard about Dependency Injections a lot lately, and I finally decided to research what it's about. Wow, I never realized how simple a concept it would be. Having been exposed to different design patterns like Factory Method, this was extremely easy to assimilate.

Dependency Injection works very well with Flex interfaces, and particularly well with Factories. If I have an object A which depends on object B, I could have A instantiate B and maintain a reference to it. Unfortunately, this creates a dependency within A upon B:

private var bInstance:B;
...
bInstance = new B();
bInstance.foo();


In this case, A has a definite dependency upon B's implementation. If B changes 'foo()' to anything else, A will break.

We can partially solve this via a interface, in which A and B agree on B's required methods. In this case, B utilizes an interface, BI, which instructs B to always implement 'foo()'. Thus, A can access B via its instance:

private var bInstance:BI;
...
bInstance = new B();
bInstance.foo(); //guaranteed since bInstance is an instance of type BI


But we still have a problem: A is still relying on the base class of B. What if we wanted to break B into different objects, and 'B' was no longer a valid name? Moreover, what if we moved B to a different library? Enter a factory.

Rather than A creating B, even via its interface, what if the code calling A passed in a reference to B, via its interface? For this, we'll add two new classes. 'Factory' has a 'createBI' function that returns a reference to B via its interface, BI. FooBar is a class which creates A. In this class, the code to create A might look something like this:

a = new A(Factory.createBI());


Whereas the constructor for A might look like this:

private bInst:BI;
public function A(bInst:BI):void {
  this.bInst = bInst;
}


From this point, we've broken the dependency of A to B, and created a new dependency from A to BI. This is a better design and is more extensible: should we need to have different variations of B, as long as they implement the BI interface, A can utilize them.

What's more, 'FooBar' injected the dependencies into A.

That's all there is to it.

Now...my question is...how far can you take this??

Saturday, April 4, 2009

Flex, Emacs, Linux, and Irony

I don't like Adobe. Their software is overpriced, bloated, and often difficult to for me to use. I wouldn't be able to derive $999 of worth from Photoshop, though there are pieces in it I would enjoy working with. Flash has made a lot of bad websites worse, while helping the Browser community ignore some of their past glaring inadequacies in adhering to standardization.

This said, I love working with Flex.

This also said, I refuse to pay for Flex Builder. Though it's not a bad IDE (hey, it's built on Eclipse, my personal favorite), it has a few glaring flaws which I won't go into (for those curious, they lie mostly in the debugger and profiler). I also don't like how little support there is for Linux. I spend 95% of my time at home working in Linux, and I don't particularly appreciate their dumbed-down version of the IDE. It's lacking many of the features I do enjoy (e.g. their WYSIWYG for rapid prototyping), while making certain tasks harder. It took me several hours to get a project assembled, after which I still couldn't create anything but .as files (it kept complaining about the project association).

So, I decided to see if I could create a customized Emacs environment for Flex in Linux. I haven't been too worried about certain features (e.g. debugging, file browsing, and intense code-completion). My primary focus is on syntax-highlighting, template generation, and easy compilation. Obviously, I'm keeping my expectations low for now. Hey, it's either this or log into Windows and use FlashDevelop which is really good, but not good enough to log into Windows.

Anyway, I found two great .el files for integration with Emacs, providing some level of syntax-highlighting and code-completion. Both can be found here: EmacsWiki. The two files are as follows:
1. actionscript-mode: provides a custom ActionScript mode (as it says)
2. nxml-mode: a bundle of files which provide extensive XML support (including MXML)

I was also able to integrate a third .el file which provides customizable templates using hotkey-esque strings: snippet.el.

All of these are searchable on the Emacs Wiki.

Anyway, I got these libraries integrated into Emacs (I also setup ECB, but I haven't used it much yet) and used this great tutorial for creating a "Makefile" for a project: . After this, the coding was pretty easy.

I attached a few screenshots for the basic view of the Bible verse memorization tool I'm developing. It's rudimentary at best, but this mock-up should show a decent view.


This first shot is a simple login screen:


The second is the main GUI with a left-side Accordion control for displaying verse references associated with different Leitner piles (I call them "buckets").


Interestingly, I wrote a similar GUI using PyQT4, which took me about 3 days. The Flex GUI shown in the screenshots took about 20 minutes. I wrote it while watching a movie on TV with my wife, and I bet her I could have it pounded out before a commercial break.

Anyway, I have the data-retrieval code written in Python. I'd like to use the ESV Web Service site as the data-source. I haven't heard back from them on licensing. We'll see how that goes.

So, here's the irony. As I mentioned before, I'm terrible at memorizing verses. Hence, I'm writing this app. Unfortunately, the application is taking more of my time away from memorizing verses...

Go figure...

Sunday, March 8, 2009

Flex and RIA development

I had a project at work to complete. Our automated testing infrastructure has aged beyond the point of usability, and no money has existed for upgrading to a more recent version, or investing in a different system for automated and manual test deployment, tracking, and maintaining.

One of my coworkers began (several years ago) piecing together a web-based automation utility which would allow us to quickly configure and execute test servers with automated tests. The solution was, conceptually, a combination of Javascript, CSS, and Ajax, in which users could add machines to a table, drag&drop test configurations to each machine, edit the test configurations (e.g. modify the command-line parameters passed to each test), and execute the overall config by sending it to the test automation system as a single CSV string.

His work lasted about 3 months, and resulted in the drag&drop interface.

Shortly after this, another coworker extended upon this work by adding the test config storage and retrieval via Ajax. Users could [in theory] add tests to each machine, edit their respective parameters, and execute said tests. They could also quickly create test configurations which would map directly to their respective automated tests in the version control repository.

The result was pretty good, but fell short in several ways: Ajax calls only worked 70% of the time, resulting in failures to execute tests, save configurations, and retrieve various pieces of information. Each test config was stored as a Javascript file on the web server, which required users to understand Javascript syntax if they wanted to manually add or edit existing configs. It also refused to work in IE.

His work lasted several months as well before he moved on to bigger and better things. I inherited it and took on the work to make it work more consistently with our test infrastructure. This lasted for about 3 months on the system before I decided to investigate other solutions.

Enter Flex.

The original interface put together was quite sound: dragging and dropping test configs to various machines is a great idea, though difficult to implement. I wanted to keep the use model of the system, but move away from pure Javascript.

After hearing some buzz regarding Flex around the office, I decided to take a look and see if it could offer a better solution.

Frankly, I was amazed. Within 3 weeks of starting, and without any prior exposure to Flex and ActionScript, I had completely reproduced all interface functionality, and even added several extensions. Rather than relying on Javascript for test configurations, I was able to introduce XML (a more logical choice, in my opinion) for configuration storage and retrieval. Relying on the Flash player resolved the issues between IE and Firefox (and other browsers which support the issues with storing and retrieving information from the web server.

In short, Flex is a fantastic solution for developing "Rich Internet Applications." The presence of a standardized API (*cough -- javascript!*) and a full-fledged object-oriented language quickly and easily resolved all issues I had with prior implementations.

In essence, though I'm impressed with the usability and functionality of Javascript and CSS, for web apps I'm likely going to stick with Flex and potentially Cappuccino if it's as cool as it looks.