This morning I wrote a quick API which allows you to easily invoke a PHP script from Flex 2, run a query on a MySQL database for authentication, and pass the results of the query back to the Flex client. The API consists of a simple login value object and a QueryService that calls an accompanying PHP script. The PHP script then runs a query based on the login value object passed in the query string as name value pairs.

The AS3 PHP LoginService API is intended to simply serve as a base class only. It is to be used as a starting point from which you can create a real world application based on sub-classing the QueryService to apply an MD5 encryption algorithm and so forth.

You can check out the example, accompanying ASDoc and source code as well as a Cairngorm 2.0 implementation which I created.

The greatest thing about design patterns is that they are typically not much more than an efficient, structured way of doing things that most of us have already been doing for a long time. Design Patterns allow us to simplify common design problems into standard, common named solutions. By implementing common design patterns and best practices we can keep our applications consistant without re-inventing the wheel everytime. They allow us to solve the same problems over and over again in the same way. Design patterns also allow us to write code that is common amongst other developers. This is helpful as it allows other developers who are familiar with these patterns to easily and intuitively work with our code, and vice-versa.

Every Software Developer iterates over objects on a regular basis. That is, every software developer has the need to loop thru an array or traverse an object at some point during the development of an application. This is obviously a basic part of programming so we usually don’t give it much thought. However, once in while it is good to reflect upon the things that have become routine to determine if there is a common solution out there. We often run into situations where we create an API that consists of a collection of objects that a client may want to iterate over. In order to provide the required functionality we have to define an interface in which the client can iterate over our collection without exposing the collections underlying implementation. This is where the Iterator Pattern comes in handy. Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation. Iterators are intended to remove traversal responsibility out of the aggregate object.

I have created an AS3 Iterator API which consists of an interface (IIterator) that defines the methods which implement the Iterator Pattern. The IIterator interface is implemented by an internal base class (Iterator) which is sub classed by concrete iterator implementations (ArrayIterator, ArrayCollectionIterator and ObjectIterator). I have also provided an IteratorFactory which handles instantiating Iterator sub-classes so that they may be referenced by the same iterator instance.

You can view the example and ASDoc as well as download the swc for the AS3 Iterator API.

After numerous requests I finally found the time to update my AS3 Custom Tween API to version 0.9.3.

In case you are not familiar with the Tween API it is a simple API which enables any object on the display list to have a tween effect applied to a property of the object. You can view the the original Tween API post here.

Version 0.9.3 has had the following additions implemented:

Most Flex and Flash developers immediately think “MVC” when they here the term “Design Patterns”, and this makes perfect sense considering most of us have either been using MVC for a long time or we have construed our own variations of it’s implementation. What ever the case it is important to understand the basic concepts and implementation of Model-View-Controller.

Model-View-Controller falls under the category of what is known as a compound pattern, that is, a combination of several different Design Patterns to create a named solution. The patterns that make up MVC are typically the Observer Pattern (Model), Strategy Pattern (View and Controller) and the Composite Pattern (View). MVC originated in the Smalltalk-80 language back in the 80’s and it has since been implemented by just about every programming language that requires a user interface, so it is a perfect solution for building Flex Applications.

MVC is even easier to implement in Flex Applications as you can utilize Event dispatching to simplify invocation between the MVC triad. This allows developers to remove the somewhat awkward Observer pattern which is dependent on passing references of each member throughout the MVC triad.

The MVC paradigm is a way of breaking an application, or more commonly, just a piece of an application’s interface, into three parts: the model, the view, and the controller. Each member is intentionaly segregated and represented by an object that is responsible for handling a specific task within the application.

MODEL: The model is used to manage information and notify observers when that information changes.

VIEW: The View is responsible for rendering the model to the user. This is usually rendered as a visual display but a view may also be a sound, a controller vibrating or anything that needs to be conveyed to the user.

CONTROLLER: A controller accepts input from the user and instructs the model and view to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response. For example, if the user clicks the mouse button, the controller is responsible for determining how the application should respond.

Here is a basic example of how to implement MVC:

Imagine that you are building a simple application called “Blogs that I read”, which is intended to allow users to click a link that loads a Blog that you read. To implement the MVC Pattern in it’s most basic form you would have three classes; BlogLinksModel, BlogLinksView and BlogLinksController. BlogLinksModel would store the blog links and handle which URL to load when invoked by the controller. BlogLinksView would handle rendering the visual display based on data provided by the model. The view would also be responsible for notifing the controller when a link was clicked. BlogLinksController would handle the processing of the selected link, determining which link was clicked and invoking the model based on this information. The model in turn would then load the URL when invoked by the controller.

It is important to keep in mind that there are many different interpretations of how to implement the MVC pattern. You can keep it simple or you can be as granular as you want. It is basically up to you as the developer to decide which implementation is appropriate for your application. What is important is that you stick to the basic principles of MVC and keep the model, view and controller segregated. Personally I prefer to have the controller do most of the heavy lifting. As in the example above, I prefer to have the controller actually load the URL as oppossed to the model making the request directly. But that’s just me. You can implement MVC according to your own interpretation. As long as you stick to the fundamental rules you’re application will be in good shape. And you will definetly begin to realize the benefits of implementing MVC as your application scales.

I have provided links to the above sample application, ASDoc and source code as well.

If you would like to learn more about MVC click here.