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. Thanks, Thomas > cheers, > John > > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
