Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Hey guys, I just spent an hour reading 55 emails in this thread. The last reply was 4 days ago, so I can see the discussion dying out, but I can't see any conclusions building up. The service-only approach, while very easy to manage as an OS, sounds extremely limited. And countless arguments can be found against it. The policy approach, while it sounds empowering to the developers, it will end up being abused. There would be the permission approach, where the app would ask the user directly can I run in the background?, but, in the lack of context, the user will just get confused. There would be the show background apps currently running in the background so I can make an informed decision about what I want running, but the average Joe (e.g. my mum) would get easily confused by that. Just throwing a wild idea: what about collecting battery usage data from users for each app and then in the store display a warning sign This app is a resource hog!? Zisu Andrei On 28 October 2013 06:22, Alberto Mardegan alberto.marde...@canonical.comwrote: On 10/27/2013 08:08 PM, Thomas Voß wrote: I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. What prevents every app from just doing that? One example: When iOS had the policy of an app playing music not being suspended, a lot of applications just looped a whitenoise sound file to not be suspended. OK, this looks like a very strong point not to allow music applications to be run in the background, but provide them with a background service. Unless there is a non-costly way of detecting the case where an application has been playing an almost silent sound for the last minute. However, I still think that we shouldn't apply the same rule for the GPS. Here if one application declares that it' using it just for the sake of keeping running in the background, the user has a visible indicator for it, and can deactivate the GPS. Also writing a system background service for the GPS is much more difficult than writing a background service for playing sounds (for the GPS, we have much more complex logic). Ciao, Alberto -- 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 -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/27/2013 08:08 PM, Thomas Voß wrote: I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. What prevents every app from just doing that? One example: When iOS had the policy of an app playing music not being suspended, a lot of applications just looped a whitenoise sound file to not be suspended. OK, this looks like a very strong point not to allow music applications to be run in the background, but provide them with a background service. Unless there is a non-costly way of detecting the case where an application has been playing an almost silent sound for the last minute. However, I still think that we shouldn't apply the same rule for the GPS. Here if one application declares that it' using it just for the sake of keeping running in the background, the user has a visible indicator for it, and can deactivate the GPS. Also writing a system background service for the GPS is much more difficult than writing a background service for playing sounds (for the GPS, we have much more complex logic). Ciao, Alberto -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Fri, 2013-10-25 at 19:27 +0200, Rasmus Eneman wrote: Having only a set of default services would be very limiting. Even if a music background service could take streams to support metronome-like apps, how about Spotify or Grooveshark? They both have a lot of security built in and you can't just take a stream and start playing, you have to talk with their servers, make sure you download the streams in correct speed (too fast and they will think your downloading their music, too slow and the listener will be sad) and have a lot of stuff setup just for them to trust you. Download service? No, a music service with special support for Spotify, and Grooveshark, and Muzu and whatever music streaming service that are out there that uses a special protocol that uses a lot of shatter to make sure you are using the data to play music and not download it. This is of particular interest to me at the moment, as I'm porting MeeSpot (a MeeGo spotify client) to Ubuntu Touch (an early video of which can be seen here: http://www.youtube.com/watch?v=ErscrflfQKI ). libspotify basically requires you to handle little buffers of audio frequently (sent either over the network or loaded from disk), so couldn't be handed off to a generic music service. Rewriting all the spotify communication and audio playback side as a daemon would be possible, but would be something of a pain since it'd go from being a fairly straight forward port of MeeSpot to a pretty major refactor. Rather than coming primarily from Android where such separations appear to be the norm I'm coming from the Maemo/MeeGo/Mer/Sailfish world, where all applications are given free reign to run in the background completely as they see fit. As a developer this makes life much simpler and as a user I've not come across much in the way of Maemo or MeeGo applications that cause significant power drainage issues. So I'd caution against making life much harder for developers (and for yourselves) over a perceived problem that may not be as large as you anticipate. But as a developer I would say that ;). Cheers, Mike. -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Would it not be an idea to make a plugin based system. For instance if someone wants to make a torrent downloader they'd make a plugin for the download service to handle the connections, pieces, etc and then make a front-end to initiate and monitor downloads, and change connection settings. Same idea for sound, etc. I see it would be quite complicated to implement though, so not really ideal. -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Hi, Am 25.10.2013 19:48, schrieb Thomas Voß: One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I disagree. If you want Ubuntu Touch to be successful, you need users. And users want apps. In order to be able to offer a rich selection of apps, you also need app developers. Limiting app developers to basically create wrappers around system services might alienate them. Sure, in order to avoid the android background service mess, a strict lifecycle policy is required and I like most of your ideas. Create powerful system services that make it possible to do stuff easily and in a power-efficient way. But there *are* apps where one size fits all doesn't work and something like an actual background service (or wakelock no suspend) is required. Any app developer who whishes to create such an app will be unhappy and might consider not creating anything for Ubuntu Touch at all. The more breaking examples we can enumerate, the more app developers are possibly affected. Let me add one breaking example that sells (from my poor student POV) relatively well on Google Play and had more than 200k downlods and a rating of 4.5/5 in the short time span when it was a free download, so there is an interested user base for something like that. The app takes a file produced by some other popular app. That file grows larger than a few MBs quite fast. The file's content is analyzed and the app creates statistics based on the file contents. Since that process can easily take a few minutes (sometimes 20 minutes) even on modern hardware, it is done in a background process while holding a (partial) wakelock. Every night the statistics are updated (taking 1 min usually), triggered by an alarm and while holding a (partial) wakelock. The only possible solution for this on Ubuntu Touch? Please wait. ETA: 20 mins. Also, please touch the display once every 30 sec and don't leave this app. Thank you. I suggest allowing background services, but only if the developer can state a very good reason when doing the upload and generally advice against using it whenever possible. This would need some kind of pre-approval so dev work is not wasted in case the approval fails. I think most apps work without the background service, so it's not a lot of review work. Also, if a background service is active, indicate that to the user (or maybe only after ~30sec of activity) and allow them to cancel the operation and disable background work for that app. Cheers, Florian -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Sun, Oct 27, 2013 at 5:43 AM, Florian Will florian.w...@gmail.comwrote: Hi, Am 25.10.2013 19:48, schrieb Thomas Voß: One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I disagree. If you want Ubuntu Touch to be successful, you need users. And users want apps. In order to be able to offer a rich selection of apps, you also need app developers. Limiting app developers to basically create wrappers around system services might alienate them. Sure, in order to avoid the android background service mess, a strict lifecycle policy is required and I like most of your ideas. Create powerful system services that make it possible to do stuff easily and in a power-efficient way. But there *are* apps where one size fits all doesn't work and something like an actual background service (or wakelock no suspend) is required. Any app developer who whishes to create such an app will be unhappy and might consider not creating anything for Ubuntu Touch at all. The more breaking examples we can enumerate, the more app developers are possibly affected. Let me add one breaking example that sells (from my poor student POV) relatively well on Google Play and had more than 200k downlods and a rating of 4.5/5 in the short time span when it was a free download, so there is an interested user base for something like that. The app takes a file produced by some other popular app. That file grows larger than a few MBs quite fast. The file's content is analyzed and the app creates statistics based on the file contents. Since that process can easily take a few minutes (sometimes 20 minutes) even on modern hardware, it is done in a background process while holding a (partial) wakelock. Every night the statistics are updated (taking 1 min usually), triggered by an alarm and while holding a (partial) wakelock. The only possible solution for this on Ubuntu Touch? Please wait. ETA: 20 mins. Also, please touch the display once every 30 sec and don't leave this app. Thank you. This sounds kind of far fetched. Who would do something like this on their phone? I think it's fair to point out apps that simply won't work for users (Spotify for example), but we shouldn't optimize for entirely hypothetical situations. Cheers, Rick -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/25/2013 08:48 PM, Thomas Voß wrote: One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I think that Ubuntu should strive to do *better* than other platforms, not equal or worse. So, given that we are at the early stages and we are still in a position to correct the design and improve the implementations, we should spend some time to think of use cases which we don't support with the current design, and address them. Especially given that it might not be easy to change this stuff in the future. Yes and no. As I wrote before in this thread, in some cases it's possible to detect when an application will need to run or can be killed. We don't have to allow all applications to run in the background. But why not let a navigation application declare in its manifest file that it wants to be left running if it's defocused while the GPS is on? Because that is an open invite to any app developer to leverage that way out, too. We do not do install time application permission verification by the user for a good reason. I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. As for GPU resources, Qt can release all of them when the window is not exposed, if told to. Hmmm, people said that about cooperative multi-tasking, too: Sure, the app will happily give up its timeslice (tm). You are right that we cannot depend on this. But the display server can know the amount of GPU resources that each application is using, and kill those which use more of them; in this way, an application which properly releases all the GPU resources would probably be saved. Anyway, I now realize that this is actually not the issue we were discussing (this is about killing, while the discussion is about stopping), so we can forget about this second topic. :-) Ciao, Alberto -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. Personally I don't really see a win by doing this instead of an ordinary wakelock, it creates a lots of policy groups and the developer can still do the same stuff. One thing I thought about is a two staged background running process. By default each app can only use a very limited one with very capped CPU, network and may easily be killed if needed. And one that requires a user confirmation that enables more conventional background polices and let the app use more CPU, network and isn't killed unless really necessary. One other idea is too change recent apps into running apps or add a category for running apps (however I don't think that would be necessary, stopped apps may still be in here. For what the users worth it's still running). Then the user sees very easily what's running and may choose to stop it if wanted. If an app is closed (from running apps or the HUD) it should be really closed, and no background processes or anything should be running. I think this simplifies the Android model quite a bit, while still giving the same flexibility and makes the user more aware of what's running and why. By having a user aware of this battery is saved. This would also make users feel that the phone works similar to the computer they already uses. This together with the already suggested things to limit the things apps need background services for could be a pretty good solution. 2013/10/27 Alberto Mardegan alberto.marde...@canonical.com On 10/25/2013 08:48 PM, Thomas Voß wrote: One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I think that Ubuntu should strive to do *better* than other platforms, not equal or worse. So, given that we are at the early stages and we are still in a position to correct the design and improve the implementations, we should spend some time to think of use cases which we don't support with the current design, and address them. Especially given that it might not be easy to change this stuff in the future. Yes and no. As I wrote before in this thread, in some cases it's possible to detect when an application will need to run or can be killed. We don't have to allow all applications to run in the background. But why not let a navigation application declare in its manifest file that it wants to be left running if it's defocused while the GPS is on? Because that is an open invite to any app developer to leverage that way out, too. We do not do install time application permission verification by the user for a good reason. I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. As for GPU resources, Qt can release all of them when the window is not exposed, if told to. Hmmm, people said that about cooperative multi-tasking, too: Sure, the app will happily give up its timeslice (tm). You are right that we cannot depend on this. But the display server can know the amount of GPU resources that each application is using, and kill those which use more of them; in this way, an application which properly releases all the GPU resources would probably be saved. Anyway, I now realize that this is actually not the issue we were discussing (this is about killing, while the discussion is about stopping), so we can forget about this second topic. :-) Ciao, Alberto -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
One simple add: I do say background services a lot, however just letting apps run in the background would basically be the same thing. That's a weigh between simple code (portability?) and forcing developers to not do anything graphical while in the background. 2013/10/27 Rasmus Eneman ras...@eneman.eu I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. Personally I don't really see a win by doing this instead of an ordinary wakelock, it creates a lots of policy groups and the developer can still do the same stuff. One thing I thought about is a two staged background running process. By default each app can only use a very limited one with very capped CPU, network and may easily be killed if needed. And one that requires a user confirmation that enables more conventional background polices and let the app use more CPU, network and isn't killed unless really necessary. One other idea is too change recent apps into running apps or add a category for running apps (however I don't think that would be necessary, stopped apps may still be in here. For what the users worth it's still running). Then the user sees very easily what's running and may choose to stop it if wanted. If an app is closed (from running apps or the HUD) it should be really closed, and no background processes or anything should be running. I think this simplifies the Android model quite a bit, while still giving the same flexibility and makes the user more aware of what's running and why. By having a user aware of this battery is saved. This would also make users feel that the phone works similar to the computer they already uses. This together with the already suggested things to limit the things apps need background services for could be a pretty good solution. 2013/10/27 Alberto Mardegan alberto.marde...@canonical.com On 10/25/2013 08:48 PM, Thomas Voß wrote: One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I think that Ubuntu should strive to do *better* than other platforms, not equal or worse. So, given that we are at the early stages and we are still in a position to correct the design and improve the implementations, we should spend some time to think of use cases which we don't support with the current design, and address them. Especially given that it might not be easy to change this stuff in the future. Yes and no. As I wrote before in this thread, in some cases it's possible to detect when an application will need to run or can be killed. We don't have to allow all applications to run in the background. But why not let a navigation application declare in its manifest file that it wants to be left running if it's defocused while the GPS is on? Because that is an open invite to any app developer to leverage that way out, too. We do not do install time application permission verification by the user for a good reason. I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. As for GPU resources, Qt can release all of them when the window is not exposed, if told to. Hmmm, people said that about cooperative multi-tasking, too: Sure, the app will happily give up its timeslice (tm). You are right that we cannot depend on this. But the display server can know the amount of GPU resources that each application is using, and kill those which use more of them; in this way, an application which properly releases all the GPU resources would probably be saved. Anyway, I now realize that this is actually not the issue we were discussing (this is about killing, while the discussion is about stopping), so we can forget about this second topic. :-) Ciao, Alberto -- Mailing list: https://launchpad.net/~ubuntu-phone Post to :
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Sun, Oct 27, 2013 at 5:50 PM, Alberto Mardegan alberto.marde...@canonical.com wrote: On 10/25/2013 08:48 PM, Thomas Voß wrote: One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I think that Ubuntu should strive to do *better* than other platforms, not equal or worse. So, given that we are at the early stages and we are still in a position to correct the design and improve the implementations, we should spend some time to think of use cases which we don't support with the current design, and address them. Sure. Especially given that it might not be easy to change this stuff in the future. That I fully agree with, and for that, we should be very careful about which features and capabilities we grant to applications. Yes and no. As I wrote before in this thread, in some cases it's possible to detect when an application will need to run or can be killed. We don't have to allow all applications to run in the background. But why not let a navigation application declare in its manifest file that it wants to be left running if it's defocused while the GPS is on? Because that is an open invite to any app developer to leverage that way out, too. We do not do install time application permission verification by the user for a good reason. I think we are misunderstanding; I'm not saying that the user should be asked (at install time or at run time) for granting a permission. There would be a policy groups background_gps, background_music which the app developer can declare in its manifest file. Then, if the application is defocused while it's using the GPS or playing music, it wouldn't be stopped. If it's not using the GPS or playing music, it will be stopped. It seems much simpler to me, and I don't see what could go wrong here. What prevents every app from just doing that? One example: When iOS had the policy of an app playing music not being suspended, a lot of applications just looped a whitenoise sound file to not be suspended. As for GPU resources, Qt can release all of them when the window is not exposed, if told to. Hmmm, people said that about cooperative multi-tasking, too: Sure, the app will happily give up its timeslice (tm). You are right that we cannot depend on this. But the display server can know the amount of GPU resources that each application is using, and kill those which use more of them; in this way, an application which properly releases all the GPU resources would probably be saved. Anyway, I now realize that this is actually not the issue we were discussing (this is about killing, while the discussion is about stopping), so we can forget about this second topic. :-) Sure, we can be clever about graphics resources, but at some point, we would need to destroy the apps egl context and require toolkits/apps to be EGL context robust and being able to handle that case. Of course, this is not a blocker, just something we do not have right now and which would require effort to implement. Thomas Ciao, Alberto -- 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 -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Hi Rick, Am 27.10.2013 16:25, schrieb Rick Spencer: This sounds kind of far fetched. Who would do something like this on their phone? More than 200k android users who downloaded the app that I described. I don't think it's a phone! is a valid excuse for not allowing any CPU intensive task in a sane way. Maybe I want to mine bitcoins on my phone while I'm asleep and it's connected to the charger? (Okay now this is really hypothetical..) I think it's fair to point out apps that simply won't work for users (Spotify for example), but we shouldn't optimize for entirely hypothetical situations. I described such an app in my mail from earlier today, and it's in fact not at all hypthetical, but you can download this app for android if you'd like to. To be more clear, the file being parsed by the app I described contains a history of messages exchanged using an instant messenger app. Apparently, there's a user base interested in statistics about their chat history. I realize this specifc app won't work for at least one other (good) reason on Ubuntu Touch. The confinement won't allow my app to access files created by another app without the user's explicit agreement, which is not required on Android for files on SD. But that is not my point. I just want to be able to use the CPU in my phone if I ever feel the need to do so. And I also want to allow others to use any CPU intensive apps I created if they like it. :-) I'm fine with restrictive defaults and requiring user effort to allow possibly unwanted things going on in the background for specific apps, but I don't agree with making those *possibly* unwanted things generally impossible. I consider my phone to a computing device after all. Cheers, Florian -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Wed, Oct 23, 2013 at 3:27 PM, Ted Gould t...@ubuntu.com wrote: On Wed, 2013-10-23 at 11:09 +0200, Thomas Voß wrote: On Tue, Oct 22, 2013 at 8:45 PM, Rasmus Eneman ras...@eneman.eu wrote: 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). AIDL is *another* middleware that helps in implementing an out-of-process component model. That being said, we will need something comparable. And before people start asking: I think we need to help developers with a layer on top of raw dbus to make this as convenient and easy as possible. We can probably hijack existing object hierarchies, but might as well come up with something that is less coupled to a specific object model. I realize that this isn't exactly what you're saying, but I don't think we want to necessarily use DBus here, at least on a well known bus (session). We've restricted the use of well known names (which is good IMHO) but that makes finding your background service slightly difficult. It seems like what ever protocol goes across it, doing something that only relies on flies in the application's cache directory I think would be more robust. Agreed, dbus is just a placeholder here and the actual communication protocol is TBD. However, it is an implementation detail that we should avoid to leak to app developers. I think that we also need to ensure that what ever defines the background service doesn't imply that protocol. For instance a background service that just writes to an SQLite DB seems valid to me. +1, with a default implementation available that eases a developer's life. Thomas Ted -- 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 -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Thursday 24 October 2013 15:36:11 Rick Spencer wrote: On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge ja...@canonical.comwrote: On 10/24/2013 02:00 PM, Rick Spencer wrote: It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... I think that is where we landed: https://lists.launchpad.net/ubuntu-phone/msg04766.html Ie, we build out our services but application developers also have a way to implement their own background service if they need to. So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I think that if we go down the path of allowing folks to write background services, then we may as well just allow the app to run in the background. I agree. Why introduce all the complexity of IPC? It will bring in issues for sure, besides killing any portability from other platforms as apps require major architectural changes in order to be split into app + service. For the user, the only outcome of those background services is that it's even harder to understand what is there running and consuming the battery. I do not agree on the opinion that we should _only_ allow system services, as that will create a tremendous amount of required features for those daemons and still make a lot of use cases impossible because we can't handle all. I do think that for as many use cases as possible we should go for system services, but not restrict apps to only have those. Why not just adding a capability for running in background? AFAIK it is planned to allow the user granting/rejecting single capabilites. Rejecting that capability would still cause the app to be stopped (with all the implications that brings ofc) if the user wants so. Additionally we should help the developer optimize his app, e.g. with clear, well documented signals on when UI updates should be stopped/minimized because in the background. Access to hardware resources (e.g. GPS updates, network bandwith etc) could be limited and slowed down. We could have a watchdog that checks for excessive CPU usage and still stops a background app if we feel it's behaving too nasty because of bad implementation. And there are more things I could think of in terms of saving battery. But I still think freezing an app and require the developer to implement background services just brings unneeded complexity with only little benefit. IMO key is to support the developer in making good stuff, instead of locking it down and forcing it to find workarounds for still delivering the use case he needs. For completeness, I would expect a different policy to be in force when running on a desktop. I could imagine that in desktop mode the policy allows applications to run in the background. However,that is a discussion for later ;) Having such a set of helpers for saving battery, or a watchdog that informs the user of excessive background resource wasting would be useful for th desktop too. While I don't think the forceful freezing of applications would work reasonably well on traditional desktop apps anytime soon. Br, Michael -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Friday 25 October 2013 09:35:26 Michael Zanetti wrote: On Thursday 24 October 2013 15:36:11 Rick Spencer wrote: On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge ja...@canonical.comwrote: On 10/24/2013 02:00 PM, Rick Spencer wrote: It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... I think that is where we landed: https://lists.launchpad.net/ubuntu-phone/msg04766.html Ie, we build out our services but application developers also have a way to implement their own background service if they need to. So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I think that if we go down the path of allowing folks to write background services, then we may as well just allow the app to run in the background. I agree. Why introduce all the complexity of IPC? It will bring in issues for sure, besides killing any portability from other platforms as apps require major architectural changes in order to be split into app + service. For the user, the only outcome of those background services is that it's even harder to understand what is there running and consuming the battery. I do not agree on the opinion that we should _only_ allow system services, as that will create a tremendous amount of required features for those daemons and still make a lot of use cases impossible because we can't handle all. I do think that for as many use cases as possible we should go for system services, but not restrict apps to only have those. Why not just adding a capability for running in background? AFAIK it is planned to allow the user granting/rejecting single capabilites. Rejecting that capability would still cause the app to be stopped (with all the implications that brings ofc) if the user wants so. Additionally we should help the developer optimize his app, e.g. with clear, well documented signals on when UI updates should be stopped/minimized because in the background. Access to hardware resources (e.g. GPS updates, network bandwith etc) could be limited and slowed down. We could have a watchdog that checks for excessive CPU usage and still stops a background app if we feel it's behaving too nasty because of bad implementation. And there are more things I could think of in terms of saving battery. But I still think freezing an app and require the developer to implement background services just brings unneeded complexity with only little benefit. Oh, and I forgot. In the UI it should be really, I mean *really* easy for the user to close an app. It should be no more efforts than bringing it to be background (e.g. just swiping from another edge, or ending the minimize swipe on a certain spot). That will cause the user to close more stuff when he doesn't need. Would have the additional benefit that the right edge gesture actually becomes useful again because there aren't 10 apps to cycle trough in order to find the wanted one. IMO key is to support the developer in making good stuff, instead of locking it down and forcing it to find workarounds for still delivering the use case he needs. For completeness, I would expect a different policy to be in force when running on a desktop. I could imagine that in desktop mode the policy allows applications to run in the background. However,that is a discussion for later ;) Having such a set of helpers for saving battery, or a watchdog that informs the user of excessive background resource wasting would be useful for th desktop too. While I don't think the forceful freezing of applications would work reasonably
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Friday 25 October 2013 09:56:03 Thomas Voß wrote: On Fri, Oct 25, 2013 at 9:35 AM, Michael Zanetti michael.zane...@canonical.com wrote: On Thursday 24 October 2013 15:36:11 Rick Spencer wrote: On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge ja...@canonical.comwrote: On 10/24/2013 02:00 PM, Rick Spencer wrote: It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... I think that is where we landed: https://lists.launchpad.net/ubuntu-phone/msg04766.html Ie, we build out our services but application developers also have a way to implement their own background service if they need to. So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I think that if we go down the path of allowing folks to write background services, then we may as well just allow the app to run in the background. I agree. Why introduce all the complexity of IPC? It will bring in issues for sure, besides killing any portability from other platforms as apps require major architectural changes in order to be split into app + service. For the user, the only outcome of those background services is that it's even harder to understand what is there running and consuming the battery. Well, a user shouldn't have to care (I'm talking in terms of the average phone/tablet user here). For IPC: I'm not convinced that we would need to expose such a low-level detail to developers under the assumption that we provide a sensible middleware/abstraction that easily allows a developer to define tasks. Communication then is on our plate and we can solve it in a central place. The communication between the background task either needs to be based on and limited to some generic format (i.e. jsonrpc). To do more (for example D-Bus), interface, type descriptions, serializers etc need to be available and end up on the app developer's plate somehow. I don't see yet how this would be flexible/powerful and transparent to app developer at the same time. I do not agree on the opinion that we should _only_ allow system services, as that will create a tremendous amount of required features for those daemons and still make a lot of use cases impossible because we can't handle all. I do think that for as many use cases as possible we should go for system services, but not restrict apps to only have those. Why not just adding a capability for running in background? AFAIK it is planned to allow the user granting/rejecting single capabilites. Rejecting that capability would still cause the app to be stopped (with all the implications that brings ofc) if the user wants so. Opening up a capability like that will almost surely be set as a default and we would pass on the responsibility to the user to handle and maintain the list of running apps. I'm especially concerned about forcing the user to deal with process states and requiring a mental model of how an app is executed on the system. I don't think this capability would be set by default and also only turned on by apps that require it. For the user maintaining a list of running apps: We are introducing new stuff to learn for the user every day. I don't see why the one thing that has been around on every computing device since multitasking got invented (closing apps) should be the one a user can't handle. You don't require a mental model for that. Each time you use the right edge you get presented with all the stuff hanging around. Having an easy way to dismiss unused stuff would not be that hard to get I think.
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Having only a set of default services would be very limiting.
Even if a music background service could take streams to support
metronome-like apps, how about Spotify or Grooveshark?
They both have a lot of security built in and you can't just take a
stream and start playing, you have to talk with their servers,
make sure you download the streams in correct speed (too fast and they
will think your downloading their music, too slow and
the listener will be sad) and have a lot of stuff setup just for them to
trust you.
Download service?
No, a music service with special support for Spotify, and Grooveshark, and
Muzu and whatever music streaming service that are
out there that uses a special protocol that uses a lot of shatter to make
sure you are using the data to play music and not download
it.
And what about smart alarm clocks that’s monitors your sleep cycle?
Microphone service?
I thought of those which monitors your phones accelerometer and finds out
how much you moves and using a special algorithm they
can calculate your sleep cycle and they finds out when they should wake you
up to make you most awake.
Sure you could create a standard service that does that, but do you really
think it's possible to create a service for every possible
application you can think of?
I don't have much experience with C++ but if I wrote my app in Java the
dream scenario for built in IPC would be something like:
An interface for receiving events and an abstract class (that extends
Thread and implements this interface) for my background
process to extend which could give something like:
class BackgroundTask extends BackgroundProcess {
protected override onMessage(string message) {
if (message.equals(Start working) {
send(Work done!);
}
}
}
class Main implements IPCListener {
BackgroundTask b;
public static void main (String[] args) {
b = new BackgroundTask();
b.start();
b.send(Start working);
}
protected override onMessage(string message) {
if (message.equals(Work done!) {
b.kill();
}
}
}
Now it's up to the BackgroundProcess class to handle all IPC and make sure
that onMessage gets called on correct thread. The
only thing the developer needs to take care of is that everything sent to
the background (or foreground) need to be serializable.
By default everything should be thread safe and beautifully simple to use.
By default BackgroundTask now continues to run even if the user leaves the
app. If BackgroundTask also needs to stop the device
from sleeping it should call some system class or something.
Now, again. I'm not very familiar to C++ but I guess that somewhat the same
approach should be doable.
Now work could be focused on how to make sure a background process don't
consume all battery. Some ideas:
* Ask the user if the app should be allowed to stop the device from
sleeping, or at least make it possible to prevent apps from using
wake locks by a setting in system settings.
* Run with lower priority (well this is more a user experience thing rather
than a battery thing)
* Cap the CPU and memory usage.
* Make the user aware that something is running, for example all apps that
have a background process running should show up in
and if the user closes the app (using long click and cross) then the
background process would be killed too.
* Limit the number of simultaneous background processes (if I remember
correctly iPhone limits them to four).
2013/10/25 Rick Spencer rick.spen...@canonical.com
On Thu, Oct 24, 2013 at 6:28 PM, Rasmus Eneman ras...@eneman.eu wrote:
Having only a set of default services would be very limiting.
Even if a music background service could take streams to support
metronome-like apps, how about Spotify or Grooveshark?
They both have a lot of security built in and you can't just take a
stream and start playing, you have to talk with their servers,
make sure you download the streams in correct speed (too fast and they
will think your downloading their music, too slow and
the listener will be sad) and have a lot of stuff setup just for them to
trust you.
Download service?
And what about smart alarm clocks that’s monitors your sleep cycle?
Microphone service?
Or my banks app that shows the amount of money on my account when I shake
my phone?
Not certain why this would ever happen in the background, but there should
be a sensor service, right?
I understand what you are saying, but I still don't think we should give
up so easily. Constraints are good, and lead to a lot of creativity and
good design. I think we should stay confident in our initial design and not
stray from the path until we are very certain that it won't work.
Cheers, Rick
--
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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Fri, Oct 25, 2013 at 10:17 AM, Alberto Mardegan alberto.marde...@canonical.com wrote: On 10/24/2013 10:36 PM, Rick Spencer wrote: So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I disagree :-) I think this would be very limiting, because we won't be able to predict what applications need. And we'd being creating overly complex system services. Think again about the location service. I have on my phone an app which let's you plan public transport routes, and makes the phone vibrate when you are on the bus and the stop where you need to get off is approaching. Or a navigation app, which also warns you about speed limits: the application would need to upload all the speed limits information into the location service. And what if it wants to use a different algorithm to want the user when it's approaching the speed limit? We obviously wouldn't built it that way, but the app could just tell the location service to wake it up if a significant change in position occurs (much like the iOS location service works). With that signal available, the app can do whatever it wants with that information. One thing that strikes me: Instead of trying to solve the problem a lot of won't work statements are made in this thread, going along with a request for removing all of the lifecycle policies. And to be clear: With strict policies in place, it is always possible to find an example that breaks. So I think we can stop collecting breaking examples here. I think that if we go down the path of allowing folks to write background services, then we may as well just allow the app to run in the background. Yes and no. As I wrote before in this thread, in some cases it's possible to detect when an application will need to run or can be killed. We don't have to allow all applications to run in the background. But why not let a navigation application declare in its manifest file that it wants to be left running if it's defocused while the GPS is on? Because that is an open invite to any app developer to leverage that way out, too. We do not do install time application permission verification by the user for a good reason. As for GPU resources, Qt can release all of them when the window is not exposed, if told to. Hmmm, people said that about cooperative multi-tasking, too: Sure, the app will happily give up its timeslice (tm). Thomas Ciao, Alberto -- 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 -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/22/2013 09:30 AM, Jamie Strandboge 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@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? Hmmm, here is one more example: * watching a video in the webbrowser (LP: #1244373) I'm not sure how this can be fixed without adding policy for it to inhibit the screen blanking unless the webbrowser-app uses the media service to play embedded content. [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/ signature.asc Description: OpenPGP digital signature -- Mailing
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... Cheers, Rick -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/24/2013 02:00 PM, Rick Spencer wrote: It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... I think that is where we landed: https://lists.launchpad.net/ubuntu-phone/msg04766.html Ie, we build out our services but application developers also have a way to implement their own background service if they need to. I added the webbrowser-app example because it was a use case not covered previously and seemed different (I'm happy to be corrected). -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge ja...@canonical.comwrote: On 10/24/2013 02:00 PM, Rick Spencer wrote: It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... I think that is where we landed: https://lists.launchpad.net/ubuntu-phone/msg04766.html Ie, we build out our services but application developers also have a way to implement their own background service if they need to. So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I think that if we go down the path of allowing folks to write background services, then we may as well just allow the app to run in the background. For completeness, I would expect a different policy to be in force when running on a desktop. I could imagine that in desktop mode the policy allows applications to run in the background. However,that is a discussion for later ;) Cheers, Rick -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Having only a set of default services would be very limiting. Even if a music background service could take streams to support metronome-like apps, how about Spotify or Grooveshark? They both have a lot of security built in and you can't just take a stream and start playing, you have to talk with their servers, make sure you download the streams in correct speed (too fast and they will think your downloading their music, too slow and the listener will be sad) and have a lot of stuff setup just for them to trust you. And what about smart alarm clocks that’s monitors your sleep cycle? Or my banks app that shows the amount of money on my account when I shake my phone? A set of good behaving default services would be very good, but it's far from enough and when trying to squeeze to much functionality in the same service just to try to cope with everything you would back fire your saving battery plan by having non optimal implementations. It's much better to try to help the developer instead of limiting him. Provide good default services than can be used when possible and provide good help in creating well behaving daemons when needed. Create an event based message handler for communicating between the frontend and the deamon, probably could use already available functionality in QT however I haven’t used it enough to tell. Make it possible to subscribe to events from the system (incoming call/message, precise time, rough time, location). Create something like Google Cloud Messaging for developers to push notifications to devices. Everything that can ease in creating good behaving apps for the developers. If you instead limits them to a set of fixed services, those will be misused to do stuff in non optimal ways. Just look at X at these days. 2013/10/24 Rick Spencer rick.spen...@canonical.com On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge ja...@canonical.comwrote: On 10/24/2013 02:00 PM, Rick Spencer wrote: It's been interesting to read all the expected use cases, and also the requirements for application developers. It's good to think hard about how we fulfill these requirements, and do it well. What I liked about Thomas's first iteration of the application life cycle, is that it is clean, simple, comprehensible, and works. To me, it seems that as an app developer you get: 1. the ability to do what you want when your app is in front and the phone is not idle. 2. a set of services via well known APIs to call for things where your app may not be in front (i.e. music service, download service, alarm service etc...) I think that instead of thinking of ways to grant applications long running processes, we should grow these services. For example, it sounds like a location service may be required, etc... I think that is where we landed: https://lists.launchpad.net/ubuntu-phone/msg04766.html Ie, we build out our services but application developers also have a way to implement their own background service if they need to. So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I think that if we go down the path of allowing folks to write background services, then we may as well just allow the app to run in the background. For completeness, I would expect a different policy to be in force when running on a desktop. I could imagine that in desktop mode the policy allows applications to run in the background. However,that is a discussion for later ;) Cheers, Rick -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Thu, Oct 24, 2013 at 6:28 PM, Rasmus Eneman ras...@eneman.eu wrote: Having only a set of default services would be very limiting. Even if a music background service could take streams to support metronome-like apps, how about Spotify or Grooveshark? They both have a lot of security built in and you can't just take a stream and start playing, you have to talk with their servers, make sure you download the streams in correct speed (too fast and they will think your downloading their music, too slow and the listener will be sad) and have a lot of stuff setup just for them to trust you. Download service? And what about smart alarm clocks that’s monitors your sleep cycle? Microphone service? Or my banks app that shows the amount of money on my account when I shake my phone? Not certain why this would ever happen in the background, but there should be a sensor service, right? I understand what you are saying, but I still don't think we should give up so easily. Constraints are good, and lead to a lot of creativity and good design. I think we should stay confident in our initial design and not stray from the path until we are very certain that it won't work. Cheers, Rick -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Thu, 2013-10-24 at 15:36 -0400, Rick Spencer wrote: So I am saying the opposite. Rather than allowing apps to create background services I think we should stick to the original vision. Apps use well known APIs for their functionality, or the the user keeps the app in front and alive on the phone. I think there should be no background processes other than what is available on the base system. This system we have started down is clean, simple, and very hard to subvert. The hard part is providing the correct set of APIs so that app developers do not wish they could write such services. I think that this is a really great goal, and we should strive to have all of the user session services provide useful interfaces for app developers. For instance, I think it's becoming clear that the location service should probably handle things like GPS traces. I think that what we can do here is make running a background task a choice of last resort for developers. For instance, we could require every background process to have an application indicator, thus making it very visible to the user that something is running. Users would naturally not want to clutter up their panels with hundreds of icons, so apps with background services would need to be justified and likely rare. I also think that we should tease out the use-cases for things that are long running background services and those that are helpers to other tasks in the system. For instance, it might make sense for an app to have a small bit of code run on a push notification to determine how it should be visualized to the user (or ignored). These helpers have limited lifecycles and I think we should look at ways to manage them differently than background services. Perhaps the Grooveshark case could be a helper for the sound-service that would manage it's lifecycle more aggressively. Ted signature.asc Description: This is a digitally signed message part -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 8:45 PM, 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?
I think that there is room for improvement on top of the android model
(which I quite like).
The essence here is: If applications are split up in components
(whether you call them activities and services, or front- and
background services does not matter), it is way easier to come up with
a policy that both ensures good battery life _and_ allows for apps (or
components of them) to run in the background.
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).
AIDL is *another* middleware that helps in implementing an
out-of-process component model. That being said, we will need
something comparable. And before people start asking: I think we need
to help developers with a layer on top of raw dbus to make this as
convenient and easy as possible. We can probably hijack existing
object hierarchies, but might as well come up with something that is
less coupled to a specific object model.
One thing that has been spinning in my mind for some time is something like:
class MyBackgroundService : public ubuntu::Component
{
public:
// From ubuntu::Component
void on_new_message(const Message message) override;
const std::string name() const override { return
MyCoolBackgroundService; }
bool store_state_for_migration(const Archive archive) override;
};
ANNOUNCE_COMPONENT_WITH_NAME(MyBackgroundService, MyCoolBackgroundService);
auto my_ex_process_service =
ubuntu::component_castMyBackgroundService(ubuntu::Component::instantiate_out_of_process(MyBackgroundService));
if (auto)
{
// We have the service running in a separate process now.
// Invoke a function of the component
auto result =
ubuntu::Component::invokeMyBackgroundService::Sum(my_ex_process_service).with(42).and(42);
if (!result.is_error())
{
// Prints 84.
std::cout *result() std::endl;
}
}
Obviously, draft code so take it with a grain of salt. But we could
come up with something like this pretty rapidly.
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.
We can fine-tune resource constraints via cgroups and ensure that a
background service does not trash the system.
Unity8's application manager would be a great place to add this
functionality as it already takes care of suspend/resume and adjusting
oom_score's.
HTH,
Thomas
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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 4:30 PM, Jamie Strandboge ja...@canonical.com 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@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) +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 : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Wed, 2013-10-23 at 11:09 +0200, Thomas Voß wrote: On Tue, Oct 22, 2013 at 8:45 PM, Rasmus Eneman ras...@eneman.eu wrote: 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). AIDL is *another* middleware that helps in implementing an out-of-process component model. That being said, we will need something comparable. And before people start asking: I think we need to help developers with a layer on top of raw dbus to make this as convenient and easy as possible. We can probably hijack existing object hierarchies, but might as well come up with something that is less coupled to a specific object model. I realize that this isn't exactly what you're saying, but I don't think we want to necessarily use DBus here, at least on a well known bus (session). We've restricted the use of well known names (which is good IMHO) but that makes finding your background service slightly difficult. It seems like what ever protocol goes across it, doing something that only relies on flies in the application's cache directory I think would be more robust. I think that we also need to ensure that what ever defines the background service doesn't imply that protocol. For instance a background service that just writes to an SQLite DB seems valid to me. Ted signature.asc Description: This is a digitally signed message part -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/23/2013 04:09 AM, Thomas Voß wrote:
class MyBackgroundService : public ubuntu::Component
{
public:
// From ubuntu::Component
void on_new_message(const Message message) override;
const std::string name() const override { return
MyCoolBackgroundService; }
bool store_state_for_migration(const Archive archive) override;
};
This is the type thing I'm needing to make it eaier to port an
application I wrote for Android[1]. It would also be really nice if we
provided some helper code for scheduling sync/alarm type services. ie -
call this method in about 20 minutes. If you do that, then our base
code group calls together to help keep the device idling as long as
possible.
1: https://github.com/dwalkes/WakeMeSki
--
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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 23.10.2013 16:42, Andy Doan wrote: This is the type thing I'm needing to make it eaier to port an application I wrote for Android[1]. It would also be really nice if we provided some helper code for scheduling sync/alarm type services. ie - call this method in about 20 minutes. If you do that, then our base code group calls together to help keep the device idling as long as possible. I think a better solution for that kind of feature would be push notifications, although this is still (as is the full lifecycle) in the works. 20 mins is a long time if you're about to miss the best snow ever ;D -- Michał (Saviq) Sawicz michal.saw...@canonical.com Canonical Services Ltd. -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/23/2013 08:27 AM, Ted Gould wrote: On Wed, 2013-10-23 at 11:09 +0200, Thomas Voß wrote: On Tue, Oct 22, 2013 at 8:45 PM, Rasmus Eneman ras...@eneman.eu mailto:ras...@eneman.eu wrote: 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). AIDL is *another* middleware that helps in implementing an out-of-process component model. That being said, we will need something comparable. And before people start asking: I think we need to help developers with a layer on top of raw dbus to make this as convenient and easy as possible. We can probably hijack existing object hierarchies, but might as well come up with something that is less coupled to a specific object model. I realize that this isn't exactly what you're saying, but I don't think we want to necessarily use DBus here, at least on a well known bus (session). We've restricted the use of well known names (which is good IMHO) but that makes finding your background service slightly difficult. It seems like what ever protocol goes across it, doing something that only relies on flies in the application's cache directory I think would be more robust. I think that we also need to ensure that what ever defines the background service doesn't imply that protocol. For instance a background service that just writes to an SQLite DB seems valid to me. DBus is going to be problematic from an application confinement point of view unless we can someone restrict the bind, path, interface, etc to application specific values. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan
alberto.marde...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2013 01:46 AM, Jamie Strandboge wrote:
I think we may be too strict on this. Consider the following apps:
* a metronome app for musicians to practice to (2 are in the app
store now) * a white noise app to help people sleep (1 in the
store) * 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) * internet radio apps (there are at least 2 in the
store) * a 3rd party alarm clock (perhaps the API that the core app
clock uses is sufficient-- I haven't checked)
[...]
Do we have a plan for apps like this? If not, could we create an
API that allows inhibiting reasonably? Note, there was a related
thread ('Catching CPU run-aways on Touch') that might be useful to
take a look at if we are going to implement this.
The case of an application using the GPS is interesting. The nice
thing here is that the system can know that the GPS is on and that the
application is listening to it, so it could let the application run
even when in the background, without the need for a specific policy flag.
Conversely, if the GPS is off, there's generally no point in letting a
GPS application to continue running, and it could be stopped.
Along the same lines of the metronom app: If the gps app is in
foreground, the location service should signal to powerd that it
should not suspend at least the gps, probably the network, CPU (and
thus, memory access).
And maybe we could have something similar for music apps? While there
are many applications which could emit sounds, some need to continue
playing while in the background (music player, metronome, etc.), while
some don't (videogame).
So, we could have a specific policy for apps who declare to be music
players (or more generically, whose main task is to produce a sound),
which makes it so that the app will not be stopped if it is currently
playing (there should be ways to detect this as well). And again,
conversely, such an app could be stopped if it gets in the background
when it's not playing music.
I think we should avoid splitting policy and instead say:
* If an application is using audio HW directly, make sure that the
specific system components are not suspended.
* If an application wants to play music in the background, it can
dispatch to the music-hub.
Please note that whenever we enable app developers to define own
background services, the solution with the system being clever about
who uses certain resources of the system (gps hw, audio hw) just works
(tm) while the lifecycle policy can still be agressive and strict
w.r.t. application components providing UI components.
HTH,
Thomas
(where I used the expression in the background you can extend it
with or the display gets turned off)
I think this would be much easier than using the music hub: both for
the developer, which doesn't have to change its code just for Ubuntu
Touch, and probably for us as well.
Ciao,
Alberto
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJmFfsACgkQVLQegMXeCFLs5ACdEgO5u5ihdMiMgGip9eoNQQof
DeQAnjKmQAtWbo2uLK7PFVTKGNDhRFRe
=fxep
-END PGP SIGNATURE-
--
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
--
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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Mon, Oct 21, 2013 at 11:53 PM, Thomas Voß thomas.v...@canonical.com wrote: Trying to distill the use-case/issue we want to solve here: Applications running in the foreground, that is, of immediate interest to the user should be able to prevent the system from going into sleep/deep sleep. Yes, including when the screen is locked, there are still legitimate reasons for applications to be running in the foreground -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/22/2013 09:59 AM, Thomas Voß wrote: Along the same lines of the metronom app: If the gps app is in foreground, the location service should signal to powerd that it should not suspend at least the gps, probably the network, CPU (and thus, memory access). Why does it matter if the app is in the foreground or background? A navigation app needs to continue runnint anyway, even if it's in the background. Shouldn't the location service also signal to the shell (or to whatever component is responsible for apps lifetime) that the app is using the GPS and shouldn't be stopped? (if not: how would you solve this use case?) Ciao, Alberto -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Some thoughts: There definitely are legitimate reasons to let apps run in the background. A game on Android I like very much is Turf, it uses the GPS to track you when you goes around and take zones. While playing, I usually listens to music. And bam, a common use case where we want two apps in the background (maybe I gets a SMS and don't change back to one of the apps I'm using). So app definitely needs a way to run in the background and prevent sleep. I think Android solves this very good using Activity’s and Services. An activity is what shows the graphical interface, everything you see is an activity. Activitys can't run in the background. Services however can't show any graphical interface but can tun in the background. This is good as it forces developers to write good behaving background services (in the meaning of, it doesn't do any graphical stuff when not in the foreground). To this Android also have a battery menu in the system settings that show how much battery every app have been using, which makes it easy to find out which app drained my battery. There are other use cases than GPS and music, apps that download stuff for example (http, torrent, or whatever), apps that measures the accelerometer and finds out when I'm sleeping very light. Personally I don't think a crippled way of running background tasks is the best way to fix battery issues, instead let the user choose and help him do it by displaying as much information ass possible. Maybe there could be a setting in the battery menu let apps run in the background that would make it possible for people to save as much battery as possible if they want. A default setting could be to disable this when the battery reaches 15% or something. 2013/10/22 Alberto Mardegan alberto.marde...@canonical.com On 10/22/2013 09:59 AM, Thomas Voß wrote: Along the same lines of the metronom app: If the gps app is in foreground, the location service should signal to powerd that it should not suspend at least the gps, probably the network, CPU (and thus, memory access). Why does it matter if the app is in the foreground or background? A navigation app needs to continue runnint anyway, even if it's in the background. Shouldn't the location service also signal to the shell (or to whatever component is responsible for apps lifetime) that the app is using the GPS and shouldn't be stopped? (if not: how would you solve this use case?) Ciao, Alberto -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
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? cheers, John -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
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. Thanks, Thomas cheers, John -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 11:45 AM, Rasmus Eneman ras...@eneman.eu wrote: Some thoughts: There definitely are legitimate reasons to let apps run in the background. A game on Android I like very much is Turf, it uses the GPS to track you when you goes around and take zones. While playing, I usually listens to music. And bam, a common use case where we want two apps in the background (maybe I gets a SMS and don't change back to one of the apps I'm using). So app definitely needs a way to run in the background and prevent sleep. I think Android solves this very good using Activity’s and Services. An activity is what shows the graphical interface, everything you see is an activity. Activitys can't run in the background. Services however can't show any graphical interface but can tun in the background. This is good as it forces developers to write good behaving background services (in the meaning of, it doesn't do any graphical stuff when not in the foreground). Yup, we are proposing a very similar approach that dispatches tasks to services that are allowed to run in background (potentially with CPU time and/or memory being restricted). To this Android also have a battery menu in the system settings that show how much battery every app have been using, which makes it easy to find out which app drained my battery. 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. There are other use cases than GPS and music, apps that download stuff for example (http, torrent, or whatever), apps that measures the accelerometer and finds out when I'm sleeping very light. Personally I don't think a crippled way of running background tasks is the best way to fix battery issues, instead let the user choose and help him do it by displaying as much information ass possible. 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). Thanks, Thomas Maybe there could be a setting in the battery menu let apps run in the background that would make it possible for people to save as much battery as possible if they want. A default setting could be to disable this when the battery reaches 15% or something. 2013/10/22 Alberto Mardegan alberto.marde...@canonical.com On 10/22/2013 09:59 AM, Thomas Voß wrote: Along the same lines of the metronom app: If the gps app is in foreground, the location service should signal to powerd that it should not suspend at least the gps, probably the network, CPU (and thus, memory access). Why does it matter if the app is in the foreground or background? A navigation app needs to continue runnint anyway, even if it's in the background. Shouldn't the location service also signal to the shell (or to whatever component is responsible for apps lifetime) that the app is using the GPS and shouldn't be stopped? (if not: how would you solve this use case?) Ciao, Alberto -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Hi, 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. 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. I do agree that for some use cases such a service is a good idea. But having the metronome app to ship a service? Really? Br, Michael On Tuesday 22 October 2013 11:33:54 John Lea 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? cheers, John -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Monday 21 October 2013 17:46:06 Jamie Strandboge wrote: Recently someone asked me about adding an apparmor policy group for qtpowerd so that apps could stop application lifecycle from suspending the app. I said to file a bug and I'd look at it because I was thinking this seemed reasonable for a number of reasons (which I'll list below). We were told that apps should not generally have this permission. This particular case was a 3rd party music player and in this case it was easy enough to punt and say that 3rd party music players should use the upcoming media service. However... I think we may be too strict on this. Consider the following apps: * a metronome app for musicians to practice to (2 are in the app store now) * a white noise app to help people sleep (1 in the store) * 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) * internet radio apps (there are at least 2 in the store) * a 3rd party alarm clock (perhaps the API that the core app clock uses is sufficient-- I haven't checked) * I'm going to release Xbmcremote (http://notyetthere.org/?page_id=17) later this week. It is affected too by this. The feature to pause the running movie or lower the music's volume on incoming phone calls is disabled for Ubuntu. -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 1:17 PM, Michael Zanetti michael.zane...@canonical.com wrote: Hi, 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. I think that the benefits of aggressively freeing up GPU resources for the user-facing process is the more valueable feature we gain here. On top: Obviously, app devs have to be supported by our SDK/middleware to be able to migrate certain functionality ex-process. 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. Well, we certainly won't allow a background process to go crazy and will limit resources available to it. On top, they will live in the same process group as the parent process and we could control their lifetime, too. For not visible to users: Unity8 and, with that the user, an app consists of all of its processes. Thomas I do agree that for some use cases such a service is a good idea. But having the metronome app to ship a service? Really? Br, Michael On Tuesday 22 October 2013 11:33:54 John Lea 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? cheers, John -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan alberto.marde...@canonical.com wrote: The case of an application using the GPS is interesting. The nice thing here is that the system can know that the GPS is on and that the application is listening to it, so it could let the application run even when in the background, without the need for a specific policy flag. Conversely, if the GPS is off, there's generally no point in letting a GPS application to continue running, and it could be stopped. It is worth nothing that application that is listening to GPS in 'foreground' doesn't mean the app should keep working/the phone awake. For example, an app that attaches GPS location to a post, while we're on the edit screen, need not keep the device (or, GPS, for that matter) on. The system could safely go to sleep, instead draining power if the user left the app on the edit post page. On the flip side, as it has been already noted, there's a number of apps that require GPS on, even when they move to background. I personally find Android APIs convenient in that respect. It is the responsibility of the developer to consume as little power as possible, otherwise the app would get bad reviews. While I find the idea of containing the resource resolution as a platform responsibility interesting, if we go that route, I think we'll overcomplicate the solution to the problem. As far as UI/daemon split is concerned, that makes perfect sense (incidentally, just like on Android). Whether the metronome should ship with a deamon - perhaps that's too much, but why not? We should recognize the fact that it is complicated to communicate with background services as area for improvement on our end. Cheers, karni -- Software Engineer Professional and Engineering Services Canonical Ltd. Ubuntu - Linux for human beings | 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
Modern OS requires silent background processes, of course. Listening music, checking email, tracking position and so on - all of it requires services (daemons). And why do you afraid to write qt based C++ class for service? I think that we must be pragmatic - QML is only gui declarative language, not complete framework for new OS. Sdk should provide some low level primitives for those developers, who wants to create more complex apps (not only notes and site explorers). Otherwise Ubuntu Phone will fail. Even with such community. 22.10.13 16:27 Michal Karnicki написал(а): On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan alberto.marde...@canonical.com wrote: The case of an application using the GPS is interesting. The nice thing here is that the system can know that the GPS is on and that the application is listening to it, so it could let the application run even when in the background, without the need for a specific policy flag. Conversely, if the GPS is off, there's generally no point in letting a GPS application to continue running, and it could be stopped. It is worth nothing that application that is listening to GPS in 'foreground' doesn't mean the app should keep working/the phone awake. For example, an app that attaches GPS location to a post, while we're on the edit screen, need not keep the device (or, GPS, for that matter) on. The system could safely go to sleep, instead draining power if the user left the app on the edit post page. On the flip side, as it has been already noted, there's a number of apps that require GPS on, even when they move to background. I personally find Android APIs convenient in that respect. It is the responsibility of the developer to consume as little power as possible, otherwise the app would get bad reviews. While I find the idea of containing the resource resolution as a platform responsibility interesting, if we go that route, I think we'll overcomplicate the solution to the problem. As far as UI/daemon split is concerned, that makes perfect sense (incidentally, just like on Android). Whether the metronome should ship with a deamon - perhaps that's too much, but why not? We should recognize the fact that it is complicated to communicate with background services as area for improvement on our end. Cheers, karni -- Software Engineer Professional and Engineering Services Canonical Ltd. Ubuntu - Linux for human beings | 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
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/ signature.asc Description: OpenPGP digital signature -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Mon, Oct 21, 2013 at 3:46 PM, Jamie Strandboge ja...@canonical.com wrote: I think we may be too strict on this. Consider the following apps: * a metronome app for musicians to practice to (2 are in the app store now) * a white noise app to help people sleep (1 in the store) * 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) * internet radio apps (there are at least 2 in the store) * a 3rd party alarm clock (perhaps the API that the core app clock uses is sufficient-- I haven't checked) * An app that records GPS data even while the screen is locked, eg so runners/cyclists/etc can track their route/performance/etc. -- 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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On Mon, Oct 21, 2013 at 7:46 PM, Jamie Strandboge ja...@canonical.comwrote:
Recently someone asked me about adding an apparmor policy group for
qtpowerd so
that apps could stop application lifecycle from suspending the app. I said
to
file a bug and I'd look at it because I was thinking this seemed
reasonable for
a number of reasons (which I'll list below). We were told that apps should
not
generally have this permission. This particular case was a 3rd party music
player and in this case it was easy enough to punt and say that 3rd party
music
players should use the upcoming media service. However...
qtpowerd prevents the device from suspending, but there's another hack in
the lifecycle code that prevents the app from suspending; these for v1 at
least are considered hacks.
AFAIK, once the music app uses the music hub these hacks should go away
(from music and mediaplayer).
I think we may be too strict on this. Consider the following apps:
* a metronome app for musicians to practice to (2 are in the app store
now)
* a white noise app to help people sleep (1 in the store)
* 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)
* internet radio apps (there are at least 2 in the store)
* a 3rd party alarm clock (perhaps the API that the core app clock uses is
sufficient-- I haven't checked)
AIUI, all of these apps either do or would suffer from the same
limitation: they
could all be suspended when the screen blanks which severely limits their
utility. I tried to use one of the metronomes and also the white noise
app, but
our current application lifecycle power management suspends them after 30
seconds. I didn't even bother with the second metronome because I figured
it
would suffer the same fate (a shame if our users think the same thing).
Note, in
many of these cases, the app is still the foreground app (metronome, white
noise, navigation). I guess a workaround for the user is to call
powerd-cli in
the terminal app-- that is certainly not what we want normal users to do.
Using power-cli would stop the device from suspending, but not the app.
Currently, we are not allowing developers to inhibit power management of
the app
or we allow it for certain apps if they run unconfined, like the
music-app. I
defaulting to suspending the app is a great default and it makes sense for
us to
continue to build out our APIs and services (eg, the media service) to
accomodate various use cases, but I also think that we should allow for
developers to opt into inhibiting app suspend at the very least for apps
that
are in the foreground because we aren't going to be able to predict all
the use
cases developers will need. We can implement this as an apparmor policy and
expose it to QML apps in some manner (heck, it could even have trust-store
integration with a prompt saying that the app can inhibit, but personally I
think not even this is needed). We can then let user reviews handle apps
that
misbehave (This app sux-- whenever I use it, my battery drains after 37
minutes
when normally I get 37 hours of life!! 1 star).
Do we have a plan for apps like this? If not, could we create an API that
allows
inhibiting reasonably? Note, there was a related thread ('Catching CPU
run-aways
on Touch') that might be useful to take a look at if we are going to
implement this.
For the music/sound stuff I thought apps were supposed to delegate that to
the music-hub[1].
Cheers
Sergio
[1] https://blueprints.launchpad.net/music-hub/+spec/music-hub
--
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
--
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
Re: [Ubuntu-phone] Thoughts on inhibiting app suspend via application lifecycle
On 10/21/2013 06:05 PM, Sergio Schvezov wrote:
On Mon, Oct 21, 2013 at 7:46 PM, Jamie Strandboge ja...@canonical.com
I think we may be too strict on this. Consider the following apps:
* a metronome app for musicians to practice to (2 are in the app store
now)
* a white noise app to help people sleep (1 in the store)
* 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)
* internet radio apps (there are at least 2 in the store)
* a 3rd party alarm clock (perhaps the API that the core app clock uses
is
sufficient-- I haven't checked)
...
Do we have a plan for apps like this? If not, could we create an API that
allows
inhibiting reasonably? Note, there was a related thread ('Catching CPU
run-aways
on Touch') that might be useful to take a look at if we are going to
implement this.
For the music/sound stuff I thought apps were supposed to delegate that to the
music-hub[1].
Maybe? I guess it depends on if the music-hub can handle streams rather than
just files. Eg, the metronome isn't going to ship different ogg files for
different tempos; it is going to create streams on the fly. The internet radio
would be a stream too. The white noise app does ship sounds files, but it has a
neat feature of being able to play more than one at a time. There is still
navigation with sound, alarms and gps without sound, like Robert mentioned. My
point is, yes, let's do the media service, absolutely, but maybe we should also
allow for other scenarios.
--
Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
--
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
