Velocity Info

[Sama]

This document explains how Velocity is built and operates. I've tried to explain it in the least programmer-oriented point of view, and is therefore intended as a high level explanation for plug-in developers, as a guide for flash developers, and as info for curious cats!


Summary:
Velocity allows skins to be PURE Flash, intended to work on ANY platform, and to allow plug ins to be coded in ANY language.

Skins are Flash swf movies with all the animation, sounds and everything you see in Flash presentations, without having to rely at all on any structure or restrictions imposed by the front end.

Flash communicates with a Java server. This Java server contains plug ins, and these plug ins can be written without any knowledge of the user interface. The plugin's methods are all delegated, and the properties are all synchronised between Java and Flash via the Velocity framework.

Non Java plug ins, which would probably be platform specific, communicate with the framework through XML via network sockets.

Here is a High Quality or Low Quality sample video, which illustrates how a DIVX movie is being played right from within an animated Flash movie.


Detail:



Distributed Computing
Velocity is a distributed computing application. Which for our purpose means you can have any number of pc's, running any number of interfaces, and that means any of these scenarios:

• 1 Computer -> 1 Screen
• 1 Computer -> 2 Screens
• 2 Computers -> 1 Screen
• X Computers -> X Screens

Moreover, each computer can be on a different operating system. So if you have a PocketPC, you can use Flash on there and use it as a remote control. The capabilities are there, but the possibilities are not all known at this stage.


Software Model
At the topmost level, Velocity uses an MVC architecture. This allows complete separation of the presentation layer, from the logic and from the data. In an English example, Flash can be used to do the user interaction, Java can be used as the mediator, and plugins such as a mplayer wrappers can be used to do the media playback. Which is exactly the approach used.


Network Communication
The layers communicate to each other via network sockets. The advantage of doing this is that different layers can lie on different devices if need be. Typically, there's only one computer in the car so all layers will be there, but the framework can support different configurations. Imagine that you have a PDA with Wifi, and you want to use that as a secondary display, or you want to have two displays running on the same PC, but you want to separate the games playing process (the kid in the back) from the GPS process (daddy in the front). These are the types of scenarios that will be possible the distributed approach.


Java
The backbone of this framework, the controller, is coded in Java. And that can live on most OS's. This of course also means that Velocity is multi platform.

Contrary to what most believe, Java is extremely fast. I work with it every day and I have seen some amazing things with it. In fact, it's no different to .net as it too runs in a virtual machine and requires installing a Virtual Machine (JRE - Java Runtime Environment), just like the .net framework.

Current tests of an alpha version have shown that Velocity works well on an Epia1000 system with 1GB or RAM, as well as a PentiumIII 1.2GHz with 256MB of RAM. The minimum spec will be decided when the product is finished and tested.


Plugins
In short, plugin developers do not need to anything special to make their plugins work. They just write a plugin that has some methods, and it's own data structure, and Velocity takes care of the rest.

The framework is arranged such that any functionality to be added, is added as a plugin, and a plugin is an independent stand-alone peice of code that can operate by itself, oblivious to the presentation layer. These plugins are interrogated by the framework and their methods and data structures are pushed to the presentation client (Flash). Since every plugin registers itself, the framework will also know to route any incoming requests to that plug-in, based on the header of the request.

Flash requires a "bridge" between it and the Java controller to manages its connections, and interpret the advertised services etc. This has been coded as a component. That means it's completely transparent to designers. They will get an compiled unit that they include in their skin movie, and this mirrors the data structures of the plugin, provides access to calling methods in plugins, and receiving data back... as if by magic!


Non Java Plugins?
Included will be a .net bridge and a COM bridge. It would mean that the plugin would be platform specific, but that's up to the developer. As long as a service adheres to the framework's protocol, then it should be possible to commuicate with Velcoity via a simple network protocol.


GPS?
GPS is paramount in any front end, therefore initially, the same approach that has been used everywhere else will probably be employed here, which is to wrap an existing app and embed it in. Of course this will be a platform specific plugin. Later, there are plans to write a multi platform GPS navigation tool in Java.


Video in Flash
Flash isn't amazing for it's video support, nor do I intend on streaming to Flash. So instead, an overlay approach is used, where the flash skin makes way for some video, and this is placed on top of everything. Nice and simple!


The Media Plugin - an example
For this, I initially chose the excellent VLC, which can play pretty much any format out of the box, including a free DVD decoder. It also works on any OS, so it's ideal for the multi platform approach of this front end. But then I came accross mplayer, which can do exactly the same as VLC but without the difficulties of connecting from a console. It's also designed to run without a GUI from scratch and therefore included a lot more functions specifically for console use.

I could do with some help in testing on Linux if anyone cares to offer it.


Flash Sample Code
Here is a small snip of the code required in Flash to drive the Media plugin:

// and play the playlist when the play button is clicked
playButton.onRelease = function () {
    Velocity.getPlugin("Media").invoke("play");
};

This will tell Velocity to talk to the Media plugin, and invoke its play method, which in turn, will then update its data access object, such as the song name, and the current playing time. And this would be extracted in Flash as follows:

// get the name of the current track
var trackName:String = Velocity.getAccessBean("Media").info["trackName"];

This is how info from a plugin is read into Flash.

// define a method to callback when the currentTime changes, so the _label on 
// the flash movie can be updated
var currentTimeWatcher:Function = function (prop, oldVal, newVal, currentTime) {
    _label.text = newVal;
};

// add a watcher to the Media plugin's 
// currentTime field, and call the currentTimeWatcher method when it changes
Velocity.addWatcher("Media", "currentTime", currentTimeWatcher);

This is how call back methods allow labels to be updated when plugin properties change.



If there's anything that is not clear or that I have missed, please ask or tell.