The OSGi specifications were originally developed for headless devices and user interfaces were therefore of no concern. This changed when the vehicle and the mobile groups worked on their specifications because they clearly required some graphic user interface. Within the vehicle group many discussion have taken place but we were never able to reach a consensus. The mobile group kept standardization of the UI specifically out of the charter because it was a hard choice and there are already standards for mobile phones..
Still, the lack of a good user interface standard makes it very hard to demo OSGi applications. Few decision makers get excited by a console running some cool (in my opinion) middleware. The lack of GUI is also a significant obstacle to portability between different environments. Why is it so hard to choose a specific user interface? The key problem is the wide range of devices that need to be supported; many devices do not even support a graphic display. However, there were more problems than just technical. Member companies also had a hard time compromising on the GUI technology because they already had favorite solutions. The interoperability issue was not of a major concern to most companies.
Swing and SWT are the standard solutions for Java applications. Both are toolkits with rectangular user interface components: text editors, sliders, lists, tables, etc. Though these toolkits are useful in desktop applications they fall far short of what is needed in a car dashboard or a highly usable mobile phone. They tend to consume lots of screen real estate, but worse, they are very static. In comparison to what is visible on the web nowadays, SWT and Spring applications are rather dull.
In the past few years many companies have turned to MacroMedia Flash for dynamic content. Try refusing to download the flash plugin and the web suddenly looks a lot less dynamic. Flash can play movies. Movies are sequences of animation of vector graphics. Vector graphics have many significant advantages. They are usually smaller than the corresponding bitmaps and they can be scaled, rotated, and translated while being displayed without loss of quality. Macromedia also added a programming language call ActionScript, making it possible to turn external events into changes in the movie as well triggering external actions on internal events; ActionScript is similar to Javascript. For example, on a mobile phone an incoming call can activate the part of the “movie” that shows different buttons to the end user. If the user presses such a buttons, the calls is taken or rejected. Sounds similar to SWT/Spring, the difference is that in Flash/SVG the buttons can change place, size, rotation, shape and color only limited by the imagination of the designer. Flash Lite, a stripped version of Flash that has been adapted to many mobile phones and provides phone specific APIs.
The most powerful aspect of Flash is the availability of powerful authoring tools. Macromedia and other companies provide tools for graphic designers to author compelling user interfaces. The result is impossible to achieve with Swing and SWT. And even if one could, good programmers are notoriously bad at UI design. Believe me, I tried and tried. Every time when I got a graphic designer on my design team the User Interface improved with a magnitude. I still do not know how they do it, but it works. Fortunately, they are usually lousy programmers.
Interestingly, there is also a standardization process going on at W3C for a format that is very similar to Flash: Scalable Vector Graphics (SVG), which is based on XML. SVG is not as mature as Flash yet, but they are improving quickly. SVG also has been extended with a Basic and Tiny profile so that it is suitable for smaller devices. Actually, the Flash Lite player can also play SVG-Tiny content. The obvious advantage is of course that SVG has no license cost. The bad news is that it will be harder to get SVG movies to play as consistent on a wide range devices as it is for a single company like Macromedia.
So what is the relation to OSGi? I feel that Flash/SVG might be a solution to the GUI problem. These technologies are primarily focused on the user interaction but have a fuzzier picture when it comes to programming real functionality. ActionScript is interesting, but it is no comparison what you can do with a real Java environment.
The OSGi Alliance could therefore specify how Flash/SVG content could be included in a bundle and how during runtime the events are bound to the bundle’s code. To support different screen formats, a bundle could include multiple versions. A desktop manager could load the content from the bundles and create the necessary bindings to the Java code when an application is activated.
This combination looks awfully attractive. It looks like such a model could finally provide the OSGi with the much needed User Interface option. Are there companies out there interested in this approach? Should we start working on this? Tell us what you think on the OSGi Developer mailing list ...
No comments:
Post a Comment