Project: Apollo Pre-Alpha Update

I just posted a refresh of the Project: Apollo pre-alpha technical demo. No promises about the reliability of different browsers at this point, but observe:

http://pre-alpha.project-apollo.appspot.com/

Key Features to Note

  1. Portions of the UI have been built and are functional
  2. You can’t see it or manipulate it, but there is a playlist engine running with two tracks programmed in
  3. Abstracted audio rendering engine is working; the system will choose the best way to play audio based on your browser and the media you want to play*
  4. Keyboard shortcuts! Try [space] to toggle play/pause, [,] to skip back and [.] to skip forward; [v] toggles a visualizer, but it’s currently disabled

Of the sample audio, the first track is in Ogg Vorbis format and relies on HTML5 <audio> tags to render, which will likely only work if you are in Firefox 3.5+, or Chrome 6+. It works in Safari also if you are on a Mac and have the XiphQT components installed for Ogg media. The second track is in MP3 which should work in all browsers since it currently defers to the Flash implementation which most browsers can handle.

Please don’t be shy to leave your comments below!

* This was one of the hardest things to build. There is an enormously complicated permutation set of browsers and the media formats they support. The current options for playing audio are limited to Flash-based engines such as the one provided by Longtail Video, Silverlight by Microsoft, or native HTML5 audio tags. I’ve implemented all but the Silverlight option up to now. I haven’t setup any rules telling the engine when to use what implementation yet but will soon.

What’s Next in Apollo?

I’ve deployed the first pre-alpha build of Project: Apollo and you can check it out. So what’s next?

Technology Sidetrack

For a little while, I’m going to sidetrack from new features in Apollo to work on the audio/video rendering system. While I’ve got JW Player working decently now, it adds a lot of overhead and if Apollo is going to run on iOS devices, it will need to have an HTML5 implementation. So the next phase of development will be focused on improving the support for multiple rendering engines.

Visual Playlist

Right now the playlist is just a hard-coded demo. Logically, I’ll need to expose it to the user so you have some idea of what’s next in the list. Simple enough.

The Library

Probably the biggest function area is the library. This is where you can store and browse all the media in your library and make playlists and so forth. Details are vague but it will be cool. I promise.

Platform Decisions

I keep tinkering with different ways of presenting my blog, but I can’t ever seem to get quite the right “look” for functionality that I want. I probably have my only myself to blame for a) not clearly defining what it is I want and b) not taking the time to develop my own theme. I guess that’s why they say “If you want something done right, do it yourself”.

Pre-Alpha Preview of Project: Apollo

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.

100% HTML/CSS/JavaScript UI

All of the interactive UI elements are HTML/CSS/JavaScript, including the play/pause butons, the time display and the scrub bar.

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.

Building an application completely in client-side JavaScript is a very different beast than traditional MVC web apps. Project: Apollo represents (even at this early state) a milestone for me in terms of the way an application of this size and scope is constructed.

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.

Lessons Learned

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.

http://pre-alpha.project-apollo.appspot.com/

Rendering Media in Project: Apollo

Just wanted to document a few nuances that I ran into while working on some of the UI features in Project: Apollo.

Flash movies must be visible

I was hoping to use CSS to set the <embed> element for a Flash movie to something like:

embed {
  display: none;
}

As it turns out, a Flash movie that isn’t displayed isn’t rendered at all; the plugin control is killed off it becomes invisible. This may not be the case in all browsers, but it is the case in FireFox. As an aside, you can set the visibility to “hidden”, but the Flash object will generally still participate in DOM layout.

This was a problem because for audio visualization or video playback as I wanted to have the player hidden until the visuals were requested by the user. Unfortunately, in this case, playback does not occur.

The solution to this problem was to use absolute or fixed positioning to station the visuals where I wanted them. When not wanted, I positioned the element somewhere off-screen.

embed {
  position: absolute;
  left: -100px;
  top: 0px;
  width: 0px;
  height: 0px;
}

There may be some fudgery necessary to keep the window from unnecessarily adding scroll bars, but I am using GWT’s LayoutPanel so this was not an issue (or at least, accounted for automatically).

This also had the side effect of complicating my thoughts around a skinnable UI. Because of this visibility bug, I can’t depend on the skin to manage the container for the MediaControl. To do so would expose too much risk of a skin setting the Widget invisible or otherwise running amuck.

Instead, I relied on a less-pretty-but-more-reliable approach of providing limited access to a managed container in the DOM. The skin can never remove this element from the DOM and so the risk of runamuckery is greatly reduced. My managed container exposes just the functions of LayoutPanel I want exposed to the skin. If the need arises, I may switch this to a singleton interface, but for now, static methods suffice.

As another aside, a fully functional and fleshed out technical demo of the ControlBar is coming soon. Just have a few more items to wrap up.