Posted by Kieran on November 5, 2009 under J2ME, LWUIT, Mobile, Uncategorized | 
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.
Read Shai’s full article, which includes some good tips on using LWUIT on touch devices http://lwuit.blogspot.com/2009/11/optimized-for-touch.html#ixzz0VvlYKZXm
Posted by Kieran on August 12, 2009 under J2ME, Mobile, iPhone |
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
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)
Posted by Kieran on July 14, 2009 under J2ME |
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
Posted by Kieran on under Android, J2ME, Mobile, iPhone |
Presentation slides from OpenMIC held in Bristol 2009
Posted by Kieran on under Android, J2ME, Mobile, iPhone |
Presentation slides from OpenMIC held in Bath 2009
Posted by Kieran on November 30, 2008 under J2ME, Mobile |
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
http://www.slideshare.net/twh/strengths-weakness-and-tradeoffs-of-mobile-platforms-presentation/
The mantra of fewer builds rather than customising for each individual handset where ever possible is something I have long believed in and practiced
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