Carlo gave a nice summary yesterday of the state of play of Native Mobile Apps (like JME), as opposed to developing for the mobile web, quoting recent deep thoughts by luminaries in the mobosphere such as Michael Mace, Mike Rowehl and Dean Bubley.
If you’re a regular reader of MobHappy, you’ll know that this is a subject dear to my heart and one which I’ve written about on numerous occasions. My take is that JME is basically broken, almost to the point of being unusable for developers, with the porting taking a ridiculous amount of time and energy.
But as my fellow mobilists point out, sometimes we need the functionality offered by an application and if that’s the case, we need to take a deep breath and plunge in, even if we know it’s going to be absurdly painful.
But, perhaps there is a middle way, Grasshopper.
One of the basic issues with native mobile apps is actually a marketing problem. Loads of people download applications - games and instant messaging apps get downloaded in their millions. Not to mention Opera Mini and Google Maps. What actually happens is that people don’t download an application if they don’t really understand what it does or why they would benefit from it. That’s not to say that they wouldn’t understand it once they have it on their phone, just that it might be difficult to communicate in one snappy line of copy.
So the middle way, is actually to develop for both environments. The mobile web (perhaps with limited functionality) becomes your market entry product - a way to get potential users to try your product. A lite version, if you like. Then when they understand just how cool and froody the thing is, they might be ready to upgrade to a power user and download the fully functional, all-singing-all-dancing JME application.
Don’t get me wrong - I’m not turning into an apologist for Sun’s JME. Those guys had the world in their hands and blew it. I pray that someone comes up with a better product and takes the game away from them. Or that they finally put their own house in order, but I don’t see any sign of that happening soon.
But for all the developers out there, consider the middle way. It’s an easy way to trial your great product, while allowing your fan-base to get the true experience when they’ve sampled its delights.
Yes, sensei, the middle way rocks!
Though you do need to still support a few different client versions for X flavours of J2ME and Symbian, and then also learn about how different mobile browsers render your mobile web content.
I’ve been working at Bluepulse recently and they put it nicely (I think it was Heidi who coined it) when they say that mobile phones are like snowflakes: at arm’s length they look pretty similar, but up close, they’re all very different.
Bluepulse is seeing good adoption through having the whole product feature set available and rendered well on a broad range of browsers. But what’s key is having the *whole* product experience functional in the browser, not just a subset of features seen on the J2ME client or the desktop browser version.
It still amazes me how many “mobile” apps ask you to go to a desktop computer to sign in and create an account. Can you imagine how slowly Hotmail would have grown if when you visited the site for the first time, it said, “now go to your daily newspaper, cut out, complete and send in the coupon you find there and we’ll send your login details in the mail”?
Interesting…. What do you thing of platforms from the likes of firethorn or mfoundry
Agreed. I’m developing a really simple app at the moment, basically just a customised document viewer for some specific content, and I’m doing both the mobile web and J2ME at the same time.
The J2ME app will not require continuous (or even any) data access from the phone, but will obviously be restricted to the handsets it runs on (though as little as possible) compared to the mobile web app.
The mobile web app will retain all the functionality, with as similar a UI as possible, and hit most phones out there through use of WURFL and it’s WALL page adapter, but it will require a data access plan of some sort on the phone of course.
By doing both, I hope to offer the app to more users, who can pick which one suits them best. Given the limited functionality required for this app, the user experience is actually very similar on both platforms.
Alex
CEO
phonething.com
One of the interesting things that we tend to forget when it comes to browsers and our ‘brower-based apps’ however, is that much of the functionality comes not from the core implementation of the browser, but from various add-ons. Many of these add-ons are not available for the mobile browser, so it becomes difficult to create a compelling interactive experience without the additional tool sets.
Currently we are building ‘hybrid’ apps that attempt to dance around the difficulties of both browser and on-device applications and provide the user with a cogent and satisfying experience.
Developing for web and J2ME is the standard rollout pattern.
Fragmentation also exists in browsers, especially for rich sites. Any major brand will usually test their site on the leading handsets within each target country.
As far as I know, fragmentation in J2ME, or more specifically MIDP and its various add-on APIs is usually an artefact of the API implementation to the underlying native APIs. After all, this is how J2ME works.
The bottom line is that the industry is a mobile *telephony* one with some general purpose computing APIs tagged on the side, with the exception of ground-up mobile operating systems. Hence, overall, the ecosystem isn’t really in place to ensure a reliable, robust and consistent mobile *computing* ecosystem.
Mobile handsets are not designed, sold or bought whatsoever on the basis of how well they implement MIDP. Within that context, it remains a messy business, but the technology is still solid in my opinion.
Another critical issue is the lack of after-sales upgrades and fixes. This is actually what tends to iron out a lot of issues in the computing world. This is why we can find handsets of the same model and make displaying different MIDP behaviours - the underlying firmware was “fixed” or “tweeked” from one to the other.