Rasmus, yes. I was very put off by Ubuntu Touch suspending (eg: commands running in the Terminal app) every time the device locked.
For 8 years now with their Maemo sdk Nokia provided to developers an easy pathway to battery-friendly media/dsp services, alarms/rtc, cell/gps location services, etc. but outside of OOM killer and watchdogs for their own daemons placed no restrictions on running programs. More of a carrot approach than stick. UI/daemon sounds promising to offer a similar experience to Android, but I hear alot of second-hand complaints about iOS or Android agressivly purging stock-browsers from RAM when multitasking away from more than 1 or 2 tabs. ..and also sounds like a large distance to cover to make background services more appealing to devs than an API - bjv (attempting to replace Nokia N900 with Ubuntu Touch on Galaxy Nexus; background media player + the gps in the browser since images 99 have been a big help.. Go team!) On Tue Oct 22 13:45:44 2013 Rasmus Eneman <ras...@eneman.eu> wrote: > > I do disagree with requiring the user to interact with the system to > > ensure longer battery life. We should try as hard as possible to make > > this automagically work. > > > For a tech-savvyy audience: Yes. For everyday users I do disagree. In > > the end, users do blame the platform for bad battery life (for a good > > reason) and we certainly don't want to have battery life preserving > > apps in our app store (Google Play has got quite a few of them). > While automagically is great when it works, it's a real hassle when it > don't. > I agree that users will be put of if there is a lot of battery drain, > however > users will also be put of if they can't use their phone as they would > expect (Android have become huge and more and more users learn that they > can do things in the background on their phone too). > > A golden path have to be found between features and battery. Personally > I think Android does pretty good here but I get a feeling that you don't? > > > my point of view is still that forcing every little small app to bring > > its > own > > daemon will: > > > > a) scare off people for writing apps for our platform as the > > communication overhead between a service and the UI is a huge effort > > and easy to mess up. > Android have AIDL > (http://developer.android.com/guide/components/aidl.html) to help > developers with this, I have used it and have to say that it's very > simple to use. Hopefully something like this could come to Ubuntu too > (it would make > sense on the desktop as well). > > > b) be suicide in terms of battery usage. This will cause exactly the > opposite > > than what it should. If everyone brings its own daemon we'll have tons > > of services running all the time and the user can't even stop them > > because > there > > is no UI to stop them. > Again: Android. > Android kills a service if the resources are needed, if the developer > wants to > create an app which have a responsible chance to stay alive even if the > user does something else he have to create an ongoing notification. This > makes to user aware that the app is running. > > > 2013/10/22 Jamie Strandboge <ja...@canonical.com> > > > 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....@canonical.com> > > 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/ > > > > > > -- > > Mailing list: https://launchpad.net/~ubuntu-phone > > Post to : ubuntu-phone@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~ubuntu-phone > > More help : https://help.launchpad.net/ListHelp > > > > > > > -- > Rasmus Eneman -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
