Access to Location/Bluetooth API of Java ME

coldhand  2007/08/31 13:51 UTC


Hi,

Is it already possible or are there any plans to integrate access to Java ME APIs like Bluetooth or Location ? That would be a great advantage over standard mobile browsers. When do you think this is possible?

Thanks,
coldhand

Re:Access to Location/Bluetooth API of Java ME

render  2007/08/31 20:27 UTC


Not possible at the moment, sorry.

Reason why Helium was created in first place was that J2ME doesn't support dynamic classloading. Connection to each J2ME API must be built to the Helium VM, current version doesn't have such mapping, but if can be added in future versions.

What kind of use you would have for Bluetooth? Personally I don't think that would be as useful as Location. However to help the lack of Bluetooth we are adding support for communication between widgets - same widget in different phones.

Location support will surely be added, as soon as there are enough phones that support it.

Re:Access to Location/Bluetooth API of Java ME

coldhand  2007/09/04 14:57 UTC


Thanks for the fast answer.

With access to the Bluetooth API it is also possible to use external Bluetooth GPS receiver without the need for the Java ME Location API (JSR-179) which is not widely spread on mobile devices.

We have JavaME code to use an external GPS receiver with a Nokia 6230 , for example. Therefore most phones supporting the Bluetooth API are GPS ready :-)

Re:Access to Location/Bluetooth API of Java ME

WebSeed  2007/09/04 15:54 UTC


I would recommend that they only supported phones with JSR-179 (Location API). Support for this API will increase as new models are released.

Including a custom NMEA parser able to handle different kinds of GPS receivers and developing wrapper functionality to replicate JSR-179 classes would increase the platform size a fair bit (not to mention the complications involved with using the Bluetooth API).

Re:Access to Location/Bluetooth API of Java ME

render  2007/09/05 05:38 UTC


Yeah, I know from the fact that NMEA formats differ between devices. Also that external GPS and Bluetooth connection drains the battery pretty fast ;)

What classes/methods should be mapped from Location Api. Is getLocationCoords() enough? Everything cannot be mapped as client size growth must be kept in minimum.

/render

Re:Access to Location/Bluetooth API of Java ME

WebSeed  2007/09/05 09:02 UTC


Personally, I think a getLocationCoords() method would be sufficient initially, preferably with the coordinates returned containing a horizontal and vertical accuracy value i.e. QualifiedCoordinates. It would be nice, but not critical to also have access to the Coordinates.distance(Coordinates) method. I guess all this is complicated by the lack of floating-point support!

I can also see support for Landmarks as being quite useful for certain applications.

Re:Access to Location/Bluetooth API of Java ME

coldhand  2007/09/05 11:48 UTC


I would suggest to support only the GPRMC-data format (RMC = recommended minimum sentence C), for example.

You are right that the usage of bluetooth drains the battery. However, if external GPS receivers are not supported, it will take quite a long time until a satisfying number of users can use a widget with location support.

Up to now we have not used the Location API in our JavaME client, because it is not widely available. This will change, of course.
It depends on the lb-service which functions are needed, however I also think the getLocation() and getLastKnownLocation() functions would be a good start. In the end the user's location data must be available for the server which is then able to adjust the service/widget to the location.

The Location API (JSR-179) requires CLDC 1.1 devices, which support floating-point.

Re:Access to Location/Bluetooth API of Java ME

WebSeed  2007/09/05 12:33 UTC


The Location API also supports external GPS units, so I guess battery drain would be an issue in either case.

Users of the Location API are not generally exposed to the raw GPS sentences, so if using JSR-179 it's kind of moot as to what sentence/s are used (this makes sense as the location may not be obtained from a GPS unit).

Re:Access to Location/Bluetooth API of Java ME

coldhand  2007/09/06 11:29 UTC


@WebSeed: Yes, you're right. The Location API handles various location providers (e.g. external GPS units) and other issues. However, as mentioned before: This API is not available on many devices. Therefore supporting devices which only support the Bluetooth API would drastically increase the number of mobile devices which can use location-based service widgets.
The minimum communication with the Bluetooth GPS receiver would be enough to reduce the size of additional code.

Re:Access to Location/Bluetooth API of Java ME

WebSeed  2007/09/06 15:11 UTC


Yes coldhand, I accept that JSR-179 is not currently widely supported if you consider the whole mobile phone market. However, I reckon that a large proportion of WidSets users have Nokia 3rd Edition devices (which do support JSR-179) - I could be completely wrong of course!

I actually developed a GPS library for J2ME earlier this year which only uses the Bluetooth API (http://www.willbamford.co.uk/files/GpsLibrary.zip). I've just compiled and obfuscated the code and it's about 9KB in size. Doesn't sound a lot, but I guess the WidSets team have to be quite frugal about adding extra classes to the platform. However, as mentioned before, size is only one consideration - there may be also other complications with using JSR-82 on various phones. For instance, I found that certain Nokia 6630's crash when reading past an input stream from a Bluetooth connection (unavoidable when accessing GPS stream). I'm sure there are many other fragmentation issues with different phone/GPS units as well.