StarRequests: Making modular requests using AS3 Signals
Background
The concept of making modular requests is one I’ve used in recent projects, and I thought it was time to standardise and release this as a library. Each request revolves around a simple interface:
The aim is to make each request modular, consistent, simple and for it to clean up after itself. By making each request implement an interface, and therefore consistent, it facilitates the creation of useful utilities. With this in mind I thought I’d put together a library of common requests and utilities.
Benefits of using AS3 Signals
The main benefits of using AS3 signals over the traditional AS3 event system (for me) are that signals can be defined in an interface and a signal can free itself up for garbage collection by removing all of its listeners.
By defining the signals in an interface we can be certain that any implementation of the interface implements the defined signals; in this case each request much have an implementation of the started, progress, completed and failed signals. The advantage of this is that any utility class we create knows the signals that each request can dispatch, because they are enforced by the interface.
Another advantage of using AS3 signals in this library is the ability to remove all of the listeners of a particular signal at once, which is another feature not available to us when using the traditional event model. The benefit of using this method is that once a request has dispatch its failed or completed signal it can then confidently free itself up for garbage collection without worrying if all listeners have been removed (we all know that not removing event listeners is a common cause of memory leaks!).
As a side note, without the AS3 signals library I wouldn’t have thought of requests in terms of interfaces and thus created this library!
StarRequests
The initial release of StarRequests includes some common load requests, a batch utility and a queue utility. For now, I’ve only included the common requests that I’ve used in recent projects, which include loading an XML file, a Bitmap and BitmapData. I plan to add more varied requests as times go on as there’s no restriction on the types of requests that can be implemented. Heck, you could have a move request that moves a Sprite to a specified position. The point is that as long as a request implements the correct interface it doesn’t matter what the request does. Other ideas for requests include File I/O requests, database requests, etc.
The library includes a queue utility, which allows you to continuously add requests to the queue utility and it will execute them in the order they are added. This utility could prove particularly useful when creating applications that are continuously updated via external APIs, such as a Twitter client.
The other utility that’s included initially is a batch utility that allows you to set up a batch of requests to be sent together, one after the other. The clever thing about this utility is that it also implements the request interface, so you can create a batch of requests that can then be included in another batch or added to a queue. Without defined interfaces, and the use of AS3 signals, implementing this functionality using the traditional event model would have been a lot more complex!
Timesaver
Not only are the requests included in StarRequests modular and consistent they also help you save time when coding. The idea being that not only do StarRequests promote a good use of polymorphism, but they also require less lines of code to use. The following snippet shows loading an XML file using normal loading techniques, and cleaning that request once it’s complete.
And now look at the same functionality using StarRequests.
It’s much quicker to write the code to load XML files using StarRequests, and it takes out the complexities of cleaning up for you! Now imagine trying to create a queue for loading XML files in the normal way, or a batch process, it would be complicated but StarRequests makes that really easy for you.
Using StarRequests with Robotlegs
I’m almost exclusively using Robotlegs with AS3 signals for all Flash Platform projects and so I wanted to make sure that StarRequests fits in with my current workflow. I think it does. Each request is completely modular, fitting in with Robotlegs’ philosophy, and therefore can easily incorporated into a Robotlegs project. It’s even possible to set up a centralised request queue service for your application so every service sends their requests to the centralised queue to be sent.
Using StarRequests to build API libraries
Using StarRequests to build API libraries could prove to be very powerful. Imagine a Twittier API library built using StarRequests; you could have a login request, update status request, get friends request and a get timeline request all of which could return strongly typed responses in their completed signals, and could be added to queues. This would be much more efficient than expecting the user to manual parse each response. Furthermore, if you look at the code examples above you’ll see how easy the API for the library could be!
Another advantage to using StarRequests is that, because each request is modular, the compiler only needs to include the requests that are used as opposed to the entire library (usually an API library is encompassed in one class). Separating the requests into their own classes can help to reduce the final file size of the compiled application.
Download StarRequests
The StarRequests library is available to download from GitHub as both the source code and a SWC file. It can be used in any AS3 project whether it uses the Flex framework or not; so you have no excuse not to try it out!
Feedback
Please feedback on any issues or requests you have using the issue tracking at GitHub and I will endeavour to solve the issue or implement your request (if I feel it fits in with the library).
Todo list
Add ASDoc comments to the libraryUpdate: The library now has ASDocs!- Implement unit testing
- Add more common requests/utilities
- (Possibly) create API libraries for common services (Twitter, Flickr, etc) using StarRequests
Disclaimer
This is the first release of StarRequests and thus as improvements and additions are made the structure of the library may change slightly.
Subscribe to the RSS
Follow me on Twitter
Follow me on GitHub
Great post. What workaround, if any, have you used for the lack of bubbling support with Signals?
May 17th, 2010@eco_bach I haven’t! And I’m not sure I will. I like the nature of signals in the sense that I know what’s going on because I’ve implemented it!
However, it would always be possible to bubble the signal yourself by creating a signal in the class that constructs the request. It would take a little while if you had a few levels to bubble, but it would have a similar effect. Alternatively you could write your own requests that make use of the signal that does bubble!
Mark
May 18th, 2010Hehehehe nice post with gist!
NICE!
May 18th, 2010@eco_bach…
May 18th, 2010I don’t know that bubbling is all that it’s cracked up to be. I prefer listening to an event directly rather than wait for it to come up from some other display object.
Having said that, there are the odd times where it is easier to listen to a bubbled event..
As mentioned somewhere else,http://www.dehash.com/?p=241,
you can bubble with Signals using a DeluxeSignal instance..
cheers
Yup you can listen for bubbling with Signals but it’s not the best case scenario. I’m a bit bummed about thats actually. I find bubbling is useful for triggering global things like tooltips and scrim layers from anywhere in your app.
Use DeluxeSignal and pass the dispatch method a new GenericEvent. Then somewhere up the line where you want to listen for it implement the IBubbleEventHandler interface and use onEventBubbled to handle it.
I have not found a way to send params along with the event or how to use specific listeners for specific bubbled events. Instead your handler will need to catch all events that may bubble through.
You’ll need to use a conditional statement in your bubble handler to decide if it’s the event you wanted. You can check event.target or event.signal to differentiate.
As erick mentioned there is a good example posted here.
June 8th, 2010http://www.dehash.com/?p=241
Nice post, I recently arrived at pretty much the same implementation
. Though I didn’t quite realise the potential for defining the request itself as an interface!
July 2nd, 2010@Peter thanks! I’ve been using this approach to my work for the past month or so and it’s really changed the way I work. I can build a request once and then use it as many times as I want in my code, knowing that the implementation is solid.
The cool thing is that a request can do anything! It can be a request to a service, or reading a file, or tweening a display object, literally anything! And once you’ve written it once you can slap 10 of the requests in a batch and it’ll just work!
Coding to interfaces is really beneficial. Especially in this circumstance. When I’m connecting to services I can make a fake service request which can be swapped out for the real implementation at any point. And because they both implement the same interface the rest of my code need not know about it.
Mark
July 2nd, 2010