- I was surprised with the breadth of platforms being supported rather than everything being just iPhone-centric. Each company had their own reasons for choosing their particular platform (or platforms).
- I observed that companies seem to be mainly developing for one platform then expanding out to others rather than attempting all at once. My thought is that this has the advantage of getting one platform right before doing others at the expense of time to market.
- It was interesting to hear TouchNote, who have a printable postcard service, say that their USP is that their service runs across all major platforms. My thought is that all-platform apps are attractive to carriers as they cover all the bases.
- RIM gave a demo of an eBay app , describing it as a ‘Super App’. This naturally includes notification and background apps that are BlackBerry’s strengths.
- I was encouraged by the number of demos that were either new companies or very new apps. Some hadn’t even released yet. There’s a lot of money being spent developing mobile apps at the moment.
- All the demos were predominantly applications as opposed to mobile web (Although some did have mobile web interfaces as well).
- It’s the first time I had heard of Orange Vallee. This is a small group within Orange that has the power/freedom to cut through all the inevitable bureaucracy in a large company such as Orange and efficiently create mobile solutions.
- One great quote from the evening is ‘Fragmentation is the cost of doing business’. Also, fragmentation is an ongoing thing. You need to be willing to support new phones/platforms every few months.
A very recent Admob publisher survey shows some interesting trends…
The report also shows that the majority of Admob’s surveyed publishers are developing for either Android and/or iPhone. BlackBerry, WebOS, Symbian, Windows Mobile and Java ME are currently much less popular. Also, more developers are now making money by using in-app advertising rather than selling their applications.
However, as the survey was from Admob, we might expect that their publishers might represent a greater proportion of those making money via advertising. Likewise, it could be said that Android and iPhone, where there are more applications, much lower prices and more competition between apps, might encourage the ad funded model. BlackBerry, Symbian and Windows Mobile apps tend to be sold for higher prices and might not need in app-advertising and hence be less represented on Admob. As with all these surveys, you also have to look at where they are coming from and compare with data from other sources.
At the beginning of February I took a quick look at the future of Java ME under Oracle.
Jaxenter has an informative article on Oracle’s "Write Once, Run Anywhere" strategy.
Some interesting observations from the article…
"Sun has prevented the adoption of Java SE on a large scale within the mobile phone market with its Field of Use Restrictions in TCK-licenses. This has resulted in a proprietary Java environment based on Dalvik on Android devices."
"In an ideal world, this unification would include Android. But this is unlikely: Android already has an established market."
"More transparency in the TCK tests and an open-source approach for TCKs would also be desirable."
"In my opinion, the lack of a really powerful user interface API is still the real weakness of Java ME. Even MIDP 3 is only a slightly revamped version of the outdated LCD UI. There are some proprietary alternatives, and Sun has also already launched its LWUIT UI project. However, none of these are standardised, and do not ship pre-installed on devices."
I personally think LWUIT has gone a long way to improve the Java ME UI. It doesn’t have to be pre-installed on devices as it is (just) small enough to be included with the application. The advantage of LWUIT is that it can be used in the billions of existing phones rather than waiting for new phones to have a pre-installed solution.
However, if Oracle unifies Java SE and Java ME then LWUIT probably doesn’t have a future. I suspect a newer or evolved UI will be produced that will be incompatible with old phones. Java ME will be ‘rebooted’ – much like Palm, Symbian and now Windows Mobile. Current strategy is such that a clean break is seen as the best way of untying platforms from their old problems and limitations.
In 2007, I observed that most of the few non-game Java ME applications that had become successful, performed most of their processing at the server. Last year I wrote about WebView applications and commented on how useful these are for some types of application.
WebView applications are just a web site embedded inside an application. It’s easy to create these on most platforms:
- iPhone as a UIWebView
- BlackBerry application as a browser field (v5 version here)
- Android as a WebView
- Windows Mobile as a HTMLControl (Win32) or WebBrowser (.NET)
With Java ME, up until now, you have had to hand-craft your own mini HTML rendering engine. However, LWUIT now supports a new HTMLComponent. This makes it much easier to create cross-platform WebView applications that include Java ME.
I have been looking into what’s planned for Java ME now that, as of the end of January 2010, Oracle now owns Sun. The webcast on Java shows a summary:
This shows that it will be ‘business as usual’ for Java ME.
Oracle have also announced they will be unifying Java ME with Java SE to revive the "write once, run anywhere" ambition. I suspect the Android Java implementation has had something to do with this decision. It shows how close a mobile Java implementation can be to Java SE.
However, I am sceptical we will ever get "write once, run anywhere" not just between server and mobile but between mobile devices. Mobile device capability varies too much. A new ‘more Java SE’esque version of Java ME certainly wouldn’t be compatible with existing phone runtimes. Also, old Java ME applications wouldn’t be (source code) compatible.
Oracle’s plans mean that there is likely to be a large compatibility break in mobile Java in the coming years. A break to a newer, more capable mobile Java is certainly what’s needed. However, I question how long this is going to take?
With all the hype over smartphones, iPhone and Android, mobile developers might be interested to know that I still get many leads for Java ME. Why? Well, I think this is mainly because it’s still the platform that will give the largest reach. Looking at the projects coming in, companies are considering Java ME for one of many of the following reasons…
- To upgrade an older Java ME application to improve features and the UI (usually using LWUIT)
- To port an iPhone (or other platform) application to Java ME
- To create an application that can currently only be done under Java ME (eg NFC)
- To create a vertical (usually business) application that will only be running on one phone model (or family)
Yesterday, a non-work friend asked me why there isn’t one programming language that covers all phones. They thought that it would have been in everyone’s interest to have a standard way of programming phones.
I explained how phone OEM and network operator selfish self-interest has resulted in the situation where each has tried to differentiate their offering by providing a different and competing solution. I also explained how, even with Java ME, the most common programming platform, companies provide add-ons just for their phones rather than championing something (a JSR) that might be used by everyone. Again, the thinking is that if it can be done on their phones but noone else’s then they have an advantage. Unfortunately, most developers ignore these specialised Java add-ons because they cause even more phone specific versions of their application.
Coincidentally, I returned home to read about yet another new Java ME add-on. The J2ME API bridge allows access to location, call logs and files related to sounds, images and video. The catch is that this only works on S60. It also requires the API Bridge to be provided as part of a .sis (Symbian) install.
In addition to the issues of fragmenting the Java ME development space, I question how many people will actually use the Java ME API bridge. First of all it won’t work on phones other than Nokia S60 where these things can be done natively anyway. Ok, there might be people who can only program Java. However, would they bother getting into Symbian territory to create a SIS file? How many of them would want their app working on S60 but not S40? How many of them would like to include a native component that might not work (who knows?) on future versions of S60? The resulting SIS has to be Symbian Signed if distributed, for example, via Ovi. Would Java developers really do (or even want to understand) this in addition to Java Signing?
Further to my recent post on the future of Java, I had an email from someone I worked with at Symbian when I worked on the Symbian Java VM implementation. He had attended a session at SEE2009 on the Future of Managed Runtime.
All Nokia S60 phones S60 3rd fp 2 and later include the IBM J9 VM. Nokia have done lots of extra work on this to make Java apps behave (from a user viewpoint) like Symbian native apps, improve performance and improve existing APIs. IBM J9 VM is now ‘the’ Symbian Java runtime.
The challenge for Symbian Foundation (and Nokia) is to open source the OS without infringing intellectual property rights or licences. Apparently, as expected, IBM won’t EPL their J9 virtual machine but they will allow third party developers who build their own Symbian ROM for the new TI reference platform to include a JVM for R&D purposes. Once they finalise their licensing talks with the foundation, phone manufacturers will still need to pay for the VM.
Hence, if phone OEMs want to include Java in the Symbian OS then the OS won’t be entirely free. From my experience on the the Symbian Java VM, I suspect plugging in a different 3rd party JVM to bring it up to the current Nokia implementation, would be a costly exercise.
As an aside, apparently Motorola gave away MIDP3 to Applix so maybe their one-year-old announcement that the reference implementation would be open sourced has become irrelevant.