On Thu, Mar 13, 2008 at 8:20 AM, Esben Damgaard <[EMAIL PROTECTED]> wrote: > But for some more hardcore stuff: You shouldn't have to close programs. > This is not good usability. Instead give the option, but if we run out > of ram, the OS should close the oldest program. But then a program > should be able to say to the OS that the program is meant to be running > for a long time.. Or maybe this is a bad idea..
I suggested that a long time ago: the important thing is not closing the current app, but getting back to the main menu. It should work more like PalmOS, because the user doesn't usually care in what state the current app is, he only cares which one he's going to run next. Interestingly, now that the iPhone SDK is out, I read that it runs only one app at a time! So no multitasking. (Hopefully they at least made it possible to play music in the background while you are doing other things. That must be an OS feature then, rather than just an application.) I bet the need for multitasking will come up, and either they will eventually have to retrofit some support for background processes or threads, or maybe they've already thought of that. So if we have a "main menu" touchscreen button, always visible, then either policy could be implemented: either it closes the current app, or leaves it running in the background and then potentially closes it later. That way there is room for successive refinement. But personally I think multitasking is sometimes useful, and anyway it can save time not to re-load some apps which are frequently used. The decision to close it could be based on CPU and I/O usage: if it's obviously doing something useful (but being nice about it), leave it running; but if it's hogging 100% CPU (or nearly) then prompt the user, whether to kill it. When there is memory pressure, the apps which are not doing anything would be the first ones to close in order to free some memory.
