12-07-2009 04:15 PM
I have serious reservations about the feasability of using the Widget API to develop reliable location aware apps. It is undeniably impressive how quickly the Widget API lets you throw together a prototype of such an app, mashing up content from numerous public web APIs. But when you try to productionize it you quickly see the limitations. This post is written in the spirit of constructive criticism. I have been hugely excited by the Widget API and the possibilities it offers but I sincerely believe that some elements of it are not quite ready for prime time. Hopefully this post will provoke a fruitful discussion. Apologies for the length!
Autonomous mode is slooooow
Widgets can specify how to get a location fix using the setAidMode() function. The assisted mode is preferred but if the necessary carrier support is not available it will switch to autonomous mode. This suffers from having an *extremely* slow first fix time. Very often, we're talking about several minutes of delay. In the meantime, all that a cute little location-aware widget can do is...look cute. For apps built using the BlackBerry Java API the first fix is equally slow when using autonomous mode. There is, however, a key difference. A java app can be set to auto start and hide out in the background until needed by the user. With a bit of luck, this allows for the slow first fix to complete in the background before the user actually gets around to using the app. This approach is not possible for a widget because it is not possible (short of monumentally hacking the generated source code) to get a widget to auto start in the background.
When it all goes wrong
Another big concern I have with the Widget API location support comes from what I know about how location support works in the BlackBerry Java API. The Java LocationProvider class can sometimes stop delivering location updates to an app. This can occur, for example, if the device is out of GPS signal coverage for an extended period of time. When this happens the app is notified via the providerStateChanged() method on the LocationListener interface. The RIM-documented best practice for handling this is to set the LocationListener to null, wait a while, and then set the LocationListener again to recommence receipt of location updates. This works just fine. The problem however is that I don't see any equivalent functionality in the Widget API documentation. It could be that the Widget API wrapper around the underlying Java APIs masks all this complexity by silently implementing the best practice that I describe above without any interaction with the widget. This would be great but I don't think it's the case. The reason is that I have occasionally noticed that my widget stops receiving location updates and doesn't recover.
12-07-2009 04:29 PM - edited 12-07-2009 04:30 PM
Thank you for all of your feedback.. There's some great stuff in your post!
When trying out the Location based approach, have you been using the "blackberry.location" object or the Gears GeoLocation object ?
The Gears object has much more functionality than the "blackberry.location" object does. The Gears object will also be working with the cell tower triangulation service (available sometime in 2010) that we announced at the Developer Conference that should help with that initial fix. This is because the Gears GeoLocation object was built on the latest JSR for location in 5.0.
I believe the GeoLocation functionality of Gears can also be run in a worker pool so that you can have this fix happen in a background thread. Give it a try and see if it helps out for that initial fix. We are also working on that "auto start in the background" as well . But like you said, that functionality isn't there yet.
I can talk with the folks that did the GeoLocation API implementation and see if they have implemented the best practice that you speak of silently.
You can check out the details of the GeoLocation API here:
Let me know if that helps you get around any of the difficulties you have mentioned.
12-07-2009 05:07 PM
Wow! It's like I've suddenly discovered a door to a parallel universe. When I saw the blackberry.location functions I didn't look any further - I just assumed that using the 'own brand' stuff would offer the best approach to location awareness in a widget. I'll certainly check all of that out and get back to you.
In the meantime, I might just suggest that your doco writers add something (preferably in bold, italic, blinking red text!) at the top of this page referring developers to the Gears GeoLocation API
12-07-2009 08:46 PM
I'll update the documents myself!
The "blackberry.location" objects are legacy objects that have been around in the browser starting sometime around the 4.5 time frame.
Let me know how it goes