ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

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)

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/

Attachment: signature.asc
Description: OpenPGP digital signature