I am writing an app which mainly is used to update data used by other apps on the device. After the user initializes some values in the app, they almost never have to return to it (occasionally to add a "friend").
What you're describing seems to fall into a category of apps where the user:
-
Wants the app to "work", meaning "run at some kind of regular/reliable interval so that it can do what it does".
-
Does NOT want to "use" the app, meaning "launch and/or interact with the app on a regular basis".
As things currently stand, this is not an app situation the system supports very well. Both current task types are scheduled based on usage, which means that processing tasks will stop running unless the user interact with your app on some kind of "regular" basis. You can make an app that works within that limitation, but it will require some kind of regular interaction from the user.
So, the first thing I would recommend here is that you file an enhancement request describing in as much detail as possible what you're actually trying to do, then post the feedback number back to this thread. As a said above, it's understood that this kind of usage pattern isn't something the current API supports very well, so bugs are important both to document developer interest and get a clearer picture of what developers want to use this API "for".
Moving to the state of things today:
The app needs to run a background task at least daily, however, without the user's intervention (or even awareness, once they've given permission). My understanding of background refresh tasks is that if the user doesn't activate the app in the foreground periodically, the scheduled background tasks may never run. If this is true, do I want to use a background processing task instead, or is there a better solution (or have I misunderstood entirely)?
Yes, you're understanding isn basically correct. More specifically:
-
Refresh task just won't work for this. Their scheduling is HEAVILY driven by on device usage patterns, so in an app like you're describing (where the user "never" runs the app), they'll basically never fire.
-
Background task might work, with some qualifications. In terms of scheduling, they're designed to run when the device is "known" to be unused based on device heuristics, which generally means they end up running in the middle of the night when the device is charging. Most apps can expect to be able to run their work "every day or so", with "skipped" days typically being caused by exceptions in user behavior (forget to plug in phone, used phone all night, etc...) or the device having to much deferred work to complete "all" tasks on any particular cycle.
In addition, you'll need to come up with some kind of mechanism to ensure that the system still considers your app as "being used". The specifics of what the looks like are something you'll need to work out for yourself, but typically that involves using notification let the user foreground and/or launch the app into the background every day or two so that the system considers the app to be in "active" use.
Finally, make sure you take a look at this forum post before you start experimenting with this API. This API can be trickier to use or test that it seems and I've seen many developers waste considerable time because their testing was distorted or they'd made a few common mistakes.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
