line of site

new blackberry development available for LBS

Research In Motion has released a new version v4.0.1 of their SDK which is focused on functionality surrounding Location APIs. These APIs are only supported on the BlackBerry 7520 on the iDEN networks such as Nextel and Telus, but offer a nice differentiator from some of the other smartphones that RIM now seems to be competing head on against.

for developers it can be found at:

http://www.blackberry.com/go/JDE

a few more takeaways from GDC Mobile

a few more random thoughts from GDC Mobile:

- a lot of money is being poured into the mobile games space. with the IPO of Jamdat, and EA "in the game" with 35 people, it's raised the bar for developers that want to deploy through a carrier. it's pretty much a requirement to support every handset, and you have to support the five major languages in Europe to play there

- development gets challenging when you have to develop for both mass market and leading edge devices...but you do if you want the business model to work. mass market devices drive most of the revenue, but leading edge devices drive people toward your applications

- there's a lot of people struggling with the X x Y x Z problem of an application that has to be provided for 2-3 screen profiles X 2-3 platforms X 2-3 languages and making this scale. sounds like WAP all over again.

- huge representation from Europe and Asia attended - not surprising.

Nokia Ventures launches new $350MM venture fund; changes name

Nokia Venture Partners today announced the launching of a new $350MM Venture fund, and has renamed the firm Bluerun Ventures. Nokia will remain an LP in the fund according to the release.

There is definitely a lot of interest in mobile in the VC space right now, so if you have an idea, get it out there and funded if you are so inclined.

lack of backward compatibility in symbian 8

i guess i'd have to look into the APIs to figure out what changed, but i am noticing more and more native Symbian apps that do not work on the Nokia 6630, which runs Symbian version 8.

I've noticed one of my favorite freeware games, Triz, does not work on the 6630, along with HanDee GTuner.

I've talked to the folks who make HanDee GTuner, and it appears they don't currently see the ROI to puchase the hardware to re-test this. Oh well.

I guess when dealing with a phone OS, you can't afford to allow the OS to bloat to handle backward compatibility forever as new features are added.

Selfishly, my real concern is that this will make it difficult to release a new N-Gage based on Symbian 8. Nokia chose to make the QD backward compatible with the original N-Gage, because on that platform, all the best games are deployed on memory cards.

A Symbian 8 N-Gage with UMTS would be killer though...

SEMC S700 and K700 J2ME root certificates missing

i'm putting this here as so others can find this - but it's come to my attention that there's a slight snafu (i hate using military terms, but it's appropriate) with the Sony Ericsson S700 and K700 handsets that have already shipped: they are missing any type of root certificate for J2ME.

This means that these handsets (which can only be extended via J2ME) will have to prompt the user for network actions and multimedia access even if the partner is trusted - which generally will become an issue for any usability minded application developer.

In practical terms, it means these handsets are best for deploying unconnected games, but not terribly useful for deploying business or informational applications that need to connect to the internet.

Upgrading the firmware will take care of the issue so hopefully SEMC fixed this before shipping the S710 to Cingular. I'll take a look pre-production version to see if they did and report back.

FileConnectionAPI works on Nokia 6630

i've been trying out the FileConnection API for J2ME (JSR-75) on the new Nokia 6630 and glad to report it works as advertised - you can browse, add and delete files from both the phone memory and memory card.

of course this is pretty big news for J2ME which generally lives in it's own little world. this will be key to getting more mainstream J2ME apps that aren't games to market that don't have limiting features. I think this is also available on one of the Nextel phones as well.

for those on the techhy side, this just exposes "file://" as a protocol and adds some directory listing functionality.

for the sake of others that might try this out - you need to make a change to Nokia's example in the .jad file (add the following line):


MIDlet-Permissions: javax.microedition.io.Connector.file.read, javax.microedition.io.Connector.file.write


nokia releases python for series 60

Python for Series 60 has been released on Forum Nokia. Python is a runtime scripting language that runs on top of the Series 60 C++ libraries, and provides a level of abstraction away from the core Symbian libraries, but still providing access to the native widgets such as tabs that are unavailable to J2ME programmers.

Inlcuded in the package is the runtime itself, and documentation with examples including the new "Hello World", and RSS Reader. The old Hello World is there too.

The downside of the Python environment is the necessary inclusion of a runtime when deloying applications, which right now is not built into the Series 60 platforms. It does come with an interesting bluetooth debugging console that allows live debugging on the phone.

My initial take is that this dev environment will still be difficult for the average programmer...I'd wait for version 2 or integration with Metrowerks, Nokia's IDE for Symbian development.

EA dumping Madden? say it isn't so

Gamespot is starting a rumor that EA could be ending it's fifteen year relationship with John Madden as the sponsor of their NFL game. Considering I still have a copy of "John Madden Power Football" right here on my shelf for the IBM AT, this is clearly Childhood's End for me. The end of an era.

I know John's old, and you are sick of putting him on Amtrack to do voiceovers, but c'mon, he doesn't have that many years left. You'll miss him when he's gone.

What seems to be less of a rumor is that EA signed an exclusive deal with the NFL for the teams, logos, and player likenesses - pretty much crippling all other NFL football video games.

Who wants to quarterback the Eagles with "Dominick McNabe"? No one, that's who. Put a fork in 'em, they're done.

thanks again, SE dev program

i've talked before about the sony ericsson developer program and they're keeping up the good work.

cool tchotchkies this quarter - yesterday i received in the mail a free "wi-fi sniffer keychain" along with a great whitepaper on Java Mobile 3D.

it doesn't take much to keep your developers happy - every device manufacturer should follow this model.

obfuscation

one of the interesting things about google's suggest service is that the javascript is obfuscated to reduce it's size (see http://www.adamstiles.com/adam/2004/12/hacking_google_.html) and save bandwidth.

this is also a great trick in general for J2ME development, also for reducing code size as well as covering your assets. for those of you that don't know, obfuscators take source code that is readable like public pleaseDoSomething{ doThisFirst(); doThisSecond()}; and turns it into public a{b() c()}; This makes things smaller, but also makes your code difficult to read by decompilers.

we've been using obfuscators forever to scramble our code, but not all obfuscators are created equal. recently we switched from using Retroguard to Proguard and saw an application that was originally 80K and was shrunk using Retroguard to 62K shrink down to 40K with Proguard. That's pretty dramatic.

Proguard is impressive in what it can do, such as removing all code that is not used, overloading as many methods with the same name and different return types as it can, and removing all the package declarations in your runtime code where possible.

Highly recommended so far, and it's free!

yet another rev of the Nokia 6600 known J2ME issues

Nokia should really do the right thing, and recall this phone - or offer everyone a super discounted 7610. The Nokia 6600 was the buggiest phone released, ever. There are class libraries out there just for dealing with workarounds on coding for this phone.

Nokia 6600 Known Issues

JBenchmark J2ME Result Database

I was doing some J2ME testing on the Audiovox SMT 5600, which ironically is a Windows Mobile 2003 device with the Intent JVM OEMed, and noticed that the JVM was very very fast. So i did a little googling and found the awesome JBenchmark result database which lists a few phones with this Intent JVM near the top (the Orange SVP C500 is essentially the same as the Audiovox SMT 5600).

Their benchmark tests are mainly graphics oriented, and our apps are generally database oriented, but a correlation definitely exists.

This site is a great resource for planning launch rollouts, especially where tuning comes later .

Sony Ericsson Phones now support SVG

Sony Ericsson Developer World has issued a release on their support for Scalable Vector Graphics (SVG).

At the time of writing, the following Sony Ericsson handsets support SVGT:

* K700i/K700c
* K500i/K500c, K506c, K508i/K508c
* S700i/S700c, S710a
* Z500a/Z500i/Z500c
* F500i
* V800

Blackberry 4.0 now MIDP2 capable

Yesterday Research In Motion announced the release of their BlackBerry Development Environment 4.0 which includes support for MIDP2 applications in addition to the proprietary BlackBerry APIs. I'll be digging into this over the next few days and reporting back.

It will probably be awhile before 4.0 is running on many BlackBerries, but this hopefully will open up the platform to a whole slew of additional applications and games. I imagine a port will still be necessary, as the key configurations are so different on the BlackBerry than most phones; not to mention the scroll wheel.

Nokia releases examples MIDP file access

Nokia has released an
Introduction To The FileConnection API (With Example) v1.1 which shows an example of how to access native device resources from J2ME. As always, they include some Nokia specific extensions:

these APIs are oh so important to bringing J2ME up to the level of C++ for Series 60 Symbian development. Unfortunately, we won't see a widespread rollout of this for quite some time...but at least developers can start working with this now.

what RIM's 2 million BlackBerry subscribers means for developers

Resarch In Motion has announced that they have two million BlackBerry subscribers, and that it doubled in less than ten months. that's pretty good, i remember a few years ago they said they had 400 thousand, which didn't seem like that much to me since everyone i knew carried a blackberry, and everyone i seemed to see on every plane i was on also had one.

for mobile developers, 2 million is a pretty small number. to put that in perspective, a small regional carrier like U.S. Cellular has about 2 million BREW enabled handsets.

the key is, BlackBerry users are definitely quality subscribers who are willing to pay for data services, and would probably also pay for quality appllications to run on the handheld. i hear from a lot of people that there aren't many applications for their blackberry and they wish they had more games to choose from...so if you are a developer, this might be a ripe market even though the numbers look small!

nokia shows more known j2me issues with 6600

Just another update to the Nokia 6600 Known Issues document from Nokia.

The 6600 is a disaster to develop J2ME applications for because of a couple really, really, bad firmware releases.

Included in the new known issues are:

2.26 MIDlet Installation Problem Description In very rare cases, installing a MIDlet to the Nokia 6600 smartrphone via OTA or Web Push may for some reason fail in the middle of the installation process. If installing a MIDlet to the Nokia 6600 smartphone via OTA or Web Push for some reason fails in the middle of the installation process, the half-installed MIDlet cannot be removed and the same MIDlet cannot be installed to the device. However, this happens very rarely.

They say this happens "very rarely" but this happens all the time for me!

look at the j2me speed of the 6630

there aren't any new tech tips on optimizing J2ME in this document from Nokia Technical Note: Tuning Up Java(TM) MIDP Performance - but check out the speed in these performance tests of the of the Nokia 6630 compared to that of the 6600!

Sony Ericsson says the plan to support MIDP2 development on OS X

Mikael Nerde, Head of Sony Ericsson Developer Program said this morning that SE plans to support development on the Mac... first in Q4 on DRM and content packaging tools, then SDK support at a later date. No date committments were given.

Also he said "i'll stick my neck out and say that [ JSR-175] will be available sometime in 2005." JSR-175 allows file access to the device which is otherwise prohibited in J2ME...

more on preminet (nokia's J2me etc sales platform)

Ewan at AAS has added his commentary on Nokia's Preminet announcement....

I'll add a few comments of my own.

Developers are driven to BREW not because it's a cool platform to develop upon (it's not) nor because it's an easy platform to develop upon (it's not) - but because the economic model works.

For the most part, Qualcomm sets the revenue share for the operators, as well as all the billing and settlement, and make it very easy for subscribers to get, use, and pay for applications. The pay for part is key - as most applications have monthly subscription fees. So instead of an X x Y model, it's an X x Y x Z revenue model which looks a helluva lot better in any business plan. The result is once you get over the barriers to entry, BREW has been very lucrative for the successful developers. Much more so than handango, which can basically adjust their percentage however *they* need to make money.

Secondly, they will be using the Java Certified and Symbian Signed QA qualifications to get applciations listed - which is a giant pain in the ass and expense for developers - but better for operators (lowers customer support costs) and subscribers (they generally get applications that don't have bugs or memory leaks) which of course helps operators (lowers customer support costs).

If Nokia is smart, they will work hard to make this as cheap as possible for the small independent developer who doesn't mind the aforementioned pain in the ass. There's no reason to bilk developers for unnecessary electoronic signatures (Verisign).

Acutally RIM requires a signature but their fee is $100. This is much more reasonable than $400 for an independent developer.

Finally, i certainly hope Nokia has the foresight to not allow operators that choose Preminet to lock their devices from shareware and installing applications from other sources such as handango. This would be a crying shame.

If you own a device, you should be able to choose what install you run on it. period.

Preminet vs BREW?

News.com is reporting that Nokia announced a system they say will compete with Qualcomm's BREW system. I wasn't at CTIA today (i will be there later in the week) so i didn't hear all the details, but it will be interesing to see how Nokia thinks they can sell an equivalent system to operators, and which operators they will be targeting such a system at.

Will they require the same level of QA that BREW does, except on the J2ME platform? I assume they will have to put the same kind of vending machine solution onto the phones themselves and allow subscription models for ringtones and applications.

I guess most Nokia phones now have a "Download" menu item that isn't hooked up to anything I have ever seen - but most of all, how does Nokia sell such a system being a non-neutral party? How do they get Sony Ericsson and Motorola to support their system?

I'll report back more when I learn more...

the best J2ME developer program

whether we like it or not, support for J2ME from operators, hardware vendors, and SUN for that matter generally sucks. so if you have to join one developer program, which one should you join?

I mean, at the free level, you should join them all. are any of them worth paying for?

I think the Sony Ericsson Developer World Core level is worth joining, simple for early access to all of Sony Ericsson's devices. The whitepapers are pretty good, and the developer forums are moderated somewhat from SE or metroworks personnel - so you can for the most part get answers from the source when you have a serious question. plus they send you cool tchochkies every quarter.

I wish that Forum Nokia had this level of support and access to their devices, but they don't. They have good examples and whitepapers, but the forums are filled with people asking newbie questions that never get answered, leaving them generally useless.

J2ME and "missing" PUT/DELETE HTTP verbs

i've finally bumped up against this famed omission in the J2ME libraries, which as you might guess, quickly rears its ugly head when doing anything with the Atom API. the MIDP1 and MIDP2 libraries only support GET, POST, and HEAD with HTTP, which is totally idiotic, especially when you look at the reference implementation source:

from com.sun.midp.io.j2me.http.Protocol

    /** 

     * Set the request method of the current connection.

     *

     * @param method request method is GET, HEAD or POST

     * @exception IOException is thrown if the connection is already open

     * @see #getRequestMethod

     */

    public void setRequestMethod(String method) throws IOException {


        if (state == CONNECT_STATE)

            throw new IOException("connection already open");

        

        if (!method.equals(HEAD) && 

            !method.equals(GET) && 

            !method.equals(POST)) {

            throw new IOException("unsupported method: " + method);

        }

        

        this.method = method;

    }

okay, great, so for no particular reason you just call it "unsupported" and then just set an instance variable which gets used

        /*

         * Note: the "ref" or fragment, is not sent to the server.

         */

        if (http_proxy == null) {

            reqLine = method + " " + filename

                + (url.query == null ? "" : "?" + url.query)

                + " " + HTTP_VERSION + "\r\n";

        } else {

            reqLine = method + " "  

                + protocol + "://" + hostAndPort

                + filename

                + (url.query == null ? "" : "?" + url.query)

                + " " + HTTP_VERSION + "\r\n";

        }

by just writing it out to the HTTP stream. i think if this allowed PUT it would just work....

well, okay, plenty of ways to work around this at lower levels or by delegation (subclassing would be great, but class bootstrapping isn't standard, especially in the JBlend VM that is used by the likes of crappy motorola phones and such...i'll see what i can do).

i also love how there is no Properties object defined in the MIDP APIs, but the first thing SUN does in there reference impl is create one...why not just include that too? jeesh.

Blackberry Java and other thoughts

thanks to everyone who has been beating the hell out of our RIM Blackberry Mobile Feed Reader - there is clearly demand for this application on this platform so stick with us and the official release will be worth the wait.

we released this basically to test on which networks the blackberry can access the network and where it cant - and the good news is most enterprises do have their gateways configured to allow access, and consumers who puchase directly from the carrier are in good shape as well. Verizon is the one exception, but we have a solution for that which will be available in the next build.

Most of the comments have been around the UI, which was a straight port from our MIDP1 version for mobile phones with a couple key tweaks for the blackerry.

Although MIDP runs on the blackberry, i don't think it's totally appropriate. blackberry users expect the user interface to act a certain way based on their experience with the other blackberry applets, and a lot of these things you just don't have control over on the blackberry MIDP1 platform.

With that in mind, we will look seriously at putting a native blackberry UI on the application, which should give you a lot more control over the menus and defaults and such.

this is an emerging trend anyway - your UI has to be custom for the device whether you are developing on BREW, J2ME, Symbian, etc. I was at a meeting at Verizon last week where they were looking at a bunch of application prototypes - and any application that looks remotely like a WAP stack met with high criticism. custom studio looking UIs - apparently, the people have spoken.

deep into BREW

sorry for the lack of quality posts and reviews these days - i've been bogged down deeply in the release of our CNET co-branded BREW Mobile News Reader powered by FeedBurner.

I've been involved before in launching a BREW app, but this is the first time I've been responsible for it end-to-end, and let me tell you, this is one cumbersome process...not only on the NSTL testing side of things, but in all the documentation that has to be generated to deploy on the individual carriers. you can see why there are so few BREW app companies, the barriers to entry are huge, but we are almost there, and you'll be able to enjoy the app and content provided by CNET (as well as your own RSS and Atom feeds) very very soon.

on another note, we're really busy here at FeedBurner readying our ability for you to advertise in your RSS feeds. If you, my readers have your own blogs that you would like to trial advertising in your RSS feed with, email me and i can put you on the list of the priveledged few who will get to trial this service over the next few weeks before the official launch.

P910 J2ME capabilities

i found in the developer doc what's improved on the J2ME side of things between the sony ericsson P900 and the P910:

The P910 Series offers the following upgrades on Java functionality compared to P900:

• All mandatory parts of the Joint Technology for Wireless Industry (JTWI) R1 specification ( JSR-185) supported


• API support added for Full Screen Canvas, vibrator and Backlight


• Access to IMEI number and software version

All exciting stuff. for more info on JSR-185, see Understanding JSR-185 by Jonathan Knudsen

Access the SIM card from J2ME applications [via Michael Yuan]

A huge pet peeve of mine is the fact that J2ME apps are crippled compared to native programming counterparts. I think the whole J2ME sandbox is an outdated idea that should just go away. You should be able to do anything in J2ME that you can do with C++, period, full stop. if you can write malicious code in Java, you can write it in C. Maybe the answer is that devices should implement the Personal Profile - but they don't so it's a moot point. J2ME is optimized for games, and building any other app is possible but an uphill battle.

Given this is a standardization layer- and it will probably take another year before manufacturers support JSR -177 - but there are certainly J2ME applications that can use this functionality now.

link:
Access the SIM card from J2ME applications

can anyone find the preverify source for MIDP 2.0?

the lack of MIDP 2.0 on OS X is getting a little stupid. if someone can find the preverify source for 2.0 - please send it my way. i've done some looking but am looking to the community... yes, i'm well aware of the MIDP 1.0 implementations and where that source is.

new MIDP 2.0 phones have some cool features

MIDP 2.0 is really looking up on the newsest handsets.

Nokia looks like they really have a solid implementation that shipped with the new 7610 - platformRequest() as well as all the camera APIs seem to work great - and they've started to include some integration with other parts of the Symbian Series 60 OS. for instance, if you tag an input field as being for email, you can insert an email address from the contacts application instead of having to type it in. that's great.

My first impressions of the Sony Ericsson K700i are great as well. the first thing you notice is how fast J2ME applications run. this phone seems to have plenty of speed and memory. the most impressive thing to me, however, was the new Java 3D API that's included on this phone. the Micro 3D implementation is impressive with the 3D tennis game they included on the phone as a demo and supports 3D models and texture maps. this game is one of the best looking phone games i've seen on any platform, and it's playable too! i wish i had more time...it's been awhile since i've done any 3D graphics programming but this API looks easy enough to give it a try.

i'm just glad that maybe i can stop ranting about how MIDP 2.0 needs to come of age. on both these phones, this is a really good step in the right direction.

handango lowers commission

handango has lowered its commissions to independent developers from 70% to 60%. is this a sign that their business model isn't working? that's the first thing that comes to my mind. handango allows developers to sell mobile applications without the carrier getting a piece of the action, but is more difficult for most users to download applications.

selling through carriers obviously is working, as JAMDAT announced it would IPO and developers i know distributing through the qualcomm BREW infrastructure are all making decent money on their apps.

and for comparison, the BREW infrastructure pays the developer 80% of the retail price, and these are usually subscription based. so with that in mind, 60% looks less and less attractive...which will drive more developers to do the extra work to distribute through carriers. given, that's all some carriers are paying as well, but with elevated startup costs.

this usually entails joining the carrier's developer program, paying a fee (~=$500), and also purchasing a certificate from verisign (~=$400) - so you need to sell quite a few apps to get a return on investment.

frustrated with MIDP 2.0 compatibility

it's still interesting to me how different the MIDP 2.0 implementations are - the same jar that runs great on the Sony Ericsson P900 and K700 (this phone rocks) doesn't work on the Nokia 9500 nor the motorola V300/400, and doesn't work for totally different reasons. Sometimes a build works on the Nokia 6230, some builds don't. and their SDKs and emulators don't help a lot, as they are mostly just skins over the same back end.

so much for write once, run anywhere.

motorola releases more iDEN MIDP2.0 Handsets

moto releases kits fori285, i325, i830

What's new for Java developers in Symbian OS v8.0

find out here.

still not as fully functional as the C++ APIs but getting there with some file access capabilities. meanwhile, can we get some more MIDP2.0 phones to market?

more on MIDP2.0 platformRequest()

from the symbian FAQ, there appears to be some new firmware for the Nokia 6600 that has fixed the problem with platformRequest() (namely, that it didn't work at all)... 4.09.1. great. how does one get that?

the faq is here:

Do Symbian OS based MIDP 2.0 phones support the platformRequest(String url) method?

also, russ tells me that this has also been fixed on the series 60 firmware that comes on the Nokia 7610.

MIDP 2.0 for Palm officially released

the IBM websphere micro environment with support for MIDP 2.0 has now been officially released on the palmone website. it runs on Palms with OS 5 and and ARM processor, specifically the Treo 600, and the Tungsten and Zire lines.

i'm not crazy that the VM isn't bundled with the Palm OS...that seems like it would have been a better deal for both palm and ibm. hopefully, it will be bundled in the future.

If you already have a J2ME app, conversion to the palm plaform is pretty easy, although there are still a few "known issues" that developers need to work around.

we did it with our FeedBurner Mobile Feed Reader - so if you have a Treo 600 or a Tungsten C, try it out!

sony ericsson announces 3 new MIDP 2.0 phones

Z500	K700	S700
GSM/EDGE 3-band 65k Colors MIDP 2.0 MMAPI + WMA Java 3D Push-to-talk	GSM 3-band 65k Colors MIDP 2.0 MMAPI + WMA Java 3D	GSM 3-band 262k Colors MIDP 2.0 MMAPI + WMA Java 3D
consumer link	consumer link	consumer link
developer link	developer link	developer link

three new MIDP 2.0 phones on the horizon - note none of them are symbian phones - which is good news if you are distributing J2ME apps. they all also support the Java 3D API for gaming.

let's hope they can get these into the hands of developers soon. that's usually about 3-4 months after they are available on the grey market. they just started offering Z600s to developers last week!

new release of palm midp 2.0 sdk (beta 3)

on my asking palm has posted the next rev of their midp 2.0 sdk. EVEN THOUGH THE WEBSITE SAYS BETA2, when you download the file, it's actually BETA3.

instructions on how to get it are still the same and can be found here.

just where is the Palm MIDP 2.0 public beta?

i've gotten a bunch of emails from people who haven't been able to locate the Palm MIDP2.0 beta.

first, you need to register as a developer with palmone.

then, it's on this page:

http://pluggedin.palmone.com/regac/pluggedin/auth/Java1.jsp

second one down:

Version: Public BETA2 (ARM only)
Date Released: February 20, 2004
Size: 7.3mb
Description: Runtime, Packaging, and Debugging Tools for Java 2 Micro Edition support on palmOne devices. Beta2 includes support for OTA and AMS.
Device Support: Zire 71, Tungsten T2, Tungsten T3, Tungsten E, Tungsten C, Treo 600
J2ME Standard Support: Connected Limited Device Configuration 1.1, Mobile Information Device Profile 2.0

at this URL:

http://pluggedin.palmone.com/regac/pluggedin/auth/ViewDocument?app=pluggedin&docId=1113

more on palm MIDP 2.0

the second beta of the palm/ibm MIDP 2.0 implementation is looking pretty good. i mentioned the release the other day and now i finally had a few minutes to try it out on a real device. These screenshots are from the T-Mobile version of the Handspring Treo 600.

platformRequest() worked out of the box, and is probably the best implementation i've seen. on this device, MIDP smoothly launches the blazer browser and quckly loads the reference. very smooth.

the application that performs the plaformRequest() seems to exit however.

the other bugs that are apparent in this pre-release developer version are some selection focus bugs in the List implementation. a few times i had one item selected, but the actual selectedIndex() seemed to be set to a previous selection.

performance of this application anyway, was better than on the nokia 6600, probably about the same as the SE P900. this implemenation uses the IBM J9 VM.

also, i don't know if this will change - it doesn't appear that the application can run in the background on the palm os. switching focus of the application seems to require a restart - so the J2ME app has to save its state.

good to see MIDP 2.0 will soon have another home.