When designing applications that utilise Lumia SensorCore SDK, please consider the following guidelines and comments.
Provide users with an easy way of enabling Location services or Motion data collection. Many people will have either Location services or Motion data collection disabled by default. Apps should provide users with an easy way to enable the necessary features for better user experience.
Motion data is not available on all devices. Apps utilising SensorCore SDK can also be installed on devices that do not support SensorCore SDK functionalities. App should prepare for a case where no sensor or sensor data is available. If an app has no functionality without SensorCore SDK, it should be stated in the App’s Store description.
Motion data collection starts only after user enables motion data in system settings. If user has just enabled motion data collection, there is no or very little history data. Especially for the Place Monitor API it may take time before place data gets collected.
Motion data can be cleared by the user. Developer must take care that app handles cases where sensor data is cleared.
Remember the passive nature of Place Monitor and Track Point Monitor. Place Monitor and Track Point Monitor will not actively poll user’s location. Therefore it might take even several hours until the data gets updated. The frequency of history data is dependent on whether some other applications are currently using GPS or not. User’s environment will have an effect on data accuracy and update frequency. For example, in city areas the data is more accurate and the frequency of updates is higher than in countryside. In normal city conditions you can expect to receive updates around every 500 meters for Track Point Monitor. With the Place Monitor, consider combining the data with more active positioning methods to create compelling apps.
Note the latency introduced by filtering. In order to improve Step Counter and activity detection accuracy, the sensor data is being filtered before it is made available through the API. This adds some latency to the step and activity detection. For example, Step Counter readings will be approximately 6-7 seconds “late”. Therefore it is advisable to decrease the granularity of the data shown in UI, for example rounding step count to nearest 50 or 100 steps.
Notice the granularity of Step Counter history data. Step Counter history data is collected by the sensor every five minutes. Data collection is aligned with system clock, i.e. always at the hour, five minutes past, ten minutes past, etc. This means that if you combine the data with Activity Monitor history data, you will be unable to get accurate measurement at the exact moments of activity changes. Note that the current reading polled from the Step Counter will always be up-to-date, not (up to) five minutes off.
Notice that the Step Counter data is absolute. Step counts and walking/running times returned by the Step Counter are total numbers since the last device factory reset or motion data clearing from motion data settings. If you need step counts and walking/running times since your application was first started, you will have to save the step count value you get the first time the application is started up. Save that value in your application persistent data storage. On subsequent application start, poll the current value of the step count, and subtract the saved value to calculate the delta. In such case it is important to remember that the step count can be cleared by user.
Try to reduce the usage of background processes. If possible, utilise history data collected by the sensors instead of polling or monitoring the sensors in background processes. The sensors collect data in a very power-efficient way, so make use of that whenever possible. The data is saved for 10 days. If it can be assumed that your application will be used at least once every 10th day, you could just collect the history data since the last time your application was used and not have to use background processes at all.
Be aware of system clock change behaviour. Changing system clock manually, for example due to daylight savings or travelling to another time zone, will have an effect on collected motion data. In case the clock is moved backwards, any data left “in the future” will get deleted. In case the clock is moved forwards, there will be gaps in the history data. Changing the date – even momentarily – for more than ten days will result in all the history data getting cleared.
Privacy is critical part of the system. SensorCore functionality requires that the user sets Location and Motion data on. In case your application moves any location or motion data outside of the device to backend, it is strongly recommended for the app to ask permission from the user for this action. For more details, check the Privacy section.
Remove the testing package from the final product. Although the Lumia SensorCore Testing package is a great tool while testing and debugging, it increases the size of your final product considerably, so it is advised to ensure you have removed it before submitting your package to the store.
Some of the functionality of SensorCore SDK has dependencies on other subsystems of the device. In some cases, the functionality may not be available if the dependency is not available, in other cases the functionality is improved when the dependency is available. We illustrate those things in the following table,
|Track Point Monitor||x*||x||x*|
* will improve also the GPS performance if present
Last updated 24 July 2014