3 ms·

Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. On mobile it doesn't happen, and we can thank And

Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. When Apple added multi-tasking to iOS later they copied the Android design more or less exactly. Browsers do something similar for browser tabs now. However this was never brought to the desktop, largely because native desktop APIs are dead and none of the companies that fund them are interested in improving them. We get the web and if it sucks, well too bad.

TeMPOraL 5y ago
> Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference. > On mobile it doesn't happen, and we can thank Android for that To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting. I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).
- horsawlarway 5y ago
  I agree with you about this distinction being important, but I come at it from a different angle - I don't mind if most apps operate in the background as they need, with preemptive scheduling like Android. But I really, Really mind if I don't have a rock solid way to quickly and easily kill an app (and all related tasks/processes/async jobs/etc). 1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location 2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'. I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".
- thu2111 5y ago
  On mobile there are ways to force quit apps. They just aren't front and centre, nor mandatory for users to understand, like it is on the desktop. Too many apps abusing resources and affecting UI speed is a separate issue, and mobile OS's developed a lot of techniques and technologies to allow apps to work in the background without bothering the user, and without overloading the device's resources. It's a nice set of systems, really, and I would be happy if desktops worked the same way. Nobody would be taking force quit away from me, even if such a system were to be implemented.
selfhoster11 5y ago
> On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. Yes, and this turns my phone into an amnesiac the moment I have a hundred tabs and fifteen apps open. Switch to a different app, switch back... Oops, all gone! Enjoy recreating the state from history manually, if that's even possible. There are no words to express how unhappy this makes me. We've got gigabytes of memory on our handhelds these days, why can't the phone just deal with it?

TeMPOraL 5y ago

> Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference. > On mobile it doesn't happen, and we can thank Android for that To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting. I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).

horsawlarway 5y ago
I agree with you about this distinction being important, but I come at it from a different angle - I don't mind if most apps operate in the background as they need, with preemptive scheduling like Android. But I really, Really mind if I don't have a rock solid way to quickly and easily kill an app (and all related tasks/processes/async jobs/etc). 1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location 2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'. I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".
thu2111 5y ago
On mobile there are ways to force quit apps. They just aren't front and centre, nor mandatory for users to understand, like it is on the desktop. Too many apps abusing resources and affecting UI speed is a separate issue, and mobile OS's developed a lot of techniques and technologies to allow apps to work in the background without bothering the user, and without overloading the device's resources. It's a nice set of systems, really, and I would be happy if desktops worked the same way. Nobody would be taking force quit away from me, even if such a system were to be implemented.

selfhoster11 5y ago

> On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. Yes, and this turns my phone into an amnesiac the moment I have a hundred tabs and fifteen apps open. Switch to a different app, switch back... Oops, all gone! Enjoy recreating the state from history manually, if that's even possible. There are no words to express how unhappy this makes me. We've got gigabytes of memory on our handhelds these days, why can't the phone just deal with it?