best practices for restoring data field state after a pause timeout

I think that should work, except of course timerState is not available for CIQ 1.

There was another thread about a similar issue (resume later with watches) from 2016 with another solution that might be more generic. (i.e. It would support CIQ 1 so you could support the “resume later” option for Fenix 3 — see below.)
https://forums.garmin.com/forum/deve...u-resume-later

(For once!) I think I was making this more complicated than necessary. It appears you can identify "new activity starting" by testing for info.elapsedTime == 0, and "previously paused activity resuming" by info.elapsedTime > 0.

Of course in either case, the user could’ve added your data field in the middle of an activity, so it’s not enough to only check timerState or elapsedTime.

Couple of comments:
- watches have a “power save timeout”, but the activity gets saved (instead of being able to be resumed later). At least that’s how 935 works
- 935 and Fenix watches (including Fenix 3, which is CIQ 1) have an explicit “resume later” feature which works a lot like you described, except the user has to select it.

FWIW, I don’t know of any popular CIQ apps that support proper resuming, including the Garmin Combo Running Power data field.

This is the kind of thing I wish were covered in the Garmin UX guide or FAQ. For example, I would never have known about the Edge behaviour except that a user mentioned it to me, or unless I read your post. I feel like there are a lot of “gotchas” that are never discovered until something breaks and a user complains. Yet they’re often “open secrets” in the sense that you would know if you’ve read every forum post dating back to the start of CIQ. And these edge cases and workarounds are often “rediscovered” over and over again, right in these forums. I feel like there should be a better way.

But if Garmin’s own apps don’t support this scenario properly, how can anyone else be expected to support it? Especially data fields that are right at the memory limit and would have to sacrifice features to support a use case that rarely happens for watches. So rare that Garmin itself doesn’t support it. What if your data field has complex internal state that isn’t easily serialized? Sure, anything can be saved and restored as long as it’s not too large, but that takes code which takes up precious memory.

I wish Garmin would just save app state and restore it in these two cases, which I’m sure is what everyone expects anyway. All the native stuff seems to be saved and restored, or at least I’m sure everyone expects it to be. So once again, CIQ is a second class citizen. I get that it may not be feasible, which is why I wish it were covered in the UX guide so devs could make a choice whether to support resuming before finding out later.

If someone doesn’t own an Edge or a watch that supports resuming, they literally have no way of knowing this is an issue. (Except by reading random forum posts.)

Maybe add a bit more to onStop and initialize for the add the DF while running/delete the DF while running.

in onStop, delete the key in storage if things ended normally, and in initialize, delete the key if there (after the data was read).

And in the data you store, include elapsedTime, and then in initialize, if the time is non zero, compare it to what's in your saved data, and if it's not close, ignore the saved data. But for this, I'm not sure if elapsedTime changes while it went to sleep, so you'll have to check that. I wouldn't expect timerTime to change though.

Maybe add a bit more to onStop and initialize for the add the DF while running/delete the DF while running.

in onStop, delete the key in storage if things ended normally, and in initialize, delete the key if there (after the data was read).

And in the data you store, include elapsedTime, and then in initialize, if the time is non zero, compare it to what's in your saved data, and if it's not close, ignore the saved data. But for this, I'm not sure if elapsedTime changes while it went to sleep, so you'll have to check that. I wouldn't expect timerTime to change though.

Yep, I do clear things out if it stops normally. My first run at it just checks timerState. Not a bad idea to try to be just a bit smarter for really weird cases.

This is definitely a hard one to debug since you can't do it in the simulator. I can't think of any scenario in the simulator where you can "resume" an activity with a new instance. And running it on the Edge requires a several minute delay while it goes to sleep. So make your test runs count!

I think that should work, except of course timerState is not available for CIQ 1.

There was another thread about a similar issue (resume later with watches) from 2016 with another solution that might be more generic. (i.e. It would support CIQ 1 so you could support the “resume later” option for Fenix 3 — see below.)

I wasn't aware that the Fenix 3 was on CIQ 1. I was thinking the Epix was the only one, which I actually have but generally no longer support. Regardless, I don't support CIQ 1 in these data fields.

I wasn't aware that the Fenix 3 was on CIQ 1. I was thinking the Epix was the only one, which I actually have but generally no longer support. Regardless, I don't support CIQ 1 in these data fields.

Well, lots of watches are on CIQ 1.3.0/1.4.0 (like the ever popular 235, and all the watches from the same era, like 920XT, 630, etc.), but Fenix 3 is the only CIQ 1 watch I can think of that supports Resume Later. I don't have direct experience with all of them, but I'm pretty sure 230 doesn't support Resume Later. Not that it matters in this case, but I know a lot of runners who actually have a 230/235 or even earlier. I know we all like to think of those watches as "ancient" and Garmin would like everyone to buy new watches, but I don't think every runner treats their watch like a phone which has to be upgraded every two years.

Also, afaik Epix is the only watch which doesn't even have 1.3.0, which could be why most apps don't support it. There's a lot of pretty basic functionality in 1.3.0 whose absence I would prefer not to work around, so I generally support every watch except Epix.

But I guess all the Edges are on 2.4 or later. (Most Edges are on CIQ 3).

And again, afaik there's no hint in the simulator or any CIQ documentation that "Power Save > Resume" or "Resume Later" are even scenarios that exist on devices.... And Garmin sure didn't care when implementing their own Combo Running Power field.

Ah, yes, I was thinking 1.0 for the Epix. My main watch for a long time was the 630. Most of my dev work is on applications, so this has never been a big issue for me.

My main public apps are for connecting to the Garmin Alpha/Astro dog tracking devices. For the simplest data field version, it even does work on the Epix. That was a lot of work for all 10 of those devices in the wild. My original Dog Tracker Application works on pretty much all devices except the Epix as my main watch at the time was a 630. But my latest Plus version (still free) only works on the latest devices with the 935/645 being the minimum and I've had to limit functionality, like track lengths, there due to memory. The Edge data fields I'm dealing with for restoring state are private so I only have to deal with devices I use. Still a good experiment to get this working.

Connect IQ is still definitely a work in progress, but I just keep reminding myself how far it's come since those 1.0 days.

Also, afaik Epix is the only watch which doesn't even have 1.3.0, which could be why most apps don't support it. There's a lot of pretty basic functionality in 1.3.0 whose absence I would prefer not to work around, so I generally support every watch except Epix.

it's nearly impossible to create an app for the epix without having the device as the real device acts so differently from the simulator. I have 1 app that supports it but remote debugging through email with a user in another time zone is not something I'd recommend.

This is definitely a hard one to debug since you can't do it in the simulator. I can't think of any scenario in the simulator where you can "resume" an activity with a new instance. And running it on the Edge requires a several minute delay while it goes to sleep. So make your test runs count!

Not sure if anyone else is seeing this and whether it's a bug or intended behaviour, but for my data field apps at least, in the simulator if I pause the timer and rerun the app, ActivityInfo is preserved (including timer, distance, etc.) In contrast, if I rerun the app while the timer is running, then everything is reset.

In other words, we can test these "resume" scenarios by pausing the timer in the simulator, then re-running the app.

Edge devices are different, as the whole device will enter a sleep mode or turn itself all the way off, with no user action required.

jim_m_58 sorry, I meant in the simulator.

Yes, that's normal in the sim.

Thanks for confirming that it's normal behaviour.

Anyway, my point is that the various "resume" scenarios (Edge - resume after power save, Watches - resume after Resume Later) seem to be testable using that procedure, contrary to the text I quoted above. Unless of course I am missing something.