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!

buy a unlocked phone

[johnjones]

plain and simple buy an unlocked gsm phone and buy a sim card

dont put up with suppliers that will not allow you to run your app's you should at least be able to download your app to the phone via a usb cable

the location and photo API's do seem very fun I have not tried them out and wonder how much is cross platform...

regards

John Jones

Cryptographic signing is not strictly required

[CTachyon]

Things might've changed since the merger with Nextel, but AFAIK there's nothing keeping you from distributing unsigned Java apps from your own company website. The user's phone will pop up a warning, of course, but it won't stop him/her from downloading and installing your app. Assuming you know all about JAD files and MIDlets, just point the user at the JAD file.

My biggest beef with Sprint is their crappy API support, at least on their older phones (my Sanyo PM-8200 supports only MIDP-1.0, and very few of the optional J2ME APIs).

Copyright Office rulemaking proceedings

[MCRocker]

Well, you missed the deadline for making comments to the "Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies" proceedings that the Copyright Office is conducting. Too bad. I'm sure your comments on this issue would have been more useful than mine were.

Perhaps you could still contact the Stanford Center for Internet and Society folks who were spearheading an effort to collect comments on cell phone locking and they could use your comments as an addendum or something.

Shout out to Lessig for his blog entry that pointed these folks out to me.

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.

Re:J2ME development issues

[bateleur]

I see what you're saying here and doubtless would've said the same myself ten years ago.

The reality is that Java mobile standards are horribly mired in politics. Whilst you might think that sidestepping all that nonsense would be a good thing, the bizarre truth is that experience has proved that to be wrong. Look at the original MIDP-1 standard. It was a pretty simple thing, even underpowered, yet still a great many devices shipped with MIDP-1 implementations which were not properly compliant. Almost as bad was the fact that many shipped with proprietary extensions. The standard was a commercial disaster for application developers because it was not actually standard at all. The people who mattered did not fully back the standard.

MIDP-2 is much better than MIDP-1 was, but still the same problems of weak implementations plague application developers. In an effort to keep this post impartial I won't name names, but the difference between the best and worst implementations is massive not just in terms of performance but in terms of compliance to spec. Sun's compliance tests are ridiculously ineffective.

Mobile apps desperately need proper standardisation to really thrive. Currently only large developers with the deep pockets necessary to port, test and distribute to multiple platforms can make any kind of money. Creating a good standard involves an awful lot of politics. Simply knowing a requirement exists is not enough to get it acknowledged. In my view, better a slightly flawed standard than no standard at all.

(In case anyone's curious, I speak both as a developer of Java MIDlets and as a member of the development team for a well known MIDP-2 implementation. My opinions are my own and not those of my employer, just in case anyone can work out who they are.)