Complications and background service

Good morning,

I have an app displaying data obtained from a web service. I'd now like to implement complications, and use a background service to regularly query the web service and publish the complication data.

Now my question: is there a way to have the background service run only if there are actual subscribers to the complication, to avoid unnecessarily loading the system?

  • I have widgets that used a background service (on devices that support them) long before complications came about.  What that added was in the glance view or when the widget is opened, what was seen was always fairly fresh, with no delay to get the data.  The default for me is that the background runs every 15 minutes, but can be changed to up to every hour.

    Publishing complications (on devices that support them) was fairly minor with already having a background service.

    In answer to your question, there is no way to see if a watch face is subscribed.  The watch face might not even be running when you want to publish (it could be running the app you use to publish).  If you always run a background and publish, when you return to the watch face, it will have the newest data right away.

  • Hi Jim, thanks for your response. In my case I'd do an update every five minutes. I also don't see the coding effort as significant, but I guess the majority of my application's users would NOT use the complication. So the question is then if I really want to load all users with a background service, if only a minority would actually benefit from it.

  • I've had background services in my widgets since backgrounding was introduced and they benefit all users

    With my weather widgets, the default is the background runs every 15 minutes requesting 3rd party weather info.

    What this means is when a user goes to the glance loop or opens the widget, it usually has data that's no more than 15 minutes old with no delay

    When complications were introduced, I just added publishing to the background services that have been useful for years..

    For users that are concerned about battery, they can configure the widget to only run the background every hour

    And by publishing, it means a watch face doesn't need to have it's own background service to display the weather info.  They can also be used by a FaceIt watchface.

  • My use case is a little different. My app displays data from a houses electrical installation (solar production, grid, house consumption, vehicle charging, ...). Most of data fluctuates a lot and showing 5 minute old data does not make much sense. When glance/widget/app are open, I do use data from previous requests only if it is newer than 1 minute and then update every 10 seconds.

    On glances on lower-memory devices I have to use a background service, and in that case I am only showing state of charge of the house battery and electric vehicle, which does not change that quickly. This background service is only enabled on those devices.

    For the complications I could use the same background service, but would then have to enable it for all devices.

  • If you have a widget with a background service that publishes at most every 5 minutes, or you have a background service in the watch face which runs at most every 5 minutes, you'll only see data at most every 5 minutes.  No way around that...

    You can't do comm in the main app of a watch face and backgrounds can only run every 5 minutes at most..

  • I guess the majority of my application's users would NOT use the complication. So the question is then if I really want to load all users with a background service, if only a minority would actually benefit from it.

    I know this is kind of stating the obvious, but you could always make the publishing of complication data an optional feature which is disabled by default. If publishing is disabled, then you don’t have to run the background service

  • It is kind of obvious, but still it did not occur to me. ;-) So thanks, I think that is a good suggestion, I'll simply make that a configurable item and the user can decide for themselves if they want to have the background service running to support the complication.