Again trying to figure some stuff out for myself… but there’s more to this project I guess
I’ve been struggling with finding ways in which we can standardize a lot of what we do. We are a unique programming bunch in that we work very closely with a creative department (designers), and that’s assuming we are not the creative person on the project in the first place.
The question is this, how do we integrate creative and development in the simplest, most efficient, most flexible way we can?
Everyone is looking for the answer in a lot of other programming languages, and the standards that they have developed. This is in one way good, but at the same time bad.
When it comes to programming concepts they are all very generic and apply to nearly all areas of developing a project. This is all fine and good, and people are really understanding it. You see more people talking about encapsulation, and abstraction… a lot more talk of reuse, everything any good object oriented ‘community’ should be using and talking about.
I think that the problem is with standards, we don’t have any standard way of doing things.
Lately I have been trying to develop my own standards ( for myself… not trying to inflict my bad decision making on you guys, however if you read this, I feel you are capable of making bad decisions on your own, so take this information for what you will 
)
So what I think I’m going to do is talk about some ideas I have, and see what people think, and what kind of thoughts can be provoked.
In this part I wanted to talk about loading, and monitoring loading.
When you are loading information you have one goal, and that is to move information from a location (url) into your application. You are the developer so when I say into your application I mean into your code, which means that you should treat receiving the information that way.
By information I mean anything that can be loaded that is textual, xml, images, swfs… this idea goes for all of them.
This is something that us as Flash developers deal with probably more than any other development community. So I feel it deserves special attention.
The process of loading information is relatively the same regardless of what that information is. The developer makes a request, optionally monitoring the progress of the request, and then handle the request when it is done.
Firstly let’s tackle the initial issue, which is just loading the information. When you are developing an application and you need an asset, it should be as simple as providing a method with the location of the asset, as a url, and the function that should be called when the asset is ready to be handled.
This led to what is a generic interface for load methods. I don’t mean interface in the OO class/interface way, more like a method description.
// load interface
load( url : String, callback : Function )
It should always be relatively this simple, and it should always happen in one place.
Cool, so we are loading our assets… (it shouldn’t matter how it happens right? It’s only important that it does actually happen). How do we monitor loading?
When you monitor something loading, most of the time you will only be concerned with how much has been loaded. Most people display this information in what they call a preloader (you all know what I’m talking about). When displaying this, the creative team may want to put just a progress bar, and other times they would like to display it as a percentage, and sometimes they show the amount in bytes that has loaded, compared to how much you needed to load in total. Of course they are not limited to this, so you must be flexible.
In what we talked about we can see that we are concerned with a few specific properties. We are talking about a percentage, the total bytes, and the status of the load. We are concerned with the status because the developer wants to know when the load errors, or is complete as well as when the load progresses.
What I decided to do is have an object represent the load as a stream, which updates it’s properties and broadcasts events anytime the status of the stream is updated. The event contains the status of the stream as well as a reference to the stream.
The stream has the three properties we are concerned with, percentLoaded, bytesTotal and status. As well as methods for registering to be a listener of the object.
This idea of the stream led to a revision in the load interface. You still call load in the same way, with the same arguments, however now you are given a stream object which can be used to monitor the progress of the load.
// load interface
load( url : String, callback : Function ):LoadStream
The key player in this system is the LoadUtility. It is in this utility that all loading logic takes place. LoadUtility is a static class that contains the various load methods we need. Each load method follows the same format , load( url:String, callback:Function):LoadStream, which is what abstracts what we are loading from how we monitor it.
When the information is done loading and is ready to be used, you make a call to callback, but what do you pass to callback? This is something that I’d like for us all to talk about, but in this first take it is simply the Event event that is broadcast by whatever load mechanism (Loader, URLLoader, etc) you use.
Listed directly below is the demo class, followed by the listing of the classes. After that I will try and gather my thoughts about in what ways this can be extended.
- Design Notes
I designed this to be flexible, and it shows in some ways. For instance, a lot of people deal with ‘batch’ loading, or just loading of multiple files with one single request. Theoretically, and quite easily, a LoadStream object can be created that treats the collection of streams in the same way as one single stream.
There is also room, and plans… and in fact I’m already working on, a StreamManager, which will be used to monitor and log what, how much and how often assets are being requested and loaded.
Another thing I am working on is a prototype display for the stream manager, which would simply just have a way of displaying the progress of all streams, possibly in a window that can be closed or something. With this we don’t have to build the displays up front, we can develop with a prototype and wait for creative to get done. After all it doesn’t matter how we implement the display, the load status is always represented in the same way.
Anyway, the code is in the following post. There’s much thought behind all of this, much more than is posted, so if you have questions please ask, and if you have suggests PLEASE suggest, that is the whole point of all of this.
-Michael
