I was delighted to be invited to be part of the panel this evening — and at only a few hours notice too (I only checked my email in the afternoon after getting back from holiday the previous evening). A flurry of tweets confirmed my place — thanks to Alex Craxton for thinking of me!
Consequently, the notes for this evening are briefer than normal, though the evening felt like it went fairly well. The topic was more technical than most Mobile Mondays and the suit percentage in the audience was very low. I hope we pitched the discussion at the right level. Thanks also to my fellow panellists: Simon Nicholson from Sun, Sergio Falleti from Future Platforms, Kieran Gutteridge from intohand and Andy Milloy from SurfKitchen.
There were a few new points raised (I’ll cover some below), but the most controversy in the room came when we got around to discussing app stores and the iPhone. There was the usual discussion around why the JavaME industry hadn’t advertised downloading apps until Apple showed the way — as Dan Appelquist put it previously, it would have been a documentary rather than a 30 second advert…
@fj questioned what Sun would be doing to catch up with Apple’s speed of development on the iPhone, but there isn’t really an answer — JavaME improvements come slowly as they involve multiple (often competing) companies working together through the often cumbersome JCP process. Apple can make changes daily. However, the JCP process eventually results in a large number of companies putting out lots of devices into multiple markets. This will inevitably cover a larger market than Apple ever wants to reach — @edent’s oft repeated point that there are many more low-level phones worldwide than there are smartphones will still be true for quite a few years yet.
As an audience member pointed out, not many of these low-level phones are used to download apps — it’s a big market but with no way of reaching it. I think this will gradually change, and we’ll start to see even the low-level phones having a reasonable JavaME capability over the next few years (this is definitely in Sony Ericsson’s plans). We’ll have to wait quite a while, though, as phones last a long time in some markets…
In other news…
Surfkitchen have recently developed a home screen app for Sony Ericsson phones on Telstra in Australia (called Telstra One). This plugged into a new API only available on those phones. I wonder how the new app affects battery life — and if it copes well, when this new API will be released. Sony Ericsson seem to be moving forward in JavaME in the way that the JSR community process cannot, but still creating an effective platform based on the JSR standards. I like their approach and I hope they do well.
Device databases
Sergio from Future Platforms said that they use the Java Verified list of device families and lead devices as a basis to categorise their builds. I wonder how often this list gets updated and how FP deal with newly released phones. This device grouping is something that should be part of a device database — something that’s sorely needed to enable developers to choose which builds to make in order to cover an appropriate range of devices. If you choose effectively you can massively reduce the testing required. Most development agencies have built their own databases, but aren’t that willing to share it as it’s part of their competitive advantage. The JavaME 3.0 SDK has a database included, but it’s not detailed enough and doesn’t get updated very often. J2MEPolish have an open source device database, but again it’s not updated that frequently and it also contains mistakes. WURFL and dotMobi have more up-to-date device databases, but they’re focussed on mobile web and don’t have the information required by Java developers. And developers need to be able to slice and dice the data to pick out appropriate pieces. Anyone for putting it all into a DabbleDB database?
New attack on fragmentation
One of the reasons that we need a comprehensive device database is that manufacturers implement their mobile Java VMs in slightly different ways. The existing official tests that mean they can put the Java name on their product seem pretty low-level and certainly don’t cover a lot of the user interface behaviour. Several manufacturers also seem to have a lower level of quality control for their Java implementations and bugs get through to devices with alarming regularity.
Orange, Sony Ericsson, Sun and Vodafone have got together to create a new set of tests, this time created by ordinary developers rather than JCP members. The aim of JATAF (you really don’t want to know what that acronym stands for) is to collect anti-fragmentation tests and release them as suite that can be run by manufacturers, operators and developers. I’m not sure whether anybody will be enforcing devices to pass the JATAF suite, but the participation of Orange and Vodafone is a good start.
Upcoming events
- Ecomo September 11th & 12th — there will be netbooks as prizes
- OverTheAir September 25th & 26th — still looking for more sponsors
No comments:
Post a Comment