How to minimalise battery use in watch-app when "paused"

How can I reduce battery use in a watch-app when it is "paused"? Ideally I would do something like "resume later", but it's not really* available. So for now this is what I do, when the user "pauses" (stops) the activity.

1. disable GPS

2. disable 1 second timer and set a 1 minute timer (to update the clock time on the screen), but still display the "dashboard"

3. if the user clicks Back, then I stop even the 1 minute timer and a menu is displayed: resume/save/discard

But it still eats the battery when paused

I'm thinking about 2 options:

1. If still in the menu, no user input for more then 1 minute, then I could switch to an empty black screen that is switched back to the menu on any user input

*) 2. Or as an "educator" I could display after 1 minute a short explanation to long press the Back button, and thus go to the watch face. I wish there was a programmatic way to do this, which would be very useful and could be used for "resume later" and save battery.

Feature request: https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-resume-later

Top Replies

All Replies

0 FlowState 20 days ago in reply to flocsy🤠

flocsy🤠 said:
In my fr965 I really tried to see if a native activity indicates anyhow whether the GPS fix is aquired, and maybe I'm blind but I couldn't see any indication neither in case of "pausing" (stopping by clicking the stop button) then entering a building and then coming out 10 minutes later nor in case I even choose "Resume later" and then open it again 10 minutes later.

flocsy🤠 said:
The reason I added the GPS indicator (besides of it being a cool sub-project) was exactly this, because I had no idea if there's a fix when I go outside...

Not to state the obvious:

- there's the GPS indicator which exists before the activity starts (GPS "progress bar" and green ring)

- Garmin probably doesn't want to show anything like that during the activity (after the timer is started for the first time) to keep things simple and avoid confusion (same as it no longer shows the sensor icons after the activity starts)

- At least on FR955, there is a native GPS data field (with graphical bars, just like the cell signal bars on a phone)

And again, even if the system says that you have a good fix (whether it's the green ring or the GPS indicator with all the bars filled in), that doesn't mean you actually have a good fix. Like I said, I always wait for the pace indicator to settle down to "0" (while I'm not moving) and this can take 5 seconds, 30 seconds, or even several minutes.

0 FlowState 20 days ago in reply to flocsy🤠

flocsy🤠 said:
Maybe I should really look into these :resume and :suspend parameters and think about it if my apps (one datafield and one watch-app) should/could behave differently.

I mean, it has come up before that data fields could also try to handle Resume Later, too (I think you brought this up once).

Garmin didn't do this with their old Running Power data field and I haven't seen any popular data field which does this, but it seems to me:

- a CIQ datafield app could save its state in onStop() (unconditionally)

- in onStart(), the app could try to guess whether it started from a Resumed Later activity. (Maybe one way would be to check whether Activity.Info.timerTime is non-zero at app startup?)

Other non-activity / non-data field apps will just unconditionally save and restore state, like one chess app I tried. Obviously doesn't make sense for every app.

It does seem that if the system explicitly tells you your app is suspended/resumed, then it would be nice to act on that information if you can.

But as usual, all of this seems like a ton of work for questionable reward. (Not too many people noticed or cared that CIQ data fields don't support Resume Later.)

0 _psx_ 20 days ago

When I thought about a special application I made some test (application that does nothing :-) ) and, of course you can switch off everything what you previously switched on but the the most problem was with system - just because it's the app or widget watch starts to run in high power and it consumes 3,5,10...% battery per hour.

Even if you exit from activity (build in app) with resume later my watch is running in high power (maybe it's a bug).

So the best solution is adding to API setPower(percent) :-) without this feature is impossible to manipulate consumption of battery.

0 flocsy🤠 20 days ago in reply to FlowState

I looked into :resume briefly about 2 years ago, but then I couldn't find any use for it in ANT+ HRM.

As for noticing issues with datafields and resume later: I reported a bug related to that in Walker, which was then fixed. But based on the download numbers (I think it was over 100k even then) and me being the 1st to report, it probably isn't used by many, bugs noticed by even less, bugs reported by even less... Interestingly the fix doesn't involve the parameter in onStart.

0 FlowState 19 days ago in reply to flocsy🤠

flocsy🤠 said:
As for noticing issues with datafields and resume later: I reported a bug related to that in Walker, which was then fixed.

flocsy🤠 said:
Interestingly the fix doesn't involve the parameter in onStart.

I don't think that's surprising - as mentioned above, Resume Later has been around forever (and CIQ data fields have never been "notified" when they're resumed later), while onStart's :resume parameter is new and specifically relates to the new (with CIQ 4.2.0) app "suspended" state, which is unrelated to Resume Later.

In this context, "suspended" is what happens when the system simply terminates your "inactive" CIQ app because it needs resources (but it passes the :suspend argument to onStop() so the app can save its state.)

Resume Later probably predates Connect IQ and it's a way for the user to (apparently) save the state of a native activity, including the FIT recording session but not including the state of any CIQ data fields.

Like I said, my only guess is that a data field could handle Resume Later by guessing that they were resumed later - e.g. if Activity.Info.timerTime is non-0 when the app starts up, it seems the only possible explanation is that the activity was resumed later.

Or maybe the app could save Activity.Info.timerTime in onStop() - if Activity.Info.timerTime has the exact same value at onStart(), then the app was resumed later.

I haven't tried anything like that myself tho. (For example I am presuming that timerTime can be read immediately when the app starts, which may not be true. And I'm assuming that no app would ever "normally" see non-zero timerTime when it reads that value at the first available moment. Maybe a better heuristic would be to check whether timerTime is greater or equal to some arbitrary number, like 5 to 60 seconds, the first time it's read. That would probably be unnecessarily lenient, and could lead to resume later not being detected in some cases though. Using 5 seconds or even 2 seconds for the "resume later" threshold would probably be enough, if it's based on the first value of Activity.Info.timerTime that's passed to compute() after the app starts up.)