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.