Slashdot Mirror
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?"
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).
Range Voting: preference intensity matters
As stated above, there are plenty of uploaders out there that will allow you to upload your own programs. http://rumkin.com/tools/sprint/ is an uploader that will allow you to upload your own code (works with the A900...I've got one too). http://www.sprintusers.com/forum/ is the forum mentioned above that have a lot of Sprint phone user geeks...I'm sure a lot of people on there could help answer your questions. Here's a link to their page for alternate uploaders too: http://www.sprintusers.com/forum/showthread.php?t= 83030
= 52772&page=1&pp=15 what you are talking about regarding the Verisign cert. You can run your own code, but to access the GPS stuff you are restricted. Hopefully someone in the above forums can help you out to bypass it. I'll keep an eye out, because that sounds like some pretty cool hacking to do.
Additionally, http://www.howardforums.com/ has a lot of good information too. Here's an actual http://sprintdevelopers.com/ Sprint-centric development site too.
Although, most of this may be useless, because I see in this post http://www.sprintusers.com/forum/showthread.php?t
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.
Signatures are a waste of bandwi (buffering...)
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.