ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Thu, 2013-10-24 at 15:36 -0400, Rick Spencer wrote:
> So I am saying the opposite. Rather than allowing apps to create
> background services I think we should stick to the original vision.
> Apps use well known APIs for their functionality, or the the user
> keeps the app in front and alive on the phone. I think there should be
> no "background processes" other than what is available on the base
> system. This system we have started down is clean, simple, and very
> hard to subvert. The hard part is providing the correct set of APIs so
> that app developers do not wish they could write such services.

I think that this is a really great goal, and we should strive to have
all of the user session services provide useful interfaces for app
developers.  For instance, I think it's becoming clear that the location
service should probably handle things like GPS traces.

I think that what we can do here is make running a background task a
choice of last resort for developers.  For instance, we could require
every background process to have an application indicator, thus making
it very visible to the user that something is running.  Users would
naturally not want to clutter up their panels with hundreds of icons, so
apps with background services would need to be justified and likely
rare.

I also think that we should tease out the use-cases for things that are
long running background services and those that are "helpers" to other
tasks in the system.  For instance, it might make sense for an app to
have a small bit of code run on a push notification to determine how it
should be visualized to the user (or ignored).  These helpers have
limited lifecycles and I think we should look at ways to manage them
differently than background services.  Perhaps the Grooveshark case
could be a helper for the sound-service that would manage it's lifecycle
more aggressively.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part