On Monday night I got the module loader system working. This means a user can now drop a module and module definition file into a predefined user services folder, launch the app, click through the title screen, and see the aforementioned module in the module selection screen. They can then choose any or all modules they wish to use as data sources and load them. Upon reaching the main application screen, clicking the retrieve data button will retrieve data from all chosen sources and populate the visual renderer.

The next step is to refine and document the module framework and API, create a mock data correlation engine (faked as per my capstone proposal), and refine the visual engine to properly process related objects.

On track!

Last night I spent more time working with the module loader system. This time I finished up the commands to retrieve service module definitions (which I reported on in my last post). Once I had that working on the backend, I slapped together a title screen and a settings screen where the end user can choose which data sources ( as supplied by installed service modules ) they want paradigm to use.

Next step? Create a scheme for modules to collect their own settings.

Today I spent some time on fairly mundane issues. In order to manage modules (those little things other developers will create to provide Paradigm with services), Paradigm will need to be able to discover those modules and access them.

To that end, I spent time creating some utilities and commands to access the local file system, search out services modules, and then load them as proxies for my data.  Adobe’s AIR provides excellent facilities for interacting with the local filesystem, though I ended the night on a sour note of run time errors due to the directory access behaving oddly.

No news is good news right? Nope. The last three weeks have been a whirlwind of non capstone related stuff. Hopefully I will have something useful to post about later in the week after visiting family is gone and backlogged other stuff is taken care of.

Yet another part of my puzzle clicked into place tonight. I’ve implemented a system which will allow custom service developers to create “modules” for Paradigm which contain custom service classes. I will provide a limited set of classes necessary to create custom VO’s and service proxies. Using these classes, custom service developers will be able to create Flex modules and an XML file describing the module and any dependencies they have. Paradigm will search a specific folder for these xml files and modules, and can then dynamically load them into the app. Each module will contain a list of custom classes that Paradigm can use to access various services. These services could be local or remote, e.g. local filesystem, Flickr photos, Twitter feed, etc.

This was a major problem to overcome, but thanks to my work from two weeks ago on a dynamic settings manager and some extra research, it’s now built!

So after a night out on the town I came home and decided to do more coding at 2 am. It’s now 3:29am. I managed to create a completely dynamic settings manager. This will allow me to define settings involving complex value objects in xml, and then load them into the application at run time. For now I am testing this with a simple value object containing the default settings for flocking ( alignment, cohesion, seperation, and anchor ). I’m using the programming concept of reflection to determine which type of object is stored in the XML and to then dynamically instanciate it and copy any values which match between the XML object and the fully typed object in Actionscript. This will impact the users of my framework in that it is crucial to allowing them to create their own data sources, value objects, etc. in Actionscript and to dynamically bind them into the application for end users.

This probably isn’t coherent to anyone who isn’t a programmer or awake at nearly 4am at the moment. I’ll explain better in my writeup and code comments.

P.S. Assuming this isn’t just my addled brain lying to me at a late hour, this may be just the sort of breakthrough I’ve been struggling for to help me actually start moving at a faster pace of development (when I have time to work on this at all).

Woot! I fixed my stupid SVN problems. It turns out that when migrating from my old machine to my new, that my entire eclipse, flex builder, svn install was corrupted. So as of now my development environment is back to functioning properly, my entire codebase including libraries is check into version control, and I’m now going to do some actual honest work.

I keep getting frustrated when dealing with silly issues like SVN not working. Gotta just push past em.

Through a combination of conflicting priorities (work, health, etc.), stumbling blocks in my methodology, choices of technologies, and occasionally laziness, I have made little progress since my last post. I’m going to take a fresh crack later today and either blow through some stumbling blocks or do an end run around them to do something else productive.

My biggest problem is the most basic of pieces. I had never envisaged the building blocks of my project being so hard. At first I thought the building blocks would be easy and the later stuff hard. This is what it’s all about though. This is where the important stuff is. Now that I’m in the thick of trying to create things that are easy for other people to use to build complex visualizations, I begin to understand. I have more and more respect every day for the great ones like Tufte who understand all of this stuff in and out and the people who use his and other works to create the wonderful applications and visualizations that we all use.