05 April 2007


The obvious: J2ME's suffered a lot of fragmentation (almost necessarily, given the ever broadening range of devices to which an application may be deployed) that have worked against the "write once, run anywhere" mantra. Particularly, Sun has proffered a multitude of JSRs that are considered "optional packages" that any vendor may (or may not) include in its platform/handset. There are so many JSRs (see, for example, this) that there are occasionally wrapper JSRs that serve only to include other JSRs. Thus, a vendor that implements JSR-185 ("Java Technology for the Wireless Industry") is really mainly only guaranteeing the presence of other JSRs. Similarly, plenty of platforms have solutions that later were standardized into JSRs. Thus, using a technology is a manner of gambling, where you hope you wager your target platform implements the requisite base platform, technologies, and APIs (that is, you want the JSR version of a given API where available, but if you need it you'll use a proprietary API, right?)

Sooooo... I have a Sprint handset, the Samsung A900 (this one.) Nokia and Motorola are easily "hacked". Sprint tends to control their handsets, closely, alas. The same rules as with any other closely guarded platform apply: no hacking! It's not necessarily in a carrier's interest to expose these APIs to just anyone. They may want to recoup the cost of developing the technology. They may be only interested in bigger partners with a compelling, mass-appeal application that could be profitable to the carrier.

In this case, vendors had to implement GPS for the E911 laws (see this and this), and so the functionality is already present on the phones. And just imagine the slew of applications that could be developed with GPS support-why wouldn't they want to expose it, right?

Slowly, JSR 172 is taking hold, and where it's not, you may find QJAE's Location APIs. QJAE is Qualcomm's Java Application Extensions which provide useful APIs. My particular handset has this API's Location Based Service API, and not JSR 172, but at least there is an API!

So, armed with this, I started looking for the compiled classes: they're nowhere to be found! I have the Spring SDK, and apparently (according to this ancient article) the jars with the compiled API were at one point included in the Sprint SDK. It's not currently. Apparently, Sprint's stance is that you need to be a partner to access this functionality. Some people have had success reverse engineering the API from documentation and explicitly enumerating the values of the constants at runtime from the handset. Sprint's stance is that this is illegal. 

This also conflicts with my limited understanding of how Sprint limits access to other APIs. Other APIs (such as MMAPI) are accessible if and only if you sign it using a pricy Verisign certificate and obtain a partner account with Sprint (for deployment). For testing, everything seems accessible enough by simply "enabling" your handset on Sprint's developer site (see this developer.sprint.com article for more) and using Sprint's toolkit to sign it (as outlined here)).

That's enough for this post. Let's see what else I can scrounge up. I need more information.