| |||||||||||||
2011: The Year of Linux Disappointments (Datamation)2011: The Year of Linux Disappointments (Datamation)Posted Dec 16, 2011 5:08 UTC (Fri) by yoush (subscriber, #38940)In reply to: 2011: The Year of Linux Disappointments (Datamation) by mjg59 Parent article: 2011: The Year of Linux Disappointments (Datamation)
It does not matter that will be "then" if condition of your "if" is false.
The current situation is - quite a few applications don't save-restore everything, without any real improvement expected. Saving-restoring state of every element in every dialog is simply too cumbersome, joe developer will never do that.
And the result is - data loss, or generally things-not-done. I don't see this is anyhow better than slowness-because-of-swapping.
On n900 I was able to e.g. open a web page while at home, find needed information, and be sure it will be on-screen when needed in a few taps regardless of if mobile network is available or sessions expired on the server from where page originates. Or - fill in contact details looking for notes in a plaintext file before typing each field.
With Android all that causes pain. Perhaps among thousands garbage apps on market, there are handful of those that don't loose data in particular cases. However, (1) need to dig through thousands to find good one, for which I don't have time, and (2) even that won't help because it's not possible to test all cases in advance, I simply don't know all possible cases.
Multitasking is not an eye candy. Quite a few real-life use cases require it. And all those are causing poor experience on Android-based device.
Most don't care just because they are not trying to use devices seriously.
(Log in to post comments)
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:18 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
so if the device doesn't have enough memory to run both apps at the same time, what would you want to happen?
would you want it to refuse to run the new program?
what if there is enough space to start the new program, but then it needs more memory later? do you want the new program to be aborted?
the Android spec says that programs are supposed to checkpoint themselves, and if you are running on a device with enough ram to run all the programs, they don't need to.
but if you are running on a device without enough ram to run all the programs that you are trying to run, and the programs don't checkpoint themselves properly, you run in to problems.
and P.S. the same type of thing happens on apple devices, if you run more than can fit in ram, the OS silently kills some non-forground process, which then must start from scratch (with whatever checkpointed state it has) when you try to access it again.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:45 UTC (Fri) by yoush (subscriber, #38940) [Link]
> so if the device doesn't have enough memory to run both apps at the same
> time, what would you want to happen?
1. I don't believe that 512M is not enough to run address book and plain text editor at the same time - which is exactly the combination causing data loss on the device lying on this table.
2. They must swap. And swapping must be implemented in such way that important things such as incoming call handling are still fast. Sorry but implementing this *is* possible, it is not a rocket science. I'm involved in fast boot projects at Montavista PS, where we are doing much more complex things (such as 200 ms from poweron to userspace running) with the same base (the linux kernel).
> the Android spec says that programs are supposed to checkpoint themselves
Value of specs that are not followed is questionable
> the same type of thing happens on apple devices
That just means that apple devices are even worse.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
and when you fill swap? remember that storage if very small, slow, and wears out with frequent writes. not at all good for swapping.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 6:08 UTC (Fri) by yoush (subscriber, #38940) [Link]
Today storage is already not that small, and tomorrow it will be even larger.
And it supports up to 10^6 writes, which, combined with properly implemented wear-leveling, eliminates this problem.
As for being slow - it just means that algorithm that chooses what to swap out must be more careful and never swap out what is needed for important use cases.
As I've written elsewhere in the thread, it is ok to become slow when device is being used beyond it's capabilities. What is not ok is random data or context loose - and this is exactly what happens today on Android devices - even under far-from-stress conditions such as running address book and text editor.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 20:35 UTC (Fri) by jimparis (subscriber, #38647) [Link]
The swap works great on the n900, just like on a laptop. If you open too many apps, or they use too much memory, more and more swap gets used, and the system slows down. And then it's a tradeoff that you the user can manage: is what I'm doing important enough that I'm OK with things being slow for the moment, or should I close some of the apps that I don't really need right now? There's enough swap that the speed penalty gets bad and I deal with it manually long before the space actually runs out -- I have never had an app die due to memory pressure.
It's the main reason I switched away from my G1: when switching from a web browser to SSH and back, you could never be sure whether the web browser would stay put. Unfortunately, since Maemo/Meego/Tizen is clearly an evolutionary dead end and it's not worth fixing bugs anymore, I've recently switched back to Android with all its failings. Hopefully the 1G of RAM in my new phone will make the lack of predictable multitasking less of an issue.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:40 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
You could be sure of that if the OOM killer didn't strike, or if you didn't get so bored of waiting for contended memory to become available that you rebooted your phone. But if you want that behaviour to be deterministic in a multitasking environment then you either need to special-case some applications or you need to assert that applications must support checkpointing. You seem to be arguing that application developers can simply assume that their resources are unlimited and not worry about what happens when they run into those restrictions.
Does this result in a bunch of infuriating edge cases on Android? Yes, and it does on iOS as well. Not everyone handles this well. Applications that you want to be doing stuff in the background may end up thrown out. But, perhaps more importantly, you don't have to manually kill a bunch of programs before you can start another, and background applications don't get killed without the opportunity to save their state.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 6:00 UTC (Fri) by yoush (subscriber, #38940) [Link]
I see nothing bad in special-casing application that are "primary" for the device. Just the opposite - I think this is proper way. Especially if it will be up to user to decide what "primary" means.
We are on free software. We could tune OOM killer, swapper algorithms and whatever, to prevent "important" things from being killed or slowed down.
And yes - less priority things will become slow, maybe very slow, if attempting to use device beyond it's capabilities. That's ok as long as user gets indication of device is being used beyond it's capabilities, and has a way to recover *without* *data* *loss*.
In Android ecosystem, as it exists today, this problem is not solved. Too many apps don't follow specs enough to avoid data or context loss. For me, this is indication of entire approach failure in Real World conditions - although it probably looked ok on paper.
And - I can't agree that behaviour where my data and/or context is lost at random points is "deterministic", sorry. And - again - I don't believe that running address book and plain text editor at the same time is a stress for 1Gz processor and 512M of ram.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 11:24 UTC (Fri) by Fowl (subscriber, #65667) [Link] Well I run on a similarly spec'd device (HTC HD2) and have no trouble with multitasking, I commonly switch between the web browser, a train timeable app, foursquare, navigation, text messaging, twittter, facebook, and gmail. Perhaps by using such "common" apps I avoid the poorly written ones. The only application I have trouble with is the one for my bank, which seems to actively resist multitasking, I presume as some sort of "security" "feature". I use a very close to "as lobbed across the wall into git", ie. "stock" distro/rom called NexusHD2-Gingerbread. Some OEMs do overload their devices. Would you like to mention your device, "rom" and applications?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 18:37 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
"Well I run on a similarly spec'd device (HTC HD2) and have no trouble with multitasking,"
Perhaps you're just not picky enough with data loss in the sense of yoush's desire to have every piece of state saved (including gui widget contents).
This checkpoint/restore stuff is so PalmOS; it's surprising that a decade+ later, with 100x the hardware resources, it's still considered necessary/appropriate.
What have really changed? Posted Dec 16, 2011 19:23 UTC (Fri) by khim (subscriber, #9252) [Link] This checkpoint/restore stuff is so PalmOS; it's surprising that a decade+ later, with 100x the hardware resources, it's still considered necessary/appropriate. It's not surprising at all. Hardware may be 1000x more powerful (you mussed one order of magnitude), but system requirements grew 1000x, too. Think about it: Pilot 5000 had 512K of memory and 160x160x1bpp screen. Full system memory was large enough to keep contents of about 163 screens. "Latest and greatest" uber-powerful Galaxy Nexus has 1GB of memory and 1280*720*24bpp screen. Full system memory is large enough to keep about 388 screens. This means that, relatively speaking, hardware resources are about 2-3 times more powerful then they were back then. So... why exactly do you expect radically increased capabilities WRT multitasking? AFAIK N900 is extremely painful to use exactly because it tries to use "true multitasking" on the hardware which is just not powerful enough.
What have really changed? Posted Dec 16, 2011 19:43 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
"Full system memory [was 163 and now ] is large enough to keep about 388 screens."
That seems like a cherry-picked metric. Applications don't save state in such proportion to their window state.
Sure, it's not 100% fair comparison... Posted Dec 16, 2011 21:20 UTC (Fri) by khim (subscriber, #9252) [Link] That seems like a cherry-picked metric. Applications don't save state in such proportion to their window state. Sorry, but this exactly what they do. Of course it's not 100% apples-to-apples comparison, but it's pretty close to it. Where you see some savings you immediately see more "bloat" applied. For example where Palm used bitmap fonts while Android uses vector fonts so difference should be much smaller then 1000x, right? Nope: Palm used 8bit encoding with tiny number of glyphs while Android supports large subset of Unicode. Note that these fonts must be rasterized which needs memory for caching, etc. Amount of resources needed to produce 2D graphic correlates with the number pixels on your screen pretty damn well. Yes, there are different techniques involved which may push the balance one way or another but the raw amount of data on your screen is still very good starting point.
Sure, it's not 100% fair comparison... Posted Dec 16, 2011 21:43 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
I'm sorry, I don't see how the plus.google.com post substantiates that the *application context that needs to be saved/restored* during an app switch is somehow proportional to the graphics frame buffer size. Can you help me out a more sketched-out example?
Sorry, my bad... Posted Dec 17, 2011 9:21 UTC (Sat) by khim (subscriber, #9252) [Link] I've missed one logical step because I was sure your understand that your correct fact (applications don't save state in such proportion to their window state) damns your idea, not mine :) Sorry about that. Obviously applications don't save state in such proportion to their window state when they are doing checkpoint/restore stuff using application-specific code. Yet they do if they use generic code! Working set of typical application includes quite a few buffers which size is directly proportional to the size of screen. If you don't ask application to checkpoint/restore stuff using application-specific code then you need to save/restore these buffers, too. And since you can fit about about the same number of them in memory on PalmOS and on Android... the same principle applies.
Sorry, my bad... Posted Dec 17, 2011 10:55 UTC (Sat) by yoush (subscriber, #38940) [Link]
> If you don't ask application to checkpoint/restore stuff using
> application-specific code then you need to save/restore these buffers...
For last ~20 years, exposure events have been used to avoid framebuffer saving.
Sorry, my bad... Posted Dec 17, 2011 14:58 UTC (Sat) by pboddie (subscriber, #50784) [Link]
Indeed, framebuffer caching is an optimisation, not the first port of call for applications that don't feel like doing a redraw. Twenty years ago, it just wasn't possible to have all the applications caching their window contents in memory, although I do accept that caching rendered font bitmaps is very beneficial for performance even in memory-constrained systems: I remember increasing the font cache above the default 48K on my 1MB machine to get substantially faster text rendering.
PCs and phones are fundamentally different... Posted Dec 17, 2011 21:51 UTC (Sat) by khim (subscriber, #9252) [Link] Indeed, framebuffer caching is an optimisation, not the first port of call for applications that don't feel like doing a redraw. Sorry. But no. It was optimization on workstations with mouse. It's hard requirement on smartphone. Why? Touchscreen. Manipulations with touchscreen only feel "natural" if image on screen follows finger without jitter. For that you need to redraw image on screen in 16ms or less. The only way to do that in a lot of cases is to use shadow buffers. Especially if you don't know the exact specifications of the target phone platform and can not guarantee that you'll be able to draw everything in 16ms using just abstract representation of your application state. Now, you can flush all these buffers when your application goes to background and restore them when it returns - but that requires cooperation from application side and is awfully similar to that dreadful "checkpoint/restore stuff". Besides if application is going to background for a short time it may not be a good idea to throw all these buffers right away (battery life, you know), so in the end you'll come up with scheme quite similar to what iOS/Android are doing. You may say: but I don't want all that fancy touchscreen stuff! Give me good multitasking instead! Well, may be you don't need it, but handset makers surely do: fate of Blackberry/Symbian/etc says that most people do want that touchscreen stuff - and if you'll take in account this requirement then suddenly resources of modern phones are not "overwhelming" but "just barely enough"...
PCs and phones are fundamentally different... Posted Dec 18, 2011 1:24 UTC (Sun) by pboddie (subscriber, #50784) [Link] Sorry. But no. It was optimization on workstations with mouse. It's hard requirement on smartphone. In general it is an optimisation. Your applications all have to be able to render themselves, but a decision has been taken that they won't be asked to do so in various circumstances because they will appear too slow or won't look very nice. If you've filled up your memory with what are effectively screenshots because you've "started" 100 applications, you should expect some of them not to reappear instantly at 50 frames per second in some tiresome animation. Having them show up eventually is a lot better than having them show up immediately and then forgetting all their state.
PCs and phones are fundamentally different... Posted Dec 18, 2011 7:52 UTC (Sun) by yoush (subscriber, #38940) [Link]
I don't really understand why you people are talking about framebuffer content saving here. This is *not* what is happening in Android.
If application restores from [poorly-saved] "checkpoint", it definitely redraws from scratch. It can't be framebuffer restore, because last framebuffer state matched last application state, not the content of the poorly-saved checkpoint.
Have you tried looking on thread? Posted Dec 18, 2011 8:57 UTC (Sun) by khim (subscriber, #9252) [Link] I don't really understand why you people are talking about framebuffer content saving here. Have you tried to look on the context of the discussion? This is *not* what is happening in Android. Sure, but the question is: why this is not what is happening in Android. If application restores from [poorly-saved] "checkpoint", it definitely redraws from scratch. It can't be framebuffer restore, because last framebuffer state matched last application state, not the content of the poorly-saved checkpoint. Sure, but then running application state includes few shadow framebuffers which needs memory proportional to the size of raw data on your screen. And if you keep that in mind then suddenly your phone is not "orders of magnitude more powerful then old PalmOS devices" but "about 2-3 times more powerful then first PalmOS device". Most touchscreen shartphones today employ this technique not because their creators are stupid, but because it was the only way to create usable "magic tablet" using today's technology.
Have you tried looking on thread? Posted Dec 18, 2011 12:46 UTC (Sun) by fuhchee (subscriber, #40059) [Link]
"Sure, but then running application state includes few shadow framebuffers which needs memory proportional to the size of raw data on your screen."
Maybe the misunderstanding here is not differentiating between the memory requirements of running vs. stopped applications, and the associated state transitions.
It seems that if many apps (which ones?) use large pixmap caches during operation, *and* these are all retained in RAM while the apps are stopped, *then* perhaps overall RAM consumption can be said to be proportional to framebuffer sizes.
If many apps do not do not keep large pixmaps during run, or if they jettison them upon an application stop, then no.
Have you tried looking on thread? Posted Dec 18, 2011 14:45 UTC (Sun) by khim (subscriber, #9252) [Link] It seems that if many apps (which ones?) use large pixmap caches during operation Practically all applications do that. Even simple list of things need background pixmap or else you'll be unable to scroll it smoothly. *and* these are all retained in RAM while the apps are stopped Of course they are retained! What's the point of doing anything else? If you need to ask application restore them then you can as well ask application start from save point. If application developer can not handle save/restore events correctly then why do you think s/he'll be able to handle "drop shadow buffers"/"restore shadow buffers" events correctly? If many apps do not do not keep large pixmaps during run, or if they jettison them upon an application stop, then no. Sure. "No large pixmaps" is BlackBerry/Symbian model which provides abysmal touchscreen experience. And to rely on the voluntary cooperation between applications is just silly: both MacOS Classic and Windows 3.x did that and it was awful. At least with save/restore model badly written application can only make experience awful for user when s/he actively uses this application. "Let's all work together" model makes it impossible to understand what exact application makes your system unusable. All systems which tried that (Maemo, Symbian, Windows Mobile) were constant battlefield because of that.
Have you tried looking on thread? Posted Dec 19, 2011 12:36 UTC (Mon) by fuhchee (subscriber, #40059) [Link]
"Of course they are retained! What's the point of doing anything else? If you need to ask application restore them then you can as well ask application start from save point. ... If application developer can not handle save/restore events correctly then why do you think s/he'll be able to handle "drop shadow buffers"/"restore shadow buffers" events correctly?"
The apps must have the ability to recompute those pixmaps whenever, or they wouldn't have been drawn in the first place. Plus the pixmap state is not sufficient for application restore anyway, and would be in addition to whatever other state is saved/restored. The question is whether apps or the OS treat those pixmaps at a save/restore as a disposable cache, thus saving memory.
Recall that we were originally discussing whether ordinary unix concepts like multitasking, expose events, are really so inapplicable here. Stopped application state could be swapped by the OS instead of by the app. If pixmaps form such a core element of this platform, then specially handling them (disposing them also in the compositor/OS) seems workable. If not, I'd like to understand why.
Have you tried looking on thread? Posted Dec 19, 2011 12:45 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The main reason to want to special-case the pixmap storage is that you'd want to be able to redraw that while the application is still restoring state - an expose event isn't going to be processed until you've pulled in everything needed to regenerate the UI, and a second of black screen followed by a responsive app is likely to be more distracting than a second of UI that doesn't respond. However, there's absolutely no reason that that has to be kept in RAM - I've no idea how Android does it, but grubbing through the filesystem on an iOS device reveals a pile of snapshots of applications.
The reason to have checkpointing built into the applications rather than the OS is that the kernel has no real idea which bits of data can be reconstructed and which are user input. Swapping the entire application would probably be massively slower than just serialising a small subset and pulling that back in.
I think you are mixing issues... Posted Dec 19, 2011 14:51 UTC (Mon) by khim (subscriber, #9252) [Link] The apps must have the ability to recompute those pixmaps whenever, or they wouldn't have been drawn in the first place. Where this idea arrived from? Applications create shadow buffers for the express purpose of not doing recomputes later. Sure, OS and some toolkits may create cache buffers, too - but these are different. If mapping application converted vector map to pixmaps to make scrolling possible then the last thing it wants is to suddenly find out that OS decided to kill these pixmaps to save memory. If the whole application is killed and then restored then, of course, pixmaps will be recomputed, but otherwise they are kept in memory in the "ready to go" state... Plus the pixmap state is not sufficient for application restore anyway, and would be in addition to whatever other state is saved/restored. Sure. Pixmaps determine minimal size of application. Of course it may (and often does) contain other information in memory, too. But of course the applications for which pixmaps are just a noise in their memory consumption are even larger thus it makes even less sense to try to use "proper multitasking" with them. Recall that we were originally discussing whether ordinary unix concepts like multitasking, expose events, are really so inapplicable here. I always remember that, but it looks like you are forgetting sometimes. Ordinary unix approach is just to ignore expose events (window manager may change window borders, and application can usually ignore expose events completely). This is clearly inappropriate (as you yourself show) and everything else is just question of how much application should do to participate in checkpoint/restore dance.
This is, again, the case of "you don't exist"... Posted Dec 18, 2011 8:48 UTC (Sun) by khim (subscriber, #9252) [Link] If you've filled up your memory with what are effectively screenshots because you've "started" 100 applications, you should expect some of them not to reappear instantly at 50 frames per second in some tiresome animation. Nope. People don't understand this. Any OS which works like that will fail. Having them show up eventually is a lot better than having them show up immediately and then forgetting all their state. Well, it may be better for geeks like your and me, but it's much, much worse for Joe Average! People don't understand that application fill up the memory (heck, most need an explanation for what memory actually is first), if they understand then they forget all about it, etc. That's why set-top boxes with HDD remove (permanently remove at that!) old records, for example. People perceive smartphones not as electronic device, but as some kind of "magic tablet". They don't know and don't want to know how the whole thing works. That's why first iPhone was such a bomb: it was worse then most smartphones of the time (initially it had no support for apps!), but it was finally "magic tablet" which can be used without thinking about memory, tasks, etc. Sure, it had a lot of limitations (when you switched from one activity to another context was often lost, it had no copy-paste, etc), but it was finally usable by Joe Average, not just by eggheads!
This is, again, the case of "you don't exist"... Posted Dec 18, 2011 14:06 UTC (Sun) by pboddie (subscriber, #50784) [Link] Nope. People don't understand this. Any OS which works like that will fail. I know you can't resist contradicting everyone, but plenty of people who don't work in software development are perfectly capable of realising that they have, in their own words, "filled up" or "overloaded" their device. You can argue that they have had to develop such notions through experience with technology that did not attempt to hide its own limitations, but people are pretty quick to notice and adapt to the limitations of things they use. It is also good design for devices to communicate their limitations gracefully. (And before you respond with the patronising "you don't get it - you're an egghead" remarks or rhetorical questions about whether people should be forced to micromanage their device's resources, just bear in mind that I'm not advocating anything of the sort. Being able to disregard the mechanisms involved and to have a device juggle potentially excessive resource demands is a form of liberation for the user, but it becomes a form of frustration if the user demands more than the device can deliver without being warned about it in advance.) I don't really know why I'm having this discussion: I don't even have a smartphone, and the benefits of running multiple applications at a time on a phone would probably be marginal for me. But given that modern operating systems rely on multiple concurrently-running processes, I agree with the complainant that having the benefits already provided generally by the operating system (not something that can be said about those old Palm devices) stripped away in favour of an inferior solution providing fewer benefits specifically within a framework has led to a suboptimal experience for users and developers.
I beg to differ... Posted Dec 18, 2011 14:57 UTC (Sun) by khim (subscriber, #9252) [Link] But given that modern operating systems rely on multiple concurrently-running processes, I agree with the complainant that having the benefits already provided generally by the operating system (not something that can be said about those old Palm devices) stripped away in favour of an inferior solution providing fewer benefits specifically within a framework has led to a suboptimal experience for users and developers. Well, this was "obvious" for phone makers from the onset: BlackBerry, Symbian, Windows Phone - they all supported multitasking for more then a decade. But then someone decided to "strip these benefits" in the favor of "useless eyecandy". And people beat records repeatedly in a rush to buy these phones with "suboptimal experience for users and developers"... Don't you think that this is... kind of strage? "Suboptimal experience" leads to record sales, rave reviews in press, etc? IMO it just shows that people have different values and for most "true multitasking" is simply less valuable then "smooth hassle-less experience"...
I beg to differ... Posted Dec 19, 2011 22:08 UTC (Mon) by pboddie (subscriber, #50784) [Link]
You always beg to differ. However, even the original iPhone was a success for a few factors other than the eye candy, which it probably doesn't have that much of in comparison to the recent models. Take the serious treatment of Web browsing - a browser with a decent pedigree instead of the awful embedded browsers on most devices of the era - and the willingness to have both WLAN and GSM on the same device, plus the emphasis on Google services that I'm sure many people now wish to sweep under the carpet as if it never played a role in the success of that device.
Yes, sure. But how was Apple able to do that? Posted Dec 19, 2011 23:09 UTC (Mon) by khim (subscriber, #9252) [Link] Take the serious treatment of Web browsing - a browser with a decent pedigree instead of the awful embedded browsers on most devices of the era ...which Apple was able to offer because it knew browser can use all (or almost all) of the available memory since it'll be the only app running. and the willingness to have both WLAN and GSM on the same device Which was already old news at the time. iPaq 6315 in US and Nokia 9500 in the rest of the world offered the same capability three years earlier and in 2006 even midrange models like Samsung i730 and Nokia N80 had it. Sure, dual (GSM/WiFi) capability was important for iPhone but it was a means, not the goal. plus the emphasis on Google services that I'm sure many people now wish to sweep under the carpet as if it never played a role in the success of that device. Oh, sure, YouTube was pretty big attraction. But this just shows that you can not reach success by just blindly showing features in your phone. You need an attractive experience - and if you can not deliver it and multitasking at the same timeĀ then multitasking must go. You may reintroduce it later when platform will be more capable. Even so Apple was not quite ready to add full multitasking to iPhone 4: apparently it was still not powerful enough. They introduced checkpoint/restore system which is even more limited then Android's one. It's all about tradeoffs and if your system is not powerful enough to support both multitasking and smooth, pleasant, experience then most people will want pleasant experience.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 20:03 UTC (Fri) by yoush (subscriber, #38940) [Link]
> Would you like to mention your device, "rom" and applications?
SonyEricson sk17i
As for applications - I have several 10s installed. Especially bad in state saving is preinstalled browser, address book and mail client. As for others - Yandex maps (the most widely used russian maps app) looses state even if switching from it for a moment to read incoming SMS. Springpad looses dialog content even when turning from portrait to lanscape to type on hardware keyboard. There are many more but I don't remember right now.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 21:27 UTC (Fri) by khim (subscriber, #9252) [Link] Springpad looses dialog content even when turning from portrait to lanscape to type on hardware keyboard. If application loses state when you switch from portrait to landscape mode then it's definitely not a problem with Android task switching approach. Buggy applications can be created for any OS with any toolkit.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 22:07 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
actually, this is the same problem.
The android solution for the screen size changing is to have the application restart. This is a graceful restart as the application knows that it is happening and is given a chance to save it's state. The fact that it doesn't is a bug in the application, and reveals a place where the framework has sharp edges that make it easy for developers to mess up.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 10:52 UTC (Sat) by yoush (subscriber, #38940) [Link]
> and reveals a place where the framework has sharp edges that make it
> easy for developers to mess up
I'd rephrase that as - it's hard for developers not to mess up
2011: The Year of Linux Disappointments (Datamation) Posted Dec 18, 2011 1:57 UTC (Sun) by alankila (subscriber, #47141) [Link]
Yeah I agree, it seems like the views in the view tree do not have their states saved when activity is destroyed in between. Activities are not very often destroyed in normal usage conditions, but definitely when memory is low they will be. Maybe task killers would also very negatively impact usage experience.
Applications can relatively easily workaround the orientation change problem: they may use the 3.0+ fragments, which can be set to be retained across orientation changes, or they may use the configChanges manifest attribute to declare that they handle orientation changes of their own. Still, all this adds to lines of code that are not obviously necessary until you do end up with applications getting constantly killed.
It seems that ICS also has some developer options, such as "Don't keep activities", which destroys each activity as soon as user leaves it. It might help developers notice deficiencies in their state saving. Hopefully this problem gets better. At any event, radical changes to simplify developer experience are too often foiled because of backwards compatibility requirements.
|
|||||||||||||