ubuntu-phone team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

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?

> 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?

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

Ciao,
  Alberto