• State Not Answered
  • Replies 15 replies
  • Subscribers 19 subscribers
  • Views 768 views
  • Users 0 members are here
Options
Related

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

flocsy🤠
21 days ago

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

  • 0 21 days ago
    flocsy🤠 said:
    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

    I know you have an FR965, but for MIP devices, constantly displaying a static screen should consume literally 0 battery (at least in terms of the display itself, and updates to the display).

    [Assuming onUpdate() isn't called constantly, although idk if not calling onUpdate() will cause problems if the watch displays a notification and the users dismisses this.]

    Ofc there may still be other things going on in CIQ that may consume energy, no matter what you do.

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

    You could do what native activities do and automatically switch to the pause menu after a timeout of a few seconds. (The user could return to the main app by pressing Back, but the same timeout would apply.)

    Yes this is kind of annoying but it's exactly what the built-in activities do.

    Then again you're not obligated to do this, and there may be no reason to, if you opt to implement some kind of explicit sleep mode in your app (see below).

    flocsy🤠 said:
    1. disable GPS

    Is that what users want? Will there be issues with reacquiring GPS when the user restarts the timer? Let's say they pause their watch for several minutes (or hours) and actually move to a completely new location during that time. Now the GPS won't be turned back on until they start the timer, but for the first few seconds (or longer) after that, they might not have a truly good fix. Or what if they stay in the same general location (e.g. duck inside a building for coffee or water), but they stop long enough for the device to lose the fix it previously had. (idk exactly under what circumstances this would or could happen - e.g. idk exactly how long you'd have to wait.)

    Would you need to give users a way to re-enable the GPS without restarting the timer? Would users find that inconvenient or confusing?

    Speaking of how long it takes to get a "good" fix, I find that that when I open a native activity like running, even if the green GPS ring appears in a few seconds, I can tell I don't really have a good fix, by noting that my position on the map is changing while I'm standing still, and my pace is fluctuating rapidly (sometimes showing impossibly fast paces.) Sometimes it can take 30 seconds or longer to get a good fix.

    I could see being ok with this if the app was in a special, optional, power saving mode.

    Maybe instead of "resume later", you could have a "sleep mode" for your app in the pause menu? If the user selects sleep mode, then you turn off the GPS and the screen (maybe show a small icon and/or text to remind the user that they're in your app. When the user presses any button (or perhaps taps on the screen), you wake up the app, turn on GPS and display a normal screen (whether it's the pause menu or the main app screen).

    As an end user, I think an explicit sleep mode would be a pretty good compromise. It is kind of like "resume later" except the user doesn't leave the app.

    flocsy🤠 said:
    *) 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.

    Are you saying that a native watchface uses less power than a static screen in a CIQ app? What if the user has a CIQ watchface?

    Personally, as an end user, I don't think it's user-friendly for an app to "instruct" users to do some thing in the native UI that the app can't do itself, unless it's absolutely necessary.

    For example there's an app which purposely refuses to work at all if touch is enabled, and users are instructed (in the docs) to disable touch if they want the app to work. Predictably, there's a negative review which criticizes this behaviour. Obviously in this case, the correct approach is to write the app so that it ignores touch inputs, as opposed to asking the user to disable touch before they open the app.

    It's not the same situation as yours, but it's just an example of how end users don't like being told to do certain things by apps. Like if your app tells users "hold Back to return to watchface in order to save battery life", maybe some users will ask themselves "why can't the app save battery life on its own?"

    Then there's other issues like:

    - not every 5-button watch returns to the watchface by default, when the user holds the Back button. e.g. fr955 doesn't - by default Hold Back does nothing. e.g. iirc Fenix 8 (and maybe Fenix 7 Pro?) uses Hold Back for something, by default.

    - even watches which do return to the watchface by default - when the user holds the Back button - can probably have that setting changed so Hold Back does something else (including nothing). e.g. Some older generations of Fenix watches use Hold Back to return to the watchface by default (and it's documented), but that setting can be changed.

    - not every 5-button watch has shortcuts in the first place

    - other watches may or may not have shortcuts, but if they do, those shortcuts may be different. (e.g. Vivoactive 4/5 shortcut is swipe right, I think)

    - some watches don't allow you to return to the watchface at all (e.g. probably every watch that doesn't support shortcuts, except in the case where there's some crazy workaround like opening the Settings menu and selecting Watch Face)

  • 0 21 days ago in reply to FlowState

    Speaking of returning to the watchface, some Fenix 7 users have complained that if you return to the watchface while a CIQ app is active, then the app is terminated, even if it's recording an activity. (Apparently the activity is automatically saved.)

    (They characterize this as something along the lines of "garmin doesn't support running apps in the background anymore". ofc they don't mean "background" as in "Connect IQ background process", but just the ability to return to the watchface without killing the app.)

    On my FR955, it seems like:

    - if the CIQ app is recording an activity, then if you return to the watchface, the app is not terminated

    - if the CIQ app is not recording an activity, then if you return to the watchface, the app is terminated

    While the FR955 behaviour would work well for you, the (alleged) Fenix 7 behaviour would be a disaster.

    EDIT: I originally did the FR955 tests using the hold Back shortcut, but just to eliminate the possibility of pressing Back having something to do with the observed behaviour, I also did the same tests with the hold Start shortcut. Exact same results. Ofc it also doesn't matter how "deep" I am in the app (in terms of the view stack), the app is terminated (or not) just the same.

  • 0 21 days ago in reply to FlowState

    Here's one post with a bunch of links to related posts:

    https://forums.garmin.com/outdoor-recreation/outdoor-recreation/f/fenix-7-series/332270/iq-bug-iq-activities-apps-are-aborted-when-switching-back-to-the-watch-face

    KrapfenKringel said:
    Seems another issue with the redesigned IQ app support for the 2022 devices. Especially problematic when using an IQ app to record an activity and you are used to a quick glance to your watch-face or widget from using stock activities. With IQ apps (like Inlineskating) they will end and store the activity, you can't resume it / keep it running in background when going back (like it works with older devices like F6 and F5 or native activity profiles).

    Honestly I wonder if what's really happening is that the CIQ app doesn't handle onBack() (or it does handle onBack() but saves the activity and closes the itself), and when the user holds the Back button, onBack() is *also* triggered.

    If that was the case, perhaps people would've noticed that this bad Fenix behaviour doesn't happen for *all* CIQ apps that record an activity, but only ones written in a certain way, but who knows.

    So maybe they're absolutely right and it's not possible on Fenix 7 to return to the watchface without killing the current CIQ app.

    The funny thing is that a few years ago, some users complained about the opposite problem: they regularly use hold Back to quickly exit an app when they're a few levels of screens deep, and they didn't like the fact that this no longer terminates the app, meaning that when the press START from the watchface, they're returned to the app (instead of being allowed to select a different app/activity.) I think these were also Fenix 7 users, so I have no idea what's going tbh, unless Garmin is just constantly flipping between opposite extremes of behaviour to try to please one group of users or another. (Actually this wouldn't be the first time this has happened.)

  • 0 20 days ago

    And finally, speaking of resume later, it does seem like modern watches with a "task switcher" do have the ability to suspend and resume CIQ apps (which is why onStart() now has a :resume parameter while onStop() has a :suspend parameter).

    But obviously CIQ apps can't suspend themselves, and I have absolutely no idea if the system can suspend a CIQ app that's recording an activity, or what would happen to the recording if it were possible.

  • 0 20 days ago in reply to FlowState

    This could be just a bug in the CIQ app. i.e it might do things in onHide that it only supposed to do in onStop.

  • 0 20 days ago in reply to FlowState

    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.

    2 minutes later...

    OK. so well, this isn't great... but there is some kind of indication. I am using Garmin for 5 years, and the fr965 for almost 2, and I pause and resume almost every day (and a few times a week also resume later) and I never noticed. To add to the confusion there's a red ring, which doesn't indicate the GPS but that the activity isn't recording.

    Another 2 minutes later....

    Well, no, sorry, there totally isn't any indication!

    So I used Hiker DF in a Walk activity. Hiker DF has a GPS indicator on the screen so I can see the accuracy every second.

    My 1st test was: start it indoors, stop it, then go back from the "resume menu" to the activity with a back click, and then exit the house. After a few seconds I got the "GPS" popup message. This confused me and I thoght this is the indication I was waiting for. But not...

    2nd test: start activity outdoors, wait for the GPS to fix, then start the activity, then stop it. Go inside, click back to see the screen, and wait until I see in Hiker's GPS indicator that it's gone, then go outside, and wait... and nothing happens on my fr965. No more indication that could tell me if I need to wait more or the GPS has a fix.

    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...

  • 0 20 days ago in reply to flocsy🤠
    flocsy🤠 said:
    This could be just a bug in the CIQ app. i.e it might do things in onHide that it only supposed to do in onStop.

    Yes that's similar to what I alluded to above (i.e. it's an artifact of the way the app is written and not a problem with the device itself).

    But that poster seems to be completely convinced that fenix 7 is killing all CIQ apps (including apps that record activities) when the user returns to the watchface, whereas this did *not* happen with earlier fenix watches. They've made multiple posts and others users seem to agree

    And I have seen a difference between FR935 and FR955 in this regard:

    - FR935: users can return to the watchface while a CIQ app is active (whether or not it's recording). Either way, the app is not terminated. If a CIQ app is recording an activity, then if a user scrolls to a CIQ widget, they will be warned that opening the widget will kill the other app.

    - FR955: users can return to the watchface while a CIQ app is active (whether or not it's recording). If it's not recording, then the app is terminated. If it is recording, it's not terminated. Either way, the user can open CIQ glances without killing the other app

    So Garmin has def changed this behaviour in the past.

  • 0 20 days ago in reply to FlowState

    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.

  • 0 20 days ago in reply to flocsy🤠
    flocsy🤠 said:
    only supposed to do in onStop.

    Speaking of onStop / suspend and the "task switcher" it does seem that Fenix 7 has the "recent apps" feature (which Forerunners lack). You hold Back to see a list of recent apps, according to the manual and forum posts.

    So what could be happening is that when you return to the watchface in Fenix 7, the system is actually suspending the app (onStop() is called with :suspend == true). And when the user returns to the app, the system is actually resuming the app.

    If this is the case, the real question is how is suspend/resume *meaningfully* different than terminate/start, assuming that a resumed app doesn't automatically restore any kind of state from when it was suspended? Maybe the only difference is the suspend/resume flags, which can tell the dev that it's a good idea to save/restore the app state?

    But if the dev can't suspend and resume the FIT recording, it seems like the suspend/resume feature is of limited utility to devs of apps that record an activity.

    NOTE: I don't think suspend/resume is synonymous with "resume later" (as the task switcher / recent apps list is very new, and resume later has been around forever, with zero support in ciq.)

  • 0 20 days ago in reply to FlowState

    The CIQ doc talks about the task switcher, including active, inactive and suspended states, but it doesn't mention whether an app that's recording an activity can be suspended or not. I assume that if it can, then the recording would automatically be saved.

    [https://developer.garmin.com/connect-iq/core-topics/application-and-system-modules/]