On Tue, Oct 22, 2013 at 4:30 PM, Jamie Strandboge <[email protected]> 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 <[email protected]> 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/ > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
