Last night I put together and deployed a pre-alpha build of Project: Apollo to demonstrate the progress I’ve made thus far. The label “pre-alpha” should pretty well indicate the state of things.
There are some browser-specific quirks to address that pertain to the deployment strategy I am currently using, but those are of low concern at this [pre-alpha] stage.
Since most of what is working is under the hood, I’d like to highlight a few of the accomplishments in this release.
Fully Abstracted Player Framework
The underlying mechanism for rendering audio is completely abstracted and decoupled from the application itself. I am currently using JW Flash Player to do the heavy lifting but as you can see it’s pretty well hidden from view. The next step is to start working on alternative rendering engines to increase compatibility. More on that later.
Growable Application Structure
I spent a lot of time tooling and retooling the basic foundations of this project to ensure I was comfortable with the architecture. It was very important to me to build a good base upon which to build the rest of the application.
I am particularly pleased with the implementation of certain design patterns in the code. For example, state changes are conveyed using the observable pattern via an event bus and the JW Flash Player is cleverly integrated through the use of a Façade and Bridge. I am equally pleased with the separation of concerns in the GUI layer; building entirely new runtime-swappable skins for the application should be a breeze later on thanks in part to GWT’s Deferred Binding mechanisms.
Room for Improvement
There are certainly areas of the application which I would still like to improve. One area is on resource injection. In the past, I have used tools like Gin to perform dependency resolution and injection similar to what Spring provides. So far in Project: Apollo I have opted to forego any DI tools and do so myself. Where appropriate, I’ve used constructor arguments or setters to facilitate testing and singleton patterns in other places to allow access to global resources such as the event bus.
The primary reason I chose to pass on DI mechanisms is that my application simply isn’t complex enough to need them, yet. I’m sure at some point down the line, managing the creation of all my dependencies in the module entry point will prove too cumbersome, but for now, it’s simple enough to take care of those chores manually.
The biggest take-away I’ve gotten out of Project: Apollo thus far is a sense of value for certain programming paradigms. As I mentioned above, I opted not to use Gin in this project, but only after some internal debate. Initially I had included it in the project but I removed it when I realized the only reason I included it to begin with was because I had been trained to do so. I hadn’t thought it through for myself!
Using a design pattern does not mean using a library or framework! There’s more than one way to implement a pattern, it turns out.
I’ve also taken a bigger appreciation for the use of design patterns and when to use them. In previous projects, I’ve wasted tons of time trying to shoehorn every aspect of a project into a uniform pattern. For example, I have worked and reworked my own implementation of an MVP framework but ultimately I @deprecated the MVP interfaces in Project: Apollo. Simply put, not everything can be classified as a model, a view, or a presenter, and it’s important to recognize that fact.
(That isn’t to say that I don’t intelligently separate business logic from design and view logic. I do. But only enough to facilitate good structure and programming practices; no more, no less.)
Without further adieu…
I’m glad you’re still with me. As a reward for so patiently reading my entire rant, you may now proceed to demo the pre-alpha release of Project: Apollo! Disclaimer: I am aware of many of the bugs already and this being a pre-alpha release, I’m not too concerned about them at this time.