ubuntu-phone team mailing list archive

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

On Tue, Oct 22, 2013 at 12:33 PM, John Lea <john.lea@xxxxxxxxxxxxx> 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?
>

Nope, I do fully agree with your examples here. And it is close to the
aforementioned Activity/Service approach.

Thanks,

  Thomas

> cheers,
> John
>
>