← Back to team overview

ubuntu-phone team mailing list archive

Re: Thoughts on inhibiting app suspend via application lifecycle

 

On Fri, Oct 25, 2013 at 10:17 AM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> On 10/24/2013 10:36 PM, 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 disagree :-) I think this would be very limiting, because we won't be
> able to predict what applications need. And we'd being creating overly
> complex system services.
> Think again about the location service. I have on my phone an app which
> let's you plan public transport routes, and makes the phone vibrate when
> you are on the bus and the stop where you need to get off is approaching.
> Or a navigation app, which also warns you about speed limits: the
> application would need to upload all the speed limits information into
> the location service. And what if it wants to use a different algorithm
> to want the user when it's approaching the speed limit?
>

We obviously wouldn't built it that way, but the app could just tell
the location service to wake it up if a significant change in position
occurs (much like the iOS location service works). With that signal
available, the app can do whatever it wants with that information.

One thing that strikes me: Instead of trying to solve the problem a
lot of "won't work" statements are made in this thread, going along
with a request for removing all of the lifecycle policies. And to be
clear: With strict policies in place, it is always possible to find an
example that breaks. So I think we can stop collecting breaking
examples here.

>> 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.
>
> Yes and no. As I wrote before in this thread, in some cases it's
> possible to detect when an application will need to run or can be
> killed. We don't have to allow all applications to run in the
> background. But why not let a navigation application declare in its
> manifest file that it wants to be left running if it's defocused while
> the GPS is on?
>

Because that is an open invite to any app developer to leverage that
way out, too. We do not do install time application permission
verification by the user for a good reason.

> As for GPU resources, Qt can release all of them when the window is not
> exposed, if told to.
>

Hmmm, people said that about cooperative multi-tasking, too: Sure, the
app will happily give up its timeslice (tm).

Thomas

> Ciao,
>   Alberto
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp


Follow ups

References