One of the parts of JavaME development that always pains me is that for such a resource limited device, in particular when accessing radio networks, is the fact that the zip api is not exposed as standard (despite the fact that the files contained in the JAR itself are zipped)
One of the great aspects of frameworks such as LWUIT and freely available information with regards to device groupings, is the promise of finally achieving the nirvana of “write one run anywhere” or the new idiom which seems to be “write once deploy anywhere”
Thankfully we do seem to be leaving the dark days of fragmentation in the Java mobile world behind us, it is fairly easy to get lulled into a false sense of security.
Shai’s closing comment on the article highlights the sort of “discovery” that device specific information, when not in the public domain, may cause many developers to burn time.
To quote Shai:
Applications are expected to explicitly declare their support for touch to utilize the full screen of the device. This is done using the following Jad flags:
Navi-Key-Hidden: true
Nokia-MIDlet-On-Screen-Keypad: no
MIDlet-Touch-Support: true
Notice that the last entry (MIDlet-Touch-Support) is required by current/older Samsung/LG devices but is illegal by the MIDP specification hence fails on Nokia etc. so for support on these devices you would need a copy of your JAD (only the jad) with this attribute added.
For those of your that want Simonmaddoxs 0870 application for your Blackberry, Samsung, Nokia or LG Java enabled phone using LWUIT, this was put together during the night, so might be a little rough round the edges, so would welcome feedback via comments please
Congratulations to Spotify on the launch of their mobile client for iPhone and Android, Videos of which can be seen below
iPhone Video
Android Video
One thing that strikes me as a little odd though is the amount of coverage this application is getting, if I want a DRM music solution for a mobile phone there is another option, Nokia comes with Music which wont cost £120 a year…..
Maybe the catalogue is much better on Spotify this is obviously enough of a draw, I have been pleased with Spotify and even paid for a few day passes, so would be tempted to purchase a subscription to utilize this on my G1 if it had a standard headphone socket (I seem to consume ear buds in my sleep) or if the iPhone if it could play in the background, as the times I am listening to music on my iPhone is usually on the train when I like to clear email etc.
Maybe this has all come down to clever marketing on the part of Spotify compared to a seemingly more complex solution even though it is easier Comes With Music solution
Sonys Walkman phones would be a seemingly obvious addition as well going back to one of my earlier posts!
Erik Starck posted over on his blog at Sony Ericsson about the fact that Spotify will not be releasing a J2ME client until the user experience is good enough,
These thoughts are from an ex Sony handset user, my last four handsets have been as follows W800 -> K800 -> iPhone 2G -> iPhone 3G and when developing for J2ME the Sonys are always my reference device of choice (Since Jp3 and the K700)
I agree with Eriks comments that actually for a specific phone (especially a Sony JP8) its perfectly possible, with the utilization of modern libraries such as LWUIT to achieve an application that is as rich as the iPhone, especially for something like Spotify.
The problem here is that most people when they request a Java application, do not want a specific phone (iPhone) or family of phones (Sony JP8, Series 40 feature pack 3 etc), this is when fragmentation rears its ugly head and things get a little more difficult for people newer to mobile, as the write once run anyway promise breaks down rapidly.
The points Erik raises that are causing the headache for J2ME user experience right now can be broken down into certain areas
Signing
The fact that the alerts that pop up and alert the user for things such as http connection and saving to the file system are irritating, however the majority can be removed by self signing the application with a Verisign/Thawte certificate (however the root cert might or might not be present on a given phone) , submitting the application through the Java Verified process, this certificate is on the majority of MIDP2 phones but not all.
In the case of messaging however, you would need your application to be signed either with the handset manufacturer or operators certificate, the problem with the operators certificate is for the people who have transferred network or have purchased an open market phone, They will not have the operators root certificate present and therefore the application will be unable to be installed.
Discovery of application to install
Assuming you have managed to install the application, where has it gone? Apple really got this process spot on. After the user chooses to install something from the app store, the user then sees where the application will live, whilst it is installing, contrast this to the Nokia S60 experience and you can see the problem!
Then you run into the other problems that Apple have made easier for a third party developer
Worldwide Distribution
Favourable revenue share
Payment handled for the developer by Apple
Payment does not matter whether the user is accessing on WIFI or their cellular radio
Update process (achievable in J2ME but has to be coded into the application from the start and is not as pleasant)
Discovery of application
Device with a large screen, fast and plenty of heap memory
Educated users who know their phone is able to run applications
Trusting users who are happy to consume applications
Spotify should run well on Sonys and their developer program has long provided the following document which at least shows the promise of what a Java solution can enable if tailored for the Sonys, rather than employing the lcd approach to J2ME development. The problem of course then is there is a lot of handset groupings out there and tailoring an application for each platform needs to be done for a reason and unless the user experience is there for them to find the application once installed on their phone are they going to use it?
One thing is for certain though as the Java platform is open and you can self distribute, you can at least guarantee the application will be able to be placed upon the device it was developed for.
Spotify may say no to J2ME but Apple might say no to Spotify! (hopefully not)
For those of us that are experienced at dealing with the Samsungs this is great news. However if Samsung are hoping to stimulate applications on their platform, specific information on the APIs and any device specific nuances that are implemented in their phones would be very useful. Simple information such as maximum jar size for a given phone is absolutely vital for any would be developer and is sadly lacking at the moment on Samsungs developer portal.
Ideally any handset manufacturer should provide device groupings like Sony Ericsson do, this would enable developers to have an understanding of what phones their application might run on and therefore allow them to support more phones, which benefits the would be end user, the developer and the handset manufacturer if they wish to encourage the eco system.
However as this and other recent entrants to the current app store craze, Should take notes it has not just been the application store distribution model that made Apples app store a success…
For anyone else scratching their head as to what Strings are currently set as defaults, in the LWUIT framework, here is the complete list of things that need replacing if you do not use the inbuilt language tool
select
menu
cancel
ok
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
After attending FOM 2008 and seeing Tom Humes presentation on the strengths weaknesss and trade offs of mobile platforms, The slides of which can be found here
The mantra of fewer builds rather than customising for each individual handset where ever possible is something I have long believed in and practiced
I have always taken an approach similar to what Tom describes in trying to get any application in to as few rather than as many possible unique builds, usually using a combination of preprocessing and mainly through basing GUIs on the resources that they have available to them, be it fonts or graphics.
Whilst I can see how certain applications such as Trutap can achieve this with great success, (we ourselves have managed one application that only had 2 builds small and large, by using a clever graphics set, clever jad and conditional logic in the code).
What happens when conditional logic for testing APIs breaks down (JSR 205 on certain Samsung handsets for example) that will report availability, however will work with undesired results, To solve this we moved in to JAD parameters to conditionally switch our code.
However whilst getting the number of builds down the root of this problem is still that the team that is developing the application still needs to know all the niggles with J2ME, luckily as you state we are no longer limited to 64kb and sub 100kb builds where the conditional code was too “expensive” to consider including in a generic midlet and preprocessed out.
Layer on top of a now completed functional build signing via Java Verify, Operators, manufacturer or in house signing via a CA such as Verisign, all of which root certificates may or maybe not been present on a particular operator handset combination, and the necessity to bring builds down to a handful is very apparent
However is the effort not just being pushed up to the logical place of the main application rather than trying to fork for each build, with the main advantage being that for a tested, signed and certified application you already have support in a given build, rather than having to port for a fresh handset. This is really just leveraging years of experience into an elegant solution, for people new to the mobile market you quickly see the appeal of platforms such as the iPhone and Android.
These new platforms have effectively made the problem worse for J2ME once you get into the realm of connected applications as people are now expecting to be able to access their contacts, connect to a network and save information without having the continual nags of a Java application that even trusted third party signing does not fully negate!
For anyone who needs introducing to the headaches of J2ME, Intohand published a white paper back at the beginning of this year http://www.intohand.com/javamobilepdf.php
Be the First to Comment