On Fri, Oct 2, 2015 at 12:10 PM, Matthew Paul Thomas <m...@canonical.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alan Bell wrote on 01/10/15 12:25: >> >> I quite agree, even if it is a user preference it would be fine, > > Making background processing a user preference would be the worst > possible approach. It would mean sometimes having to choose between > battery life and an app that works. It would mean users experiencing > different things, from the same app on different devices, and not > understanding why, never realizing that it was because they twiddled > the setting a year ago to see what it did and then forgot about it. It > would mean app developers often not experiencing their own apps the > same way that most of their users were. It would mean silly nag > screens in some apps prompting you to change your multitasking > setting. And for a combination of those reasons, it would require > people to learn what "background processing" is, and make a decision > about it, when most of them have far, far better things to do with > their lives. > >> I would choose to have multitasking when the screen is on. I find >> it rather frustrating on slow connections to be unable to >> background the web browser to let it load something while I check >> on other things. >> >> ... > > Notice how Safari on an iPhone doesn't have the same problem, despite > not multitasking. Half-load a page, switch to another app, switch back > a while later, and the whole page will usually be loaded. (Except > maybe bits that were to be loaded by scripts that were frozen.) > > So, multitasking is not the only solution to that problem. > > A better solution, perhaps, would be to expand the Download Manager > service. > <https://developer.ubuntu.com/api/apps/qml/sdk-15.04/Ubuntu.DownloadManager.index/> > > First, make it accept more than just an URL. You can encode HTTP > authentication into an URL, but you can't provide cookies, client > certificates, a POST form payload, or even an HTTP Referer. > > Second, instead of making it an opt-in API for apps to use for "a long > running connection", just make it automatic for every transfer. > There's little point in halting a transfer because an app is going > into the background; the app will usually just restart it again later, > using more battery (and more data) in the long run. > > If those two things were done, the Web browser could use it for almost > everything. So as long as the HTML of a page had been loaded, with the > other resources requested, the rest of the page would load in the > background.
While that might sound like a solution to the problem on the paper, it won’t fly, for several reasons: - afaik this is not part of the design goals of udm, so it might require quite some refactoring (or even a complete rewrite) to catter for this new use case - oxide (and chromium under its hood) has a highly optimized engine to perform HTTP requests, tailored especially for the browser use-case, that can handle a number of concurrent requests. It would be naive to think we can replicate that in udm without a significant effort and finite resources, if at all possible - that engine is not meant to be easily replaced in chromium, trying to do so would result in a significant amount of work (again, if at all possible), and an increased maintenance cost That doesn’t mean we shouldn’t try and think of clever solutions to this problem. Ensuring that a page is fully loaded before the corresponding process is suspended, to avoid CPU and data consumption later on when the browser regains focus, is desirable. -- 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
