Project Elbow: FileManager

Another night of programming.

Since it’s just not a good idea for loaded modules to be calling the FileLoader (or SQLManager) classes directly, I’ve created the FileManager class to load files for them.

The FileManager also limits the numbers of files being simultaneously loaded to a preset number so in case the files are actually being downloaded there won’t be too many service calls being done at once.

Also, the FileManager class makes sure that the file being loaded isn’t already being loaded.  If the file is already being loaded and it’s a download, then sending another request doesn’t make any sense… so such a request is queued instead of started.

In the future it might make sense to move the SQL and cache lookups into the FileManager class so it can go ahead and run a task that’s going to load a file from cache regardless of the length of the running list.

Right now, files are loaded in FIFO order, but a priority number could be employed to order the tasks in the waiting queue.

Most of the items that will be loaded will be media files, so a separate media manager is going to be required so that the FileManager/Loader process doesn’t have to run if the bitmap data is already in memory.

I suppose this could all be rolled into the FileManager class…  It will be important to use weak references or a separate reference counter of some sort so the FileManager (or whatever) either isn’t holding on to anything or can let go when something had fallen out of use.

I don’t know.  This might not be a problem.  The kinds of media I’m thinking about are user interface elements, but those would probably be embedded or drawn by Sprite modules. Or they would be loaded and cached by a module and a new instance created on the fly from the cached bitmaps.

So many details.

I’m tired.