Synaptic Technol ...

I got an e-mail from Matt Volpi over at Sun about this so here is his post... as usual, be helpful and download and test this extrememly helpful addition to the NetBeans platform.

*NetBeans Mobility Pack 5.0 Beta*
NetBeans Mobility Pack 5.0 adds several key new features to an already
powerful and easy-to-use mobile Java development tool, including:
Improved end-to-end support for building web services-based mobile
applications for any MIDP device, new custom components in the Visual
Mobile Designer, improved pre-processor support for device
fragmentation, editable generated code and improved emulator support.

NetBeans Mobility Pack 5.0 information and download instructions
  * http://www.netbeans.org/kb/50/mobility.html

I got my complimentary copies of "Pro J2ME Polish" by Robert Virkus a couple of days ago, so its about time I posted something on here...

Pro J2ME Polish, is an excellent book for JavaME (J2ME) developers, it explains a lot about the differences between devices and how to use j2mepolish to get around those problems.

Robert Virkus is the Lead Developer of Enough Software (www.enough.de) and J2MEPolish is their open source tools project which includes a LOT of useful utilities, preprocessing and work around code for the fragmentation issues that we all face. So check the tools out at www.j2mepolish.org and check the book at your favourite book store.

Pro J2ME Polish (amazon.co.uk link)

Oh and I wrote the foreword for the book.

During the latest re-organisation of the handango.com sites, it would appear that they have finally decided to drop support for J2ME applications. Selecting J2ME apps for Nokia 6600 devices now just shows the normal series 60 symbian apps.

I suppose this isn't really big news to anyone in the development community, as talking to a number of the gang over at www.j2me.org (which is now available at www.javame.org also - thanks to CEO) no-one I've spoken to ever had any realistic number of sales from handango anyway and everyone seemed to be dropping them as a useful sales channel for j2me anyway.

I just remembered I got this solved recently...

A lot of people (generally a long time ago, so maybe everyone else has solved it anyway) seem to have had a problem with the emulators not being able to create httpConnections when using a proxy server, this is how I've had it solved with Squid.

The issue is that Squid's default configuration denies specific (CONNECT) port access to port numbers other than 443 / 563 (https)..

To solve, you need to get your network administrator to modify the squid configuration:

modify /etc/squid.conf

modify the line:

acl SSL_ports port 443 563

add the port number you want to allow access to ... often 8080 to the end of that line and restart squid..

NOTE: This is a bit of a HACK fix, and you should really create a new "acl" and modify the following line:

# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports

to allow access for your new acl

Cheers

Kirk

While I'm still in the mood for ranting... here's another one.

Faults being fixed with firmware updates.

While I understand that writing perfect software is not technically possible, the solution to many, many jvm inconsistencies and performance problems has been a firmware update... That might sound innocuous enough, but think about it, how does the average user KNOW that a firmware update is available for their device ? For that matter does the average "NON TECHNICAL" user actually even know that the device requires firmware ?

Generally, the situation seems to be that if you phoned technical support for your device, they MIGHT know that a newer version of firmware is available to you, in practice I have heard of people calling technical support and the support people not even knowing that a newer version is available.

So, say we write a game for a device and if the user has the up to date firmware, then everything is fine.. however, if the user has an older version of firmware which still has a problem then the game may not run at all, run too slowly to be playable, suffer from unknown corruption problems.. Somehow I don't think that the end user is going to be happy with that, and who gets the blame for this problem... You the developer, the first the the user is going to do is blame you, delete your game and probably think twice about using you as a supplier again.

So, here's a few firmware updates:

• Sony Ericsson's T610, original firmware had pretty abysmal performance for j2me, my noted favourite was that if you had the device charging, the animating power indicator icon seemed to take too much processing and degraded the performance of the jvm to pretty much unusable in many situations (and added a nice flickering problem on repaints). Firmware upgrade improved T610 performance as you can see by the range of results on www.jbenchmark.com (115 -> 696 ) thats a significant difference.

• Nokia 6600, original firmware didn't support installation of signed MIDlets, this was fixed in a firmware update, I suppose this could actually be worked around by detecting the HTTP_USER_AGENT header and reading the firmware revision to redirect the OTA installation to a specific unsigned version.

Anyway, what I'm saying is that I understand that firmware updates are necessary, BUT and this is a BIG but, we need a better way of informing end users that a firmware update is needed.

I don't have a solution as such for this.. but, I have had a few ideas...

• Automatic updates OTA, like firmware updates for digital tv, they are sent OTA and automatically installed, I don't know if it still happens, but Orange in the UK at least used to do SIM updates at one point OTA. Problem, this won't work, too much bandwidth would be used, it would take too long and I don't think many people would be too happy with having their contacts lost as happens in many updates.

• Automatic notification by network operators... this is a possibility, the network operators COULD do a device detect on accessing their portal and if required tell you that you need a firmware update and where to get it (nearest update centre) and also tell you that if you don't do it you might have problems with some applications.

So, thats the end of that rant... anyone got any opinions on that.

Along the lines of the old java motto... "Write once, run anywhere"... those of us in the j2me development community all know that there are MANY inconsistencies between JVM implementations... and the problems that these cause for us all with having to write custom versions for specific devices. So here is my rant... (this actually comes from a reply I made on www.j2me.org)

I use folder names for each device type to hold the resources (images) and then set an ant property on build to the correct one and it includes the correct images...

In my opinion the big problem is more the non standard implementations and the inconsistencies that this brings:

• Some that DO call hideNotify() etc... some that don't
• Some that do have the ability to know when a sound has finished others that don't
• Some that do have the correct getHeight() getWidth() values, some that dont.
• etc...

Here's the one of the big problems in my opinion...

No list of known faults.. ok, some manufacturers do keep a list of some of them, Nokia for instance has their "known issue" documents, but what would be REALLY helpful would be something like a bugzilla for j2me implementations (which would include things like firmware revision details too !!!)

There HAVE been a few attempts at this in the past... the University of Dortmund had a web application which had some details, but its a bit out of date these days. Someone has started some sourceforge project, j2mebugs I think it was, which is along the right kind of idea. However, nothing exists "in the wild" for us to actually use, wouldn't it be EXTREMELY helpful if the manufacturers and jvm developers themselves actually let us know about things, even if it means just a press release or a known issues document that we can then include the details of in a database ?

I go back to my argument a while ago ... if the jvm vendors (and manufacturers) can't stick to a standard how do they expect the javaverified.com process to work for us ? The Technology Compatibility Kit from Sun, SHOULD test for these kind of problems and anyone who doesnt correctly meet the standard SHOULDNT be licensed... that said, of course there are sections of the specifications which obviously can be interpreted differently... but then ... that SHOULD be answered by the expert group for that JSR

Ok, you've read my opinion, now lets have yours ?

Jason Lam has been writing this e-book for quite some time, but thankfully he releases updates to it every so often. I keep pointing people on j2me.org and other community sites to this book (PDF) for insight and help with midp2 development.. so here is the link to it..

http://www.jasonlam604.com/books.php#j2megaming

Very good and for all those students out there that keep asking where they can get a free j2me book or tutorials, this is probably one of the best places to start.

For some time now I've been looking for an up-to-date list of firmware revisions for Sony Ericsson devices, I've even asked SE themselves via the forums and the core member surverys that they ask me to complete every now and then... Well here is some very useful information, www.esato.com have already done it for me and being a community it would seem that this is a good place to get the information relevant to different global markets too.... congratulations esato members.

http://www.esato.com/board/viewtopic.php?topic=35026#Firmware