I have to admit I haven't fact-checked this on my own but I have it on fairly good authority that several versions of Windows could swap themselves out, sometimes resulting in a bluescreen.
Windows has ALWAYS asked the user which processes to kill under memory stress, except in the most extreme of conditions (when it crashed). Android and iPhones thought they'd look cooler if they didn't, resulting in a decade of endless frustration for many users.
Note that I was talking about writing processes to swap, not killing them!
Why can't the app save its state to storage and restore the saved state when it's started again?
These phones go much farther the already absurd limitations of standard Android ("we know what apps a user doesn't care about so we'll kill them without asking, at any time"). Most developers are not aware of them, and in any case it's very hard to constantly save all the state Hardly any previous system in the history of computers has ever required it, and Android's developer documentation doesn't highlight enough h…
The expectation in mobile environments is that you store whatever information you need to resume from cold in response to the app leaving the foreground, since the OS may kill it with little further warning at any time thereafter. This recommendation occurs prominently in the lifecycle docs for both iOS and Android.
You're describing bad app implementation. It is quite common for the OS to suspend apps when they're in the background or when the device is under low memory/power conditions. The fact that you as a user are experiencing it in the form of degraded functionality is a bug with the app itself and should be addressed by the developer. As a reference, check iOS apps where the system monitors and controls each app's resour…
These phones kill apps, not suspend them.
From the app's point of view both are the same - the app can no longer execute code and upon resume it must restore state.
Windows has ALWAYS asked the user which processes to kill under memory stress, except in the most extreme of conditions (when it crashed). Android and iPhones thought they'd look cooler if they didn't, resulting in a decade of endless frustration for many users.
Note that I was talking about writing processes to swap, not killing them!
Yes indeed, I'm pretty sure that explorer.exe can or could get swapped out. I don't think that can result in a bdod though
I despise that this still happens today on a phone with 8GB of RAM. EIGHT GIGABYTES. That's what they sell the MacBook Pro with, but Android, built for low memory devices from the ground up, can't consistently keep a single application in memory in the background for just a few seconds. You can literally switch for five seconds and the last app has to reload. This drives me absolutely nuts.
What's worse is when the task switching app and/or the home screen app have to be restarted. My phone only has 4 GB ram, cause it's nearly 3 years old and low cost, but still... I feel like windows 95 could run (poorly) on 4 MB and the start button and the task bar never swapped out. (Well explorer.exe did crash from time to time)
The start button and the task bar are part of explorer.exe, although if I'm not mistaken the File Explorer windows have always been run in a separate instance of explorer.exe .
I'm pretty sure that the task bar and start button could get swapped out btw, but they're quick to reload (except for the start menu and the tray icons)
Why can't the app save its state to storage and restore the saved state when it's started again?
Because it costs resources the developers are unwilling or unable to spend. They might also be lacking competence. My local bus authority’s application is barely able to keep track of its state while it’s running . An other common situation is an applications getting in an irrecoverably broken running state. If the application preserves state on shutdown you might not be able to get it out of the broken state.
I think Android dev is unnecessarily designed in a way that makes saving data require a lot of code. If you know what you're doing, you can mmap a file, put all your working memory in there, and let the OS save it for you. No serialization or parsing necessary and memory access is exactly the same as usual with no overhead. You'd think that using a managed language would make it easier to abstract and support this kind of thing but seems they'd rather require all app devs do manual saving and reloading of their app data.
Because it costs resources the developers are unwilling or unable to spend. They might also be lacking competence. My local bus authority’s application is barely able to keep track of its state while it’s running . An other common situation is an applications getting in an irrecoverably broken running state. If the application preserves state on shutdown you might not be able to get it out of the broken state.
I think Android dev is unnecessarily designed in a way that makes saving data require a lot of code. If you know what you're doing, you can mmap a file, put all your working memory in there, and let the OS save it for you. No serialization or parsing necessary and memory access is exactly the same as usual with no overhead. You'd think that using a managed language would make it easier to abstract and support this ki…
These phones go much farther the already absurd limitations of standard Android ("we know what apps a user doesn't care about so we'll kill them without asking, at any time"). Most developers are not aware of them, and in any case it's very hard to constantly save all the state Hardly any previous system in the history of computers has ever required it, and Android's developer documentation doesn't highlight enough h…
Hardly undocumented! https://developer.android.com/guide/components/activities/pr... The expectation in mobile environments is that you store whatever information you need to resume from cold in response to the app leaving the foreground, since the OS may kill it with little further warning at any time thereafter. This recommendation occurs prominently in the lifecycle docs for both iOS and Android.
The vendors-specific behaviors reported in dontkillmyapp are undocumented