ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Tue, Oct 22, 2013 at 1:17 PM, Michael Zanetti
<michael.zanetti@xxxxxxxxxxxxx> wrote:
> Hi,
>
> my point of view is still that forcing every little small app to bring its own
> daemon will:
>
> a) scare off people for writing apps for our platform as the communication
> overhead between a service and the UI is a huge effort and easy to mess up.
>

I think that the benefits of aggressively freeing up GPU resources for
the user-facing process is the more valueable feature we gain here.
On top: Obviously, app devs have to be supported by our SDK/middleware
to be able to migrate certain functionality ex-process.

> b) be suicide in terms of battery usage. This will cause exactly the opposite
> than what it should. If everyone brings its own daemon we'll have tons of
> services running all the time and the user can't even stop them because there
> is no UI to stop them.

Well, we certainly won't allow a background process to go crazy and
will limit resources available to it.
On top, they will live in the same process group as the parent process
and we could control their lifetime, too.
For "not visible to users": Unity8 and, with that the user, an app
consists of all of its processes.

Thomas

>
> I do agree that for some use cases such a service is a good idea. But having
> the metronome app to ship a service? Really?
>
> Br,
> Michael
>
> On Tuesday 22 October 2013 11:33:54 John Lea wrote:
>>  From a design point of view, the guidance we are currently following is:
>>
>> - Only the app in the foreground when the phone is unlocked is
>> guaranteed to be running.
>>
>> - In all cases where an app requires functionality that needs to run in
>> the background and/or while the phone is locked, this functionality will
>> need to be split off into a separate daemon that will be packaged and
>> ship together with the foreground UI app.  The daemon will have no UI,
>> and it's functions will be started and stopped using the foreground UI app.
>>
>> Applying this guidance to the use cases below:
>>
>> On 21/10/13 23:46, Jamie Strandboge wrote:
>> >   * a metronome app for musicians to practice to (2 are in the app store
>> >   now)
>>
>> The metronome app could be split into a UI app and daemon.  The UI app
>> would start/stop the metronome and configure the sound/timing, and the
>> daemon would play the sound.  The daemon would continue playing the
>> sound irrespective of UI app state until the user switches the metronome
>> off via the UI app.  This is useful in the case where a musician wants
>> to set the metronome running, and then focus say a synthesiser app to
>> practice on.
>>
>> Just forcing the Metronome app to run when the phone is locked and the
>> metronome app is in the foreground does not support this use case, the
>> 'UI app' and 'deamon' approach seems a better fit.
>>
>> >   * a white noise app to help people sleep (1 in the store)
>>
>> Again I think splitting the White Noise app into a separate UI app and a
>> daemon that plays the sound is advantageous.  This is because the user
>> might for example also want to run a separate Sleep Pattern monitoring
>> app at the same time.  Restricting the White Noise app to only running
>> when it is in the foreground (irrespective of the phone lock state)
>> precludes this use case.  btw, the Sleep Pattern monitoring app would
>> also be broken into a UI app and a deamon.
>>
>> >   * a navigation app that speaks the directions to you as you drive (none
>> >   in the>
>> >     app store AFAIK, but this would be a wonderful addition)
>>
>> I think the UI app / deamon split is a better solution for the problem
>> as well (again because the user will sometimes want to perform other
>> tasks while the navigation app continues to speak directions).
>>
>> >   * internet radio apps (there are at least 2 in the store)
>>
>> I think the UI app / deamon split works here?
>>
>> >   * a 3rd party alarm clock (perhaps the API that the core app clock uses
>> >   is
>> >
>> >     sufficient-- I haven't checked)
>>
>> Same as above.
>>
>> It looks to me like the UI app / deamon split solves all the use cases
>> we have currently thought of, are there any reasons why we should not
>> follow this approach in all these cases?
>>
>> cheers,
>> John
>