Users shouldn't have to launch and quit applications. They shouldn't have to save and open documents. State should just persist. Always.
If you pull the plug on your box you should be able to plug it back in and all state should be restored within seconds.
All applications should always be "running" and in the same state you last left them. You only need to switch focus between them as you perform your tasks.
Can modern OSes really not be made smart enough to manage our systems in this way? Why do users decide which applications get memory and CPU resources? Why do I need to manually start a bunch of applications and open documents after restarting my computer? None of this makes sense.
Hopefully iPhone OS can push us further down this path.
Abstracting away document save is also probably not a good idea unless there's automatic versioning (at least up to a few versions) built in.
Also 1-dimensional lists (like the coverflow of docs in iPad's iWork) don't scale well. These problems are dealt with more effectively by hierarchical folder systems of today's desktop OSes than by the iPhone OS. They're not as foolproof, but there's real benefit in exchange for the complexity.
I agree with you about application start/stop though. Also, IMO infinitely adjustable/overlappable windows in desktop OSes don't add much value either. A simpler windowing model (maybe a little like webOS's cards; the iPad's is too extreme) would probably be better.
Automatic versioning is also just "one of those things that software should do". Ideally with some logarithmically scaled set of versions when space becomes an issue.
Folders don't scale either. People quickly wind up just using search. Search works pretty darn well everywhere beyond the trivial case. Of course, for search to work really well, what the iPhone OS needs is an interface to let device-wide search tap into third party data stores.
Also, I think "piles" a la albums in the photo app is going to become a more generalized solution to the 'folder' issue.
It will fill the middle-ground where linear lists break down and tagging/foldering makes sense, but before tagging/foldering gets so complex that you just search anyway.
I mostly agree with you on the rest.
Most users of MS Word will be familiar with this.
That said, neither Palm OS or Newton OS could multitask. Android and the iPhone OS seem to have found a very elegant approach to that particular problem without compromising the user experience.
The Palm had 4 threads, only one of which was available to the developer. Another was used for comms and a third for graffiti processing. I don't think the last one was allocated.
The Newton had at least two threads -- comms in the background were needed even in those dark ages.
What should've been taught, from the very beginning, is that we really should be working on versions of the original document. Not that it's an easy problem in itself to solve... refer to various versioning systems as examples.
Some better monitoring device would be useful, but already you can see which services are running, and what has been using the battery. So culprits should be easy to identify and remove, without a task manager.
This article is describing how the main app (the bit you see) functions. When it is swapped out you get an event, then again if they are killed. The OS manages that.
However you can also write services/daemons which are persistent and (as far as I know) not suspended by the operating system. I don't believe they can present a UI but they can communicate with your main app.
These are intended for things like occasional server polling and pushing notifications to the bar. But I don't believe there is any technical restriction on using them for other things.
Its so close to web architecture, that we can see Chrome browser on the other side - it's architecture is making step towards applications by using processes for loaded web pages. Both architectures are closing - apps are more like web pages and web pages are more like apps ...
(A reference to Steve Job's supposed appraisal of John Gruber's article about the iPhone TOS Section 3.3.1. See: http://news.ycombinator.com/item?id=1255858)
On a side note, I seem to take heat every time I imply that phones will end up on par with PCs. The common theme I've been pushing is that most of the developments we've seen in PCs over the past decade will reoccur for phones. Is this really so far fetched?
though, who knows, maybe the declining cost of RAM will solve this problem for PCs, and eventually phones.
A great blog post, the Emperor has No Close about this:
Map a key to launch it. Hit down, then hit close and voila. Can also switch quickly between open apps.
I'm planning to get an android device, but was very disappointed when I played with a droid and learned you can't always kill apps. The culprit in this case was the fandango app. Even after an update, I had to uninstall it because it wasn't responding. Maybe I don't know how to use the app manager?
"You know what iPhone OS is missing that Mac OS X has? The SPOD."
("Spinning pinwheel of death", "rainbow beachball of death", etc.: http://en.wikipedia.org/wiki/Spinning_wait_cursor)
I'm nearly ashamed to admit I have never noticed it's absence until now.
On iPhone, if apps save as they go, excessive usage can be solved with a kill -9 when I press the home button. Relaunching the app will take a few seconds and is transparent; I don't have to fight with the malfunctioning instance.
I'm assuming the OS is modern enough that all apps have their own address space so perhaps the hardware doesn't have an MMU capable of the necessary remapping of physical memory into a different address space.
Oh and two nits with Grubers piece. 1) This system is well thought out but it's hardly "state of the art" and 2) on iPhone OS 4.0 backgrounded apps will receive a willTerminate notification before they're completely terminated.
Paging is really only necessary if you can interact with more than one application at time. On an iPhone, that doesn't happen. Paging is probably less efficient than this system.
And yes, an app can manually attempt to restore it's state but a) doing so can be quite tricky (keyboard up, word half-typed) and b) it's puts a heavy onus on developers, many of whom just do not bother.
Better to persist as little as you need, and deal with everything else through clearly defined lifecycles, IMO. Although, I also think programming languages should provide immutable datatypes by default ;).
Apps compiled for 4.0 are "frozen" when backgrounded. When they are brought to the front, either from the new task pane or their icon, they are unfrozen and restored to a running state. If the iPhone becomes low on memory it terminates frozen apps from least to most recently used.
So since these apps are already suspended, and must deal with a degree of state change when restored, I'm curious why the OS doesn't/can't page their backing store out to flash memory.
People are pretty jazzed about Skype running in the background, but they are going to be dissapointed when they realize that only means that you can keep the current call running while you leave the app. Skype still won't be able to stay open and listen for incoming calls. Same with chat or IRC apps.
"These services include background audio, so apps like Pandora can play music in the background, and VoIP, so VoIP apps can receive a VoIP call even when the iPhone is asleep or the user is running other apps."
This is demoed by Skype's head of product development, David Ponsford around 00:22:20 in the video of the iPhone OS 4 Event: http://events.apple.com.edgesuite.net/1004fk8d5gt/event/
(I personally found most of the event rather interesting, if you have about an hour to spare.)
As an example: now that the iPad SDK is no longer under NDA: one of the most interesting APIs in iPhone OS 3.2 (iPad) is MPMoviePlayerController gaining the backgroundView and view properties. Basically, it opened up a whole arena of interactive video applications that overlay graphics on top of live or recorded video (think
watching baseball game on iPad and pulling up player's on-base stats by clicking on magic button hovering near base, true interactive TV, interactive remote control with show previews...)
I think some companies do take that ethical consideration very seriously. The company I work for provides a digital phone service with E911 and our corporate culture has definitely changed since this service launched. The possibility of interrupting a customer's service even for a few minutes in the middle of the night makes me uncomfortable. There's always that possibility someone will be reaching for the phone to call 911 and you definitely don't want to be responsible for playing any role in preventing it.
XMPP doesn't (yet) have a standardized way of filtering data. Using Privacy Lists is a workable hack. Google implemented their own thing (using Protocol Buffers  to replace XML-on-the-wire, instead of gzipping as the XSF recommends). Process One has their own system as well for OneTeam .
The future ideal is to use SIFT , but it is still experimental and as far as I know, only Prosody  has partially implemented it.
(dammit, how do I embed URLs in the reply?)
If your XMPP server happens to support privacy lists you can request not being send those presence notifications for a while. But at least some servers do not send the last presence when you clear that privacy list. And at least some of those servers do not allow you to get presence for all users in your roster by sending only one (unaddressed) request for presence. You have either to send all users in your roster that request or drop the connection and reconnect to get the current presence of all users.
That'd let developers have cached data that the OS knows it can blow away safely if memory gets low. The app then just regenerates the cache when necessary.
If iPhone OS could look around running processes for purgeable data, it could avoid or postpone killing apps outright. That would only be necessary if purging wasn't sufficient.
In fact, this seems a lot more useful on a swap-free phone than on OS X itself.
Android apps are written in Java. So the standard approach for doing this is to use Java's weak & soft references which basically tell the GC that, "hey, I've used this memory but if you really need it back, you can have it!".
"MemoryFile is a wrapper for the Linux ashmem driver. MemoryFiles are backed by shared memory, which can be optionally set to be purgeable. Purgeable files may have their contents reclaimed by the kernel in low memory conditions (only if allowPurging is set to true). After a file is purged, attempts to read or write the file will cause an IOException to be thrown."
I might be wrong on this.
Take the just-released Macbook Pros for example. nVidia's Optimus has controls at the application-level whereas Apple's technology is at the library/framework-level. There is no user interaction to switch between different graphics chipsets; depending on need for performance/battery life, the OS does "the right thing".
Ars has an article on it