Hi,
I was lucky enough to have access to a 6600 prototype phone for a couple of weeks for testing - and was very blown away by the quality of the new screen. (makes a 3650 screen look dull and washed out!)
However I had some problems with getting some J2ME API's/features to work correctly - as I was attempting to port some existing Series 60 MIDP1.0 apps.. (The phone takes around 10 second to reboot - which happens if you hit unhandled exceptions in your code!!) ...
So just wondering if anyone has any feedback to share on these issues (or any workarounds), or even news that the following is fixed on newer prototypes -
1) Unable to provide a .JAD file for a MIDlet - which unfortunately on this device means you cannot set the security attributes allowing access to Bluetooth/Camera API's in J2ME etc (which now are disabled by default).
When attempting to use Bluetooth from a J2ME midlet - I can discover/id other bluetooth devices/SPP's - however get a 'security' exception on the bluetooth API when the connection is made. (due to the above attributes not being set).
The 6600 did not have any WAP access working (browser etc from main UI did not function at all) - which in turn meant that you could not WAP-Push a MIDLet nor could you send a .jad file with the URL location of the applet. Additionally - you could not send in a seperate message with the .jad and another with the .jar file (an error would appear if you tried to install it).
Just to top it all off - the Applications program (used to specify security on installed MIDlets) - did not allow any security settings to be altered. (it just ignored changes)
On the good side - the GPRS/HTTP access inside the MIDLet and C++ apps worked (only way to get data onto the phone from the internet) ...
So the big question is - has anyone actually gotten a J2ME app to successfully discover and connect to another device via Bluetooth??.
2) Inability to use existing Series60 apps (or provide versions that degrade gracefully when not used on a 6600). This was mainly due to the missing Alpha Channel (native pixel format is USHORT_RGB_565 format - ARGB formats not supported under NokiaUI). Note that this pixel format is not supported by any emulators yet (although the new 7600 concept sdk supports a mode called rgb_444 which at least gives you a non Alpha mode to play with)...
This meant that the all my classes which relied on Transparency/Alpha channels stopped working (ie Graphical Font and Sprite Routines) - and had to be written using the really really slow MIDP2.0 Image/Graphics classes (using their 32 bit ARGB support).
I benchmarked routines using the MIDP2.0 stuff on the 6600 and found it was around 4-5 times slower then the equivalent call using NokiaUI - and of course not backward compatible with Series 60 v1. (It also means that completely seperate codebases must be maintained for the 3650/6600's.)..
The Image.getRGB call itself was the main offendor as it seems to have a very slow init/deinit time (ie. making a lot of individual calls to this function to slice up an in memory image is very slow - and much quicker to grab the whole lot at once and use System.Arraycopy to get the individual sprites from the int[] array)..
On a good note - the ability to replace/upgrade a MIDlet on the phone and preserve the RMS correctly was a real big bonus... (and saved a lot of time if your app must access it's information from the internet)
Anyone else with experiences to share on using this prototype (or even the finished thing)...?
Niall G
http://mobilewares.net
[email][email protected][/email]