• Replies 4 replies
  • Subscribers 17 subscribers
  • Views 533 views
  • Users 0 members are here
Options
Related

Garmin Running Power apps: data improperly reset when activity is "resumed later"

FlowState
over 6 years ago
Description
When a running activity utilizing the Garmin Combo Running Power CIQ data field is cleanly "resumed later", all running power data is unexpectedly reset to 0 -- average power, lap power and last lap power. I assume this also affects the relevant individual Garmin running power data fields.

Expected Behaviour
When running activity is resumed later, Running Power data should be preserved, just as with any native data.

Device/Firmware
935 (ROW) 10.10

Reproduction Procedure
- Add Combo Running Power data field to a running activity, on a supported device such as 935
https://apps.garmin.com/en-US/apps/a...e-8606884d96bc
- Wear RD pod or HRM-RUN/etc.
- Open running activity
- Go outdoors and get a GPS fix
- Start timer
- Run for a little while
- Press lap
- Run a little while more
- Average, lap and last lap power values should now be non-zero
- Pause activity
- Select "resume later"
- Open running activity again
- Note that native activity data such as Timer has been restored correctly
- Average, lap and last lap power values are now 0, which is not what the user wants

Notes
- Interestingly, this general issue (affecting all CIQ data fields that compute their own data which is persistent during an activity) has already been raised by a developer, long before running power was released
https://forums.garmin.com/forum/deve...u-resume-later

- My data field app has the same issue, which led me to this bug report. A very popular data field (100k downloads) that supports lap information also has the same issue -- when you resume later, computed lap data (such as lap count) is lost.

I wonder if developer and/or user awareness of this issue needs to be raised -- much like the "workout laps are not CIQ laps" issue (which will never be fixed for CIQ 1 and 2). It's not a trivial one-liner fix -- app-specific data needs to be saved on exit and restored on startup, but only when an activity is being resumed later (and not for new activities). The code can be even less trivial if variable amounts of data need to be saved.

It would be nice if there was something in the "New Developer FAQ" for this issue (along with the "workout laps" issue.)

- This problem (and the workout laps issue) sort of highlights how certain bugs/limitations/unexpected behaviour in CIQ seem to be even more apparent when Garmin releases a major feature using CIQ, as opposed to using native code. It seems to me that this kind of universal limitation/unexpected behaviour shouldn't be a surprise to any developer, in an ideal world, because it would be highlighted in the documentation and/or the FAQ.

For example, the "workout laps" issue seems to have been independently "rediscovered" over and over again, every time users of a popular app noticed that lap data was wrong during workouts. Had this issue been highlighted in the beginning, devs could warn their users about the problem in advance.

IMHO, devs shouldn't have to rely on forum searches or CIQ experts to help figure out these problems after the fact.
  • over 6 years ago
    Hey FlowState,

    I've got a ticket made for the team in charge of those datafields. I hear your feedback about beefing up some of the known issues or limitations not being presented very well. This is something we are hoping to improve.

    -Coleman
  • over 6 years ago
    Thanks Coleman.ConnectIQ, appreciate it!

    I know it's really an obscure corner case -- actually, in the case of my app's user report, I found out that the real problem was his Edge going into "sleep mode" (I didn't even know that was possible) and resuming an activity afterwards, but it sounds like a similar issue. (The CIQ data field closes and opens while the activity is still active, for whatever reason).

    I don't even know how many people ever use "resume later", but it would've been nice to know about that related data field pitfall beforehand, to decide whether or not it should be handled.

    I guess in a perfect world it would be awesome if the memory state of data fields could be automatically suspended and resumed, just like all the native data, but I'm assuming it's not feasible for one reason or another.
  • 11 days ago in reply to FlowState

    i'm working on a datafield now and had no idea about this behavior until i tested today on a long ride with two devices (1) a garmin watch, I used the "resume later" functionality after our lunch for the short ride home (2) an edge unit where I created two separate recordings before and after lunch. It was confusing to me that my datafield stats for the "resumed-later" activity matched the part two edge recording of the ride home; after searching the forums I realize now that my data field stats are getting reset. As far as I know this still isn't covered in the documentation, I agree it definitely should be! I think the datafield lifecycle events in general could be fleshed out in the docs and this would be very helpful.

  • 11 days ago in reply to renschler

    Yeah, it looks like Resume Later will never be addressed in the docs or the API. (The :resume key in AppBase.onStart's state dictionary does not refer to "resume later", but instead resume from suspend on newer devices which have "multitasking" via the "task switcher").

    But if you want to handle it in your data field, I can envision the following approach:

    - in your datafield's AppBase.onStop(), save the app state

    - the next time the datafield runs, check whether ActivityInfo.timerTime is non-zero [*] at startup. If so, assume that the datafield is part of an activity that was resumed later and restore the app state. If not, clear the previous app state

    [*] or substitute the heuristic of your choice. Maybe you want to use elapsedtime or elapsedDistance instead. And maybe you want to have some threshold other than 0, like 5, 10, or 30 seconds, to avoid any possible false positives. (Maybe there's some crazy edge case where the user starts the timer asap, and the data field sees a value slightly greater than 0 the first time it reads timerTime.)

    I haven't actually tested this approach myself.