← Back to team overview

ubuntu-phone team mailing list archive

Re: Background services: a problem that we need to face

 

On Wed, Jun 25, 2014 at 12:29 PM, Rodney Dawes
<rodney.dawes@xxxxxxxxxxxxx> wrote:
> On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
>> On 14-06-25 02:11 PM, Rodney Dawes wrote:
>> >
>> > I don't now, nor have I ever, owned any iOS devices. Nor have I
>> > developed any apps for them.

I do own an iOS device (iPhone 4s).

>> > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
>> >
>> > Apps can have long-running background tasks for certain things, on iOS.
>>
>> Apps can only run in the background for a limited time, and they can use certain
>> APIs to get woken up regularly, but they can't run in the background save for a
>> few exceptions. This is why IRC apps on iOS disconnect after a few minutes, or
>> are designed for jailbroken devices.
>
> No, apps can run in the background indefinitely, per the documentation
> link I provided above, in order to handle a situation in the specific
> list of situations described in that documentation.

No -- iOS apps do not *actually* run in the background indefinitely.
This is trivially observable on an iPhone.

- start Strava (GPS app to track your running/cycling data)
- launch the camera in HDR mode, take a photo of the awesome scenery
- load Google Maps app to figure out your next turn

Go back into Strava and observe that it has been killed by the OS.
Strava will ask you if you wish to resume recording from last known
point.

I haven't used your automotive app you point out, but I would bet
(0.25 bitcoins ;) that if you tried a similar sequence of actions, you
would eventually see the OS kill off the app.

What you perceive as "indefinite background app" is in reality the iOS
framework blackbox doing a lot of heavy lifting and making policy
decisions on behalf of the apps and the end user. Strava pretends to
be an indefinitely running app recording GPS coordinates, but the
actual implementation is more similar to Strava subscribing to the
location services API, and writing a little callback to do something
with the data that comes in occasionally.

[note: as I have never seen the iOS framework code, I am only guessing
here, but my guesses are at least based on a careful reading of the
APIs and actual experience with iOS apps ;) ]

> Skype does not
> automatically disconnect after a few minutes. And AFAIK, it does not
> need to remain in the foreground to stay on a call.

Skype may not automatically disconnect, but that does not mean it is
actually running in the background. Again, the iOS telephony framework
is running in the background and Skype subscribes to the API. It gets
woken up by the telephony service when an incoming call comes in.

> Maybe the app with full UI needs to remain open always on iOS, and there
> are not actual separate background processes without UI, but they do not
> need to remain in the foreground to remain processing.

Ubuntu's approach is modeled after the iOS approach, which is to let
apps subscribe to a functional API (play background music, location
services, etc.). The actual implementation of how the OS accomplishes
the perception of "background" tasks is thus abstracted from app
developers.

Android is proof that users cannot make informed decisions. Observe
how they are tightening up their APIs and discouraging use of raw
wakelocks, and moving their developers to the same API subscription
model.

As Sergio points out, the implementation still has a lot of pieces
in-flight. If you think that our API is missing support for
"specialized background processing", then please
propose/design/request a specific platform-wide API that all apps can
use.

Providing a generic "run as a daemon" capability only makes sense on
platforms where you do not care about battery life or power
consumption.


Follow ups

References