Provider States
The BlackBerry OS automatically updates the state of a LocationProvider by calling the providerStateChanged() method of the registered LocationListener. Here is a detailed description on how these status codes are interpreted in RIM’s implementation:
- TEMPORARILY_UNAVAILABLE: GPS Chipset has stopped looking for a fix. LocationProvider will no longer provide a fix to the application.
- OUT_OF_SERVICE: When there is an IT Policy sent to the device to disable GPS.
- AVAILABLE: Never sent to the application because we never know when the GPS will have coverage again and continuously trying to get a fix would drain the battery. The application can decide when to retry by resetting the provider (see below).
Resetting the LocationProvider A LocationProvider might stop returning fixes when network coverage deteriorates or the device is in an environment which is not suitable for receiving GPS data (e.g. indoors). In these scenarios, the GPS chip will go completely cold to preserve battery power and throw a TEMPORARILY_UNAVAILABLE event by calling providerStateChanged()of the registered LocationListener instance. If this event is triggered, an application can reset the provider to bring back the GPS chip to life. After calling LocationProvider.reset()
After a reset, the application can try to get a fix again. However, if the GPS chip fails to get a fix (if the network coverage or environment has not improved), it will again become cold and will stop getting fixes. It is expected that the application will decide when to reset the provider. It is strongly recommended not to reset the provider at an interval less than five minutes since it can take up to five minutes to get a fix from a cold start.
When resetting, first you will have to set the LocationListener of the LocationProvider to null, reset the LocationProvider and then set the LocationProvider to null as well before creating a LocationProvider and a LocationListener from scratch.
Note: In some handheld software versions it was reported that the TEMPORARILY_UNAVAILABLE state was not always triggered as appropriate. In these cases, it is a good practice to keep track of the timestamp of the last valid fix and to reset the provider if the last valid fix is more than five minutes old.
Message Edited by shaque on 07-22-2008 03:26 PM
Message Edited by shaque on 07-22-2008 03:26 PM
Message Edited by shaque on 07-22-2008 04:06 PM
