JavaME

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

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

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 ?

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