Trade-offs between Complication.value versus ActivityMonitor/SensorHistory classes

Now that we can access several data points straight from a device's native complication by using the getComplication().value method, I was curious if there were any trade offs between using the Complications class versus other Classes like the ActivityMonitor or SensorHistory to get similar data points. The main things I'd be curious about would be memory usage and battery life (assuming everything was coded appropriately).

For example, on my FR965, I can fetch my current heart rate from Activity.getActivityInfo().currentHeartRate, but now, if I'm not mistaken, I can also subscribe to the complication of type COMPLICATION_TYPE_HEART_RATE and access its value from there.

Likewise, for number of steps since midnight of current day, I could use ActivityMonitor.getInfo().steps versus complication of type COMPLICATION_TYPE_STEPS.

I did a test on my FR965 for stress, and I used the SensorHistory.getStressHistory() method versus the COMPLICATION_TYPE_STRESS complication, and the complication value was updating much more frequently than the SensorHistory method. The complication value was updating as it would on a native watch face, which I guess is the whole point... but could I be doing something wrong with the SensorHistory data, or is that lag to be expected? Stress is one of those values I'd want to have as close to real-time as possible.. or at least be able to grab the current value when I flick my wrist and look at the watch.

So would I run into any major issues with my watch's battery life or performance if I just subscribed to like 5-6 complications and displayed that data on my WF, instead of grabbing them from other classes? I'm a sucker for consistency and reusing code, and this just feels like it's set-up pretty well for it... but I'd rather not sacrifice my battery life too much in the process. Would that question be dependent on the specific complications I'd want to use?

On a semi-related note, does anyone know if we'll be able to access the "training readiness score" as a complication any time soon? I really like having that value displayed on my native watch face, and I don't see it available anywhere on the API. Would be cool to use it as an arc or bar somewhere on a custom watch face.

  • With anything in SensorHistory, new data is only saved every 1-2 minutes at most so nothing there will be "real time".

    With Complications, not all devices have support for them so if you only use them, you are limiting the devices you can support, but on the other hand, with touch devices and Complications, you can use onPress to launch the app that's the source of the data.

  • Also, complications require a permission that looks like "Permission to read data from other apps" which some users may find suspicious. To be honest, this was what made me give up using complications.

  • I do a hybrid. 

    I get data from the non-Complications methods.  I only use the Complications API for the ability to open to the corresponding apps or the ability to get metrics that aren't available any other way.

    I'm going to begin exploring how to integrate third-party complications next.  That's tricky, since users can't use CIQ settings to pick them (as far as I know).  I have to do that via an on-device menu.

    Has anyone else actually started supporting complications in their watch faces that aren't the Garmin standard ones?

  • Appreciate all the feedback and discussion so far!

    So in summary, it sounds like the biggest issues or hurdles with Complications are just that they're unavailable for a wide range of devices/users, and that they require some extra permissions to access the data on the device, which might alienate some users that won't trust it. Are there any known concerns on security or just people being cautious? What about something like battery life?

    Honestly, I'm just getting started with the SDK and getting myself familiar with some examples and documentation around the forums, but unless I come up with something really cool and useful, I don't think I have the time or experience to support multiple resolutions and devices with different hardware/firmware, so this might be more of a personal project tailored to my fr965 for the time being.

    For Stress specifically, it sounds like I'll have to access the COMPLICATION_TYPE_STRESS Complication for near real-time data, as SensorHistory only stores data every couple minutes or so. And if I were developing a WF for a wider range of devices, I could use the "has" operator to check if they have that particular complication, and if they didn't, I'd resort to fetching it from SensorHistory.

  • I doubt that many users notice, care, or even understand what the permission means.

  • I have a couple apps that publish and a watch face that can use them.  The watch face can easily figure out which are available and act accordingly.

    You can also have CIQ published complications in the new Faceit that figures out what's available on a device.

  • I'm wondering the same thing. The only real way to say for sure would be to test and profile in the simulator, but that might not be so easy because I don't get HR info in the sim when using ActivityMonitor.

    This app has an example of using complications: Simple Example WF that shows a bunch of things - Discussion - Connect IQ - Garmin Forums

    I'm assuming there may be a slight memory overhead for the variables required for the subscription.

  • In the simulator, go to the menu Simulation -> Activity Data and press that little Play button to activate the Heart Rate Reporting via Activity Monitor.

  • Thanks, that helped. Interesting that the complication subscription in the example I linked to just works, no need to press play.