ubuntu-phone team mailing list archive

[Rick Spencer <rick.spencer@xxxxxxxxxxxxx>]

On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx>wrote:

> On 10/24/2013 02:00 PM, Rick Spencer wrote:
> > It's been interesting to read all the expected use cases, and also the
> > requirements for application developers. It's good to think hard about
> how we
> > fulfill these requirements, and do it well.
> >
> > What I liked about Thomas's first iteration of the application life
> cycle, is
> > that it is clean, simple, comprehensible, and works. To me, it seems
> that as an
> > app developer you get:
> > 1. the ability to do what you want when your app is in front and the
> phone is
> > not idle.
> > 2. a set of services via well known APIs to call for things where your
> app may
> > not be in front (i.e. music service, download service, alarm service
> etc...)
> >
> > I think that instead of thinking of ways to grant applications long
> running
> > processes, we should grow these services. For example, it sounds like a
> location
> > service may be required, etc...
> >
>
> I think that is where we landed:
> https://lists.launchpad.net/ubuntu-phone/msg04766.html
>
> Ie, we build out our services but application developers also have a way to
> implement their own background service if they need to.
>
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 if we go down the path of allowing folks to write background
services, then we may as well just allow the app to run in the background.

For completeness, I would expect a different policy to be in force when
running on a desktop. I could imagine that in desktop mode the policy
allows applications to run in the background. However,that is a discussion
for later ;)

Cheers, Rick