Opinionated comments on mobile phone industry news
|
All entries are written by Anders Borg, CEO and Consultant of Abiro, that has a long experience in strategic planning, developing embedded and Java software, usability aspects, and the mobile phone industry in general. You can also read the latest Mobile News entries on your phone via wap.abiro.com, and we provide many News Feeds from popular news services. For advertising and contribution queries, please use the feedback form. News feed (local) FeedBurner Feed
|
|
Monday, March 26, 2007
On the outlook for a viable mobile application platform
"But is there a real mobile development platform for independent developers?"
In my opionion, yes: Java ME / CLDC / MIDP. It's in pretty much all new phones, development tools are free, performance is not an issue anymore, and applications can be sold independent of operator approvals or certifications and other formalities. There are several independent e-commerce sites that can sell your MIDlets. There are certainly issues with the misdirected security scheme of MIDP, that I've commented on before, but for the basic functionality that's less of an issue. For stand-alone games and most utilities it's not an issue at all. Getting a commercial success is something else, and don't assume that you'll get rich just by releasing any odd application. I know that by experience. Testing on and adapting to many phones (which is required) is also a major pain, but less so if you rely on basic (read: old and tried) functionality.
I won't deny that a Symbian OS application can access much more of a phone's functionality, and also the latest functionality. Even when overcoming the MIDP-stipulated security warnings issued for many of the feaure accesses there are several features of phones that you can't access from a MIDlet at all. This is true for e.g. the SMS Inbox of the phone, something many want to access for good or bad reasons. In newer phones you can access the phone's file system and PIM database, but not in a user-friendly way, as per below:
"For example, to access file system of the mobile phone from Java, you need to use APIs defined in JSR 75..."
I agree the security scheme of MIDP and JSR incompatibilites are real issues, but most applications don't need to access the file system via JSR 75 anyway:
- Read-only files (images, audio etc) are bundled with the application as resource files, that are very easy to access from the MIDlet
- Smaller amounts of persistent data (like configuration options etc) is easily stored using RMS
If the solution is complex, and especially if it's a community solution, the main "intelligence" is probably on a server anyway, so there are a lot of applications that don't need local read/write file access.
Steve Jobs has an an interesting view on Java:
"Java’s not worth building in [to the phone]. Nobody uses Java anymore. It’s this big heavyweight ball and chain."
Almost all phones released today have at least Java ME / MIDP, and the MIDlet development community and sales are thriving, so Steve is of course clearly and completely wrong.
Again, there are a lot of issues with developing MIDlets, but it's too easy to say it's all bad, when it's only partly so. Also, being available in so many phones means developing a MIDlet is given for services that need good user and phone interaction, something Google and Yahoo! have endorsed fully. Even for corporate applications/services MIDlets might be the best choice, as most users will have phones with only Java, and not Symbian OS. Even BlackBerries run standard MIDlets. Even so, try to stay away from later JSRs in general.
Nice post. I should say though, that I'm not dismissing mobile Java at all. It has a great future (I wrote about it here ), however at the moment I can see a lot of difficulties that J2ME developers have to face to make their midlets to support multiple products, even if from one vendor. That makes me wonder if there really is a single platform, and not a collection of related but incompatible platforms.
Regards,
Ivan Kuznetsov
As you say, even within one manufacturer's line-up there are considerable differences between phones, not all because of Java though (more below). Especially manufacturers that haven't standardized on one Java implementation (e.g. Samsung uses anything available) have this problem.
That's why I think abstracting platforms (like Celsius, J2ME Polish, widget platforms etc) will become increasingly important, and larger development houses have already adopted such, licensed or in-house developed.
Sun could also help here, by putting more pressure on KVM and JSR providers (which includes also phone manufacturers that make their own KVMs) to comply with standards. As that compliance is verified via TCKs, that show increasing signs of not covering all there needs to be covered, compatibility might actually deteriorate as functionality quickly advances. Note that JSR-specific TCKs are developed by individual JSR providers (often phone manufacturers) and not by Sun or any other central institution. Not that the latter would warrant better compliance.
Sun could also help by becoming the sole provider of KVMs and class libraries (similar to SE and EE), and those would be used as-is in phones, but I doubt that will ever happen.
Another big issue, and maybe the biggest, is that even though a KVM might be TCK compliant, an integration thereof might not. Most of the functionality for e.g. MMAPI is in the phone's system software and hardware, not in the Java adaptation layer. Same goes with UI widgets, Bluetooth etc.
Smaller developers have a lot to gain from using the features available in CLDC 1.0 / MIDP 1.0, to minimize risk for incompatibilities. Hence there's a common denominator of sorts, but when you start to fan out the problems start as well. Also a smaller developer has no chance to test on many handsets, and new ones are released every day.
Actually I developed Converter Pro using only 1.0 features, so it's possible, also for non-games.
Post a Comment
Links to this post:
<< Home
