Open J2ME Development Options? 32
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?"
Cryptographic signing is not strictly required (Score:4, Informative)
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).
Check out some of the uploaders (Score:3, Informative)
Additionally, http://www.howardforums.com/ [howardforums.com] has a lot of good information too. Here's an actual http://sprintdevelopers.com/ [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
Re:Check out some of the uploaders (Score:3, Informative)
Copyright Office rulemaking proceedings (Score:4, Informative)
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 [stanford.edu] and they could use your comments as an addendum or something.
Shout out to Lessig for his blog entry [lessig.org] that pointed these folks out to me.
J2ME development issues (Score:5, Informative)
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 [jcp.org]. 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 (Score:3, Informative)
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.)