Creating, Configuring, and Destroying IPosDet
The IPosDet interface is a traditional BREW interface, created using ISHELL_CreateInstance
if ( SUCCESS != ISHELL_CreateInstance( pIShell, AEECLSID_POSDET,
(void **)&pMe->pIPos ) )
When you're done using the interface, you must release it as well, using IPOSDET_Release
if( pMe->pIPos )
IPOSDET_Release( pMe->pIPos );
Of course, because it's a standard BREW interface, you can also cross-cast to IBase and use IBASE_Release
, or the RELEASEIF
macro that you can find in many of the Qualcomm sample applications which does essentially the same thing.
Before you use an IPosDet instance to obtain positioning information, you must configure it using IPOSDET_SetGPSConfig, which takes an AEEGPSConfig structure with the following members:
|There's a correlation between the time interval between position reports and accuracythe smaller the interval between position requests, the larger the potential error in the result.|
- The nFixes field indicates the number of fixes you desire when invoking IPOSDET_GetGPSInfo.
- The nInterval field indicates the number of seconds between position reports you desire when invoking IPOSDET_GetGPSInfo.
- The optim field indicates the tradeoff between position accuracy and speed you require, and is a constant, such as AEEGPS_OPT_NONE (no optimization is required) AEEGPS_OPT_SPEED (optimize positioning data for speed), AEEGPS_OPT_ACCURACY (optimize for position accuracy), or AEEGPS_OPT_PAYLOAD (optimize for minimum use of the network). It's typically best to specify AEEGPS_OPT_DEFAULT, which performs no optimization.
- The qos field indicates the desired quality of service, and is a range from 0-255. Not all handsets use this field.
- The server field is a structure that identifies the type and address of the server; most applications should simply specify AEEGPS_SERVER_DEFAULT in the svrType member of this structure.
Deciding what value to use for the mode
field is somewhat tricky, because the IPosDet interface can return either a single position report (called a one-shot operation) or can return a series of positions over time, for use in tracking and navigation applications. The mode
field can have one of these values:
- AEEGPS_MODE_ONE_SHOT: This returns only a single position determination.
- AEEGPS_MODE_DLOAD_FIRST: This uses the network to contact an LBS server for the first position request, and then performs subsequent position requests using only the handset's capabilities. Use this value in tracking or navigation applications where initial accuracy is key.
- AEEGPS_MODE_TRACK_LOCAL: This minimizes network use for applications requiring frequent rapid position, velocity, or altitude information.
- AEEGPS_MODE_TRACK_NETWORK: This utilizes the network for repeated tracking information, providing improved accuracy at the expense of performance.
- AEEGPS_MODE_TRACK_OPTIMAL: This attempts to honor the optim field to determine the best algorithm for position determination.
- AEEGPS_MODE_TRACK_STANDALONE: This minimizes dependency on the network and is suitable for use in regions where the cellular network may not be available.
- AEEGPS_MODE_DEFAULT: This is the default mode of operation, providing a single position determination.
Thus, if you need only a single position report at a time, use AEEGPS_MODE_DEFAULT
). If you require multiple position reportsas most navigation or tracking applications doyou need to consider the tradeoff between the time interval between fixes and accuracy. There's a correlation between the time interval between position reports and accuracythe smaller the interval between position requests, the larger the potential error in the result. As you develop your application, be sure to allocate time to test the different options in different settings to decide which of the tracking options are right for you.