Oavatos

I was lacking any form of a demo (other then the attached apk) in my last post to show what we were experiencing and why I have opted to see if I could develop an alternative. So here are two videos to show what we are currently releasing and what I am working on. These videos were taken from a CDMA HTC Hero were I had installed a VNC server which I then connected to the VNC server from my Mac and captured the video using Capture ME.

Rhodes based application

So as you watch the above video what you may notice is that after launching the application you will need to wait roughly 30 seconds for the springboard to appear. Now I know the HTC Hero is an older device and therefore is slow by nature, but hold those comments until you view the second video.

Native Android based application

In watching this video you will notice that from launching the application to having the springboard appear you are waiting about 10 seconds. So going native has reduced our launch time by two thirds. Now don’t get me wrong Rhodes is still an impressive means to release a mobile application for multiple platforms without requiring one to learn the native language of that device. It is possible that there may be some setting we have missed that may cause the display to render much quicker…though to be truthful we have checked with others and seem to be on par with their implementations of using the Sungard springboard.

I also received some feedback in regards to my previous post:

seems a bit silly. If you have any actual business logic Rhodes is much faster than an Android Java app

In reading over my previous post again I realise I was not very clear in what my plan after the springboard is. Now this is mainly because for now I am just focusing on the springboard. However here is what I am currently thinking (though that may change when I get closer).

Most of the content in our current mobile application can either be served as static HTML pages, or are web services. So in the case of a simple HTML application there is no business logic the “micro-application” would need to take care of other then to report any issues of not being able to fetch the HTML. For any of the web service widgets the idea would be to have the web service take care of the bulk of the business logic and report back to the widget in such a way that the widget could render any error conditions to the user.

Of course this would not cover some of the other areas of the business logic, such as any interaction a widget may need to act on (i.e. after doing a directory search adding the contact to your address book). I am still thinking about that part of the equation, but am not focusing on that until I finish the springboard component. It will also be on a app by app basis. My preference would be to try and distil our content down to a handful of application types but realise we may not always be able to do that.

Some background first. I work at the University of Manitoba and for the last 7 years I have been in charge of our Enterprise Portal which we are using suite of products bundled as Luminis from Sungard HE. Last fall the University was becoming interessted in developing a mobile application and around that time Sungard HE was offering a mobile product based on Rhomobile.

I was quite impressed with the presentations that Sungard offered in regards to this product and strongly suggested that this would be the best direction for the UNiversity to take given the somewhat limited development staff we had. The idea that a developer would only need to learn one language but could deploy their mobile application to multiple mobile OS’ was ideal. However as I played with it a bit over the fall I saw at least for Android devices the applications built were a little bulky and sluggish. I had hoped this was due to not tuning the application build.

However as the team that was resonsible for developing hte mobile application is getting close to releasing our first application for iPhone and Android they have found that despite various fine tuning the application is still sluggish.

So this leads me to my current post, last week on the way home remebering a conversation I had with a peer at USask last fall about this framework and our expierence with the Luminis portal he had an idea of manging the “micro-apps” via a webservice rather then via the rhoconfig file. The idea was to develop a set number of basic apps along the lines of what Luminis had in terms of channel types. This way one could add a new “micro-app” to all devices by using one of the base application types and updating the central web service.

What I plan to do is apply this concept not to the Rhomobile framework, but rather to using a mobile devices native language. My thought is, in an attempt to reduce the amount of device specific coding one needs to do to maintain such an applicaiton, can I create a springboard that relies entirely on a web service for it’s content? Then if I could do that, could I develop a set of generic “micro-app” types that would accomodate the bulk of the content we wish to include in our mobile devices. This way our developers would not need to build custom widgets in each language but just the web service that supports the application.

So a half a week later in messing about in the evenings and weekends I have my first dynamic springboard working on the Android platform.  It likely could be tuned a bit more, and of course made more bulletproof but as a proof of concept it works well.

When the application launches it connects to my server and fetches a JSON file (I have not built the web service’s yet) which is of the form:

{"items":[
{"label":"News","type":"rss","icon":"http://oavatos.org/test/mobile/news/news.png","control":"http://oavatos.org/test/mobile/news/news.json"},
{"label":"Events","type":"rss","icon":"http://oavatos.org/test/mobile/events/events.png","control":"http://oavatos.org/test/mobile/events/events.json"}
]}

The JSON contains the title, application type, icon and control file. The idea of the control file is that it will contain information that will help the generic application handler render the content. However That will be for another post to describe (once I get to that point).

So now that I have a prototype for Android my next task will be to teach myself Objective C and create a similar application for iOS. Once I have both of these prototypes done I will start looking at the micro app creations.

If interessted here is an unsigned APK of my efforts. Android Dynamic Springboard Prototype