Thursday, July 9, 2009

'Opera Unite' released for Android, Win Mobile, Nokia S60 and Brew!

A few weeks ago Opera announced its latest innovation: Opera Unite, a small web server sitting in the browser enabling true peer-to-peer transfer of content and social networking. A preview version of an Opera desktop browser is available for download, a mobile version is said to be in the works (at Opera).

What most people may not know: The feature that Opera Unite delivers is available on mobile handsets already, namely on Android (here it rather works with Webkit), Win Mobile, Nokia S60 (Webkit again) and a Brew based handset. In fact, it was already demonstrated on JavaOne four weeks ago. How come?

What Opera calls Unite and intends to port to mobile tomorrow is functionally contained in what Sprint (wireless carrier in the US) calls Titan (which essentially is Mobile OSGi plus web browser integration), shipping with a number of handsets this year. What each respective technology does:
  • it turns your device into a full web server (we call it the The Server in your Pocket)
  • it lets you share your content peer-to-peer with your friends
  • the local user interface runs in the browser
  • new services & capabilities can be injected (taking effect on both the server and the browser based UI)
  • on broadband networks it discovers peers via some internet lookup service (for instance, the demo on JavaOne used Twitter for that purpose). Certainly, Opera is ahead of the game in this regard as they provide an operational central DNS service operational
  • on local networks it can discover peers through UPnP

Despite these similarities, OSGi takes the concept one step further and offers additional capabilities:
  • it is browser agnostic. In fact, on Android and S60 the Webkit browser is used, whereas on WinMobile and a Brew based handset we use Opera Mobile (without Unite support)
  • the server feature runs in the background and is available even when the browser is down
  • new services (i.e. a new p2p messaging service) are written in Java and are deployable (push or pull) at any time (even once the device is already shipped). This opens the door to leveraging an incredible amount of existing code, knowhow and developer resources. Moreover, pure Opera Unite services run in the browser sandbox and cannot leverage platform capabilities that Opera does not provide JavaScript APIs for. In mobile this is crucial as file access (essentially the only platform access API currently available in Unite) isn’t all you want to use. There is location, messaging, PIM, etc. … In OSGi, you’re not bound to the APIs of your sandbox, you can bring you own APIs! Not to speak of the many APIs you get out of the box
  • OSGi is a recognized industry standard, it is not a proprietary technology. It has an open governance model, a reliable spec and a huge developer community behind it

Anyway, despite these differences I am extremely excited about Opera Unite. Alike Sprint and OSGi, Opera has stood up for a new approach of architecting the internet: Turning dump clients into intelligent servers. It is not about yet another social networking platform, it is about expanding the very core fabric of the web and the way social communication works today. It took a popular brand like Opera to finally get a public conversation going about this new architecture. I sincerely thank Opera for having created this level of awareness in public. Sprint & Co. haven’t managed to create even just a fraction of the buzz we have seen in the last few weeks, initiated by Opera's announcement.

Lawrence Eng from Opera says in his blog "I hope you’ll join me in imagining a more personal and social computing experience that actually begins to deliver on the old (but not forgotten) promise of the Internet bringing people together in meaningful ways." I certainly will! Will you?

Opera, why don’t we team up and explore what comes out if we combined Unite and Mobile OSGi?

- Jo

Tuesday, June 23, 2009

Update on OSGi for Android

In Nov 2007 folks from Luminis managed to port OSGi onto Android, or more precisely, onto what was called Android back then. Meanwhile most framework providers have gone ahead and ported their implementations to Android as well. However, as I argue in an earlier post, refer to Mobile OSGi on Android, I see little value in just porting OSGi. The value comes from integrating OSGi with Android. OSGi must be understood as a complementary platform, not a competing technology and that approach requires a good level of integration between the two.

Pursuing the goal to create a value adding OSGi based stack for Android, ProSyst recently releases the first version of the stack. It works on all Android 1.5 (Cupcake) compliant devices. Here's is the list of supported features from the Release Notes:
  • Compliant to specifications OSGi Core 4.1 and OSGi Mobile 4.0 (JSR232)

  • Java Security enabled and integration between OSGi and Android security policy frameworks

  • Support for w3c & Opera based Web Widgets
    • Web widgets run in WebKit browser-based viewer
    • Installation and security verification of Widgets executed through OSGi

  • Server in Your Pocket & RMA (Richt MobileNet Application)
    • Local web server functionality, pretty much the same thing as Opera Unite (will blog about that one soon)
    • Automated translation of OSGi services into local JSON based web services (provides Web Widgets access to platform capabilities like Messaging, Location, etc. You can also write your own OSGi services in Java and provide access to that functionality to your web widgets)
    • JavaScript Convinience Library for finding, binding and using OSGi services within the browser

  • Integration of Android Intents with OSGi Event Admin (bi-directional exchange of events/intends)

  • Access to OSGi Services through Android IDL (enables Android developers to leverage OSGi services)

  • Access to Android APIs from within OSGi

  • OSGi runtime lifecycle management: User can select different OSGi runtime modes (Always On, Always Off, On if OSGi content installed)

  • Content Management User Interface
    • Listing OSGi content packages
    • Installing content from SDCard
    • Unistallation of content

  • Installation of OSGi Content through WebKit Browser

  • Full mobile device management support
    • OMA-DM 1.2 based remote management interface
    • All OSGi defined Management Objects: Configuration, Application, Logging, Monitoring, Policy
    • Sotware Component Management Object (SCOMO): Remote management of Android APK packages, OSGi Bundles, OSGi Deployment Packages, Widgets (push-install, update, uninstall)

This is pretty much as much as you can get from it right now. Features coming in future releases are:
  • Support for Bundle App Model (so that you can write bundles that use the native Android UI APIs. To do this properly an integration with the OSGi Application Admin is required)

  • Connectivity between OSGi runtime in Android with Eclipse IDE based OSGi Development Tools

  • Extend the OMA-DM device management tree by the Lock&Wipe Management Object (LAWMO), which enables enterprises to remotely wipe lost or stolen phones.

  • Enabler OSGi Service APIs & JavaScript for accessing phone featuers like Camera, PIM, Messaging, etc.

The stack is available for side-load as well as pre-load (for OEMs who decide to pre-integrate it on their devices). In fact, the Lock&Wipe and Android Package push deployment featuers require the stack to be signed by the OEM.

I hope this solution as well as the work of other OSGi community members (i.e. EZDroid) will help drive adoption of OSGi on Android.

Jo

Tuesday, April 21, 2009

Listen to Verizon!

A lot has been written about this years CTIA, big news about new voice services, Skype on iPhone, Samsung presenting Android or not, bla bla bla. The most remarkable statement, however, was littled commented: Verizon committed to Mobile OSGi!

Talking about the carrier's challenge of supporting 8 or 9 different mobile operating systems, Verizon Wireless' CEO Lowell McAdam said that "I don't think I need to bet on an operating system, I need to bet on layers that will bridge those operating systems."

Isn't that exactly what OSGi delivers? A cross platform bridge for apps, services, APIs? A manageable middleware layer that reduces bad fragmentation while unleashing a particular platform's power? I'm absolutely sure McAdam alluded to Mobile OSGi, there's just no other way... ;-)

Thursday, April 2, 2009

1,000 reasons to go for Mobile OSGi

Apple has recently announced the iPhone OS 3.0 Software. As for any of their public statements, once again Apple is extremely proud of its own achievements. The new OS version is said to come with 100 new features and an incredible set of 1,000 new APIs. Indeed, version 3.0 seems to mark a major milestone in the iPhone evolution and I am sure they really did a great job.

What’s the connect to OSGi, though? The iPhone 3G device was launched in June 2008. The new OS 3.0 is expected to be launched around mid 2009 - that's 1 year period at least. Apple claims that ...With the new SDK, members of the iPhone Developer Program can build applications that do even more... I'm sure they are not exaggerating on this. However, why would developers had to wait 1 full year (!) to get more APIs? Why to have them wait 12 long month to leverage more of the extremely capable and beautiful platform that they had right from the beginning? That's one year of delayed innovation, one year of untapped opportunities, one year of competitors to catch up, isn't it? You think a year is not that long? I claim it is! Recap what has happened meanwhile: Android phones entered the market, Palm Pre has been announced (and if speculations are right will also hit the US market before iPhone OS 3.0 is out), Nokia has launched its touch OS (S60 5.0), etc. etc.

Mobile OSGi is setting out to solve the *API innovation cycle problem*. In OSGi, new APIs can be loaded at any time, by anyone (who has the right permissions). Developers don't need to wait for X years for the manufacturer to complete the next static image version - they just pull the APIs they need and deploy them along with the apps. Internet firms can wrap their services into APIs and have them be used by 3rd party developers to create the next gen mobile apps for them. New business models (like the one Apple is to ship with 3.0: in-app sales) can emerge way quicker than before etc. etc. For sure, there's always more creative brain power outside the manufacturers engineering team, why not leverage that, why not to unfold the true creativity of the worlds developer community?

It’s sad enough that the phone hardware platform got to have a static lifecycle. But the APIs don’t need to be static, really!

Thursday, March 26, 2009

Mobile OSGi on Android

Soon after Android was launched most of the OSGi framework developers got ambitious to port their implementations onto this platform. The world now has a number of "hey, see, OSGi runs on Android - isn't that cool?" type of demos. In my opinion noone really needs a plain OSGi framework on Android, the value add is very low.

Little thought has been spent on what OSGi on Android is actually good for, what's the value add that OSGi brings to the platform. We have spent quite some time to analyse the platform and came to the conclusion that it is not a pure OSGi port but a proper OSGi integration that enables value adding use cases. I have summarized a couple of our thoughts, find them here:



To recap the highlights of what OSGi can do for you on Android:
  • Support for Widgets (local web applications)

  • Support for enabling web apps to access phone features and custom services implemented in OSGi

  • Support for OSGi Bundles and Deployment Packages

  • Support for OSGi Applications that use the Android UI (coming soon)

  • Support for Remote Management (push/pull deployment of Android apps and OSGi content; remote configuration; remote monitoring and logging; etc.)

  • Support for eventing between OSGi and Android

Here're some screenshots on how the Widget support looks like. Widgets can be plain Opera Widgets (they comply to the w3c widget spec) or what we call RMA Widgets which are widgets that use OSGi as a local web server to access device functionality.

We'll continue to work out the value proposition so as an implementation that does all that.

Comments?

Friday, February 20, 2009

EclipseCon 2009


I'm extremely pleased to have been given the chance to talk about Mobile OSGi on this years EclipseCon in Santa Clara. Find the abtract here. Hope many of you will join the talk. Let us catch up!

Monday, December 29, 2008

Sprint Titan 1.0 released - Mobile OSGi goes Mainstream

Sprint has released the 1.0 version of Sprint Titan™ - a first class Mobile OSGi implementation for Windows Mobile 6.x Standard and Professional devices. Officially the following devices are supported, however, the stack essentially runs on any Win Mobile phone:
  • HTC Touch
  • HTC Touch Pro
  • HTC Touch Diamond
  • HTC Mogul

Official support for a selection of Windows Mobile Standard (these are typically the ones with the mini Querty keyboard and no touch screen like the Samsung ACE (i325)) is said to be announced shortly as well. Moreover, Sprint Titan is said to be integrated on Sprint’s mainstream Feature Phones.

In addition to the production stack which installs only on devices operated in the Sprint network (Sprint branded phones as well as non-Sprint branded phones provisioned by Sprint), Sprint offers 90 days trial versions of the stack which install on any Win Mobile 6 device. I have tried with a HP iPaq 614c and it works great! In my opinion, with these trial stracks Sprint offers a great service to all OSGi enthusiasts around the world who can pick up the stack and get started.

Compared to what Sprint released in December last year, the new stacks now support Location API on the CDC side, contain a bunch of bug fixes and have been performance improved. Functionality wise, there is still work to be done (full web widget and service remoting support, additional JSR support on CDC (like 135), OSGi Bundle App Model support, etc.). However, the new releases are a major improvement over the old versions and should be fun to use!

The new release package also consists of a new version of Sprint’s Eclipse IDE plugins (now Eclipse 3.4 is supported, several bug fixes were applied) as well as an 80+ page developer guide that helps developers get up speed. A set of application demos (binaries, source code and documentation) will come out shortly as well.

It’ll be very interesting to watch what the creative people around the world will start doing with this beautiful and powerful platform!