ubuntu-phone team mailing list archive

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

On Tue, Oct 22, 2013 at 4:30 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
> Pulling in Zoltan, Daniel and David for comment
>
> On 10/22/2013 05:40 AM, Thomas Voß wrote:
>> 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.
>>
>
> It sounds like what we are saying is that we don't have to change anything in
> the system, we just need to communicate to developers how they should program
> within the system for these sorts of apps.
>
> Sounds like what is needed here is:
>  * the SDK to treat compiled apps as first class citizens (I know this is
>    planned, perhaps Zoltan can comment on its status)
>  * documentation on developer.ubuntu.com that explains in developer terms how
>    power management and application lifecycle work, specifically for HTML5,
>    Cordova, pure QML and this new QML ui with background service. I did
>    something similar for application confinement[1] which has been quite helpful
>  * provide an example QML ui with background daemon. We have a pure QML
>    tutorial[2][3] for a currency converter. Perhaps a simple white noise app
>    that uses qtmultimedia in the backend service would be a good example
>    (though a simple metronome might be better since the white noise app could
>    in theory use the media service). The docs[2] could call this 'QML with
>    background service' (or something)
>

+1, I can take existing documentation of the app lifecycle and put it
on the wiki. I'm travelling today, but back in service tomorrow.

Cheers,

  Thomas

> If we did the above, app developers know where they stand and they can get their
> work done now while we build out various system services and SDK support to
> better support common use cases. Daniel and David, what do you think about
> changes like this for http://developer.ubuntu.com? Does it make sense?
>
> [1]http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/
> [2]http://developer.ubuntu.com/apps/
> [3]http://developer.ubuntu.com/apps/qml/tutorial/
>
> --
> Jamie Strandboge                 http://www.ubuntu.com/
>