Feature request: Shorter intervals for background process execution

Hi, maybe this has been asked or requested before: I use a temporal event to execute a webRequest from a background process in my Watcface. I use it to access blood glucose levels from a web server. The background process can run only every 5 min and that is really limiting the usability and value of my watch face, as I need the glucose data to be as close to real-time as possible.

I understand the battery consumption is a concern for watch faces and datafields but it should really be up to the developer to decide how often to execute the background process (at least within reason) I don't see why there should be a huge problem to allow execution, say, every minute instead of after every 5 mins. It would greatly enhance user experience for many watchfaces that require background processing.

I am sorry If I post this question/request at the wrong place (Im happy to post it elsewhere if you let me know where)

Best regards
Fredrik

  • With a background process in a watchface, it not only runs when the WF is visible, but at other times too..  Like if you're recording a running activity, so doing something like 5x the number of requests can impact the battery while out running or biking.

    What you can do is create a device app.  A full blown app that can do things like a makeWebRequest in the foreground, and can do it as often as reasonable.  For example, here's a device app of mine that displays Tempe data, but looks like a watch face, but can do things you can't do in a WF.

    https://apps.garmin.com/en-US/apps/54e90766-dc58-4f42-b898-261a090949c5

  • Thank you for answering Jim, appreciated. I understand we don't want to drain the battery to quickly. What about limiting the background to allow execution only when the watchface is "active", and not during activity? In most cases, there is no point to update the watchface if its not in the foreground anyways.   

  • Why not just do it as a device app?

    There are a number of cases where running a background when the WF isn't visible can be useful.  Widgets need background processes to run when they aren't visible, becasue they are visible that often.

  • I feel that using a watch face I get a more integrated function. I'd like the blood glucose readings feel like they are part of the core services provided by the watch. A widget needs to be manually restarted every time I do an activity or after I have used other services (like compass, heart rate, step counter, etc) whereas with a watch face, its always on. I understand these argument may not be valid for every user but the core issue is still that the developer is not allowed to implement what he or she feel is the best user experience vs battery performance ratio.   

  • One of Garmin's top concerns is "battery life" and don't want to leave that up to CIQ developers.  It's the same reason that onPartialUpdate is limited to a 30ms avg.  Or that watch faces can't play tones, etc.

  • I understand. The only way for me to improve reading frequency is to implement my app as a widget. Thanks for taking time to respond to my questions. 

  • No, a widget is only one option. You can do a device app (sometimes called a "watch app").  You start it, and it runs until you stop it, and can do comm in the foreground.

  • Sorry Jim, I confused myself. I actually meant an app, not a widget. I have made it as a watch app as well but I always have to go back to the menu and chose the app after I finished an activity whereas with the watch face I don't have to do anything it just pops up. Its perhaps something I can live with I guess. Will try both options to see if the increased web request frequency improves accuracy or not for my glucose readings.