Open J2ME Development Options?

loganb asks: "I'm currently holding in my hand a brand new Samsung A900 cell phone with a brand new EVDO data plan. I was initially excited about the OSS/free application development possibilities, as the J2ME stack on this phone supports the new Media, Location, and Messaging APIs. Much to my dismay, however, Sprint (my carrier) locks all the interesting APIs up tighter than a drum, and makes it nearly impossible to get an app to market. You need a $400/yr Verisign certificate just to download an app to a developer-enabled phone and you need a contract with Sprint to receive the certificate necessary to distribute the app (solely through Sprint's online store) to regular users. Of course that is not really an option for free/OSS programs, 'vertical' applications, or anything that doesn't neatly fit into Sprint's business plan. Thus, do any of the other national domestic cell providers allow unfettered access to the Java APIs on their phones? Is there any sort of hackery (such as buying an unlocked phone from Europe and using it on a domestic GSM network) that has an equivalent result?"

Comments

You can still return your phone and cancel Sprint

[antifoidulus]

if you got the thing less than 14 days ago. The law gives you 14 days to cancel if you don't like your service. As for unlocked phones, you don't have to import one from Europe, amazon sells them, as do a lot of other places.
Personally i would recommend T-mobile(since they are actually a European company!) and have fun!

J2ME development issues

[happynut]

I've read through the comments; I thought I would put in my 2 cents.

Several folks pointed out that you could get the midlet (the term for the type of app sprint runs) on the phone by hosting it yourself or downloading via a cable, and bypassing Sprint's site and the need for a developer's certificate.

They are correct, but they are also missing part of the story.

They part they are missing is: in order to use some of the APIs on the phone, your midlet must be "blessed" by the operator. Technically it has to say the protected features it wants access to and be signed by the manufacturer or operator. All this is covered in the MIDP2.0 (JSR-118) spec. I was a member of the committee that wrote that spec.

So, if you want to write a local game you don't need any of that magic: you can do everything you want via the "untrusted" (that is: unsigned) profile. But to do some of the more advanced features (like using GPS data, or being able to be woken up when not running - push registry) you have to be signed by the manufacturer or operator.

Anyone who's read to this point will probably have noticed that the folks who make the phone or sell the phone (manufacturer or operator) are able to bless applications, but the folks who bought the phone cannot. This wasn't an accident.

When the committee was working out the details of the protection model manufacturers and operators were well represented. The only third party developers present were companies that were beholden to operators. There were no end users or corporations represented, so their interests didn't get a lot of weight.

I don't think it was evil intent by any of the parties. Its just that went these standard committees meet each representitive makes sure their interests are protected, and those who aren't present don't get a voice. This is a very common problem for most standard committees; its not unique to the JCP or MIDP. But it does help to explain why you, an 3rd party developer is a second class citizen even for your own phone, let alone your customer's phones.