Mobile Multitasking | Hacker News Reader

Mobile Multitasking

daringfireball.net

75 pointsanderzole64 comments

I'm glad that iPhone OS is providing us an excuse to take personal computing a least a few steps down the path to where it should have gone years ago.

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.

I'm not so sure abstracting away document open is a good idea in the long run. You lose the ability to separate your valuable data from the application, and it encourages lock-in within each app.

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.

Document Open certainly didn't prevent proprietary document nightmares. Lock-in is only an issue inasmuch as users don't demand a sane export. Pages documents could be a proprietary, patent-protected nightmare internally and it wouldn't matter to me: when I want the document out, I export it back to myself in a standard format. (Sure, it'd be nice to have a mass-export, but these things will come with time.)

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.

Yes proprietary formats encourage lock-in too and open standard doc formats are better. But the 'export' that you mention requires a document open (or 'import') on the other end.

I mostly agree with you on the rest.

And apps like Pages already have an import.

"You lose the ability to separate your valuable data from the application, and it encourages lock-in within each app."

Most users of MS Word will be familiar with this.

Only because RTF is not well-known among nontechnical users.

And because most moderately complex Word documents will not transfer 100% when you save them as RTF. Or said differently, RTF documents won't display the same in different applications if they contain enough complexity.

You mean, following down the path that Palm OS devices used since first released in 1996?

Or Newton OS devices from 1993. This isn't the first time that Apple has tried to build a computer with seamless state persistence and without a traditional exposed file system.

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.

Actually, both of them could, but just in very limited ways.

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.

If you want to edit a document and then save it as a new document you have to make that choice before you start editing on the iPad. A lot of people are going to destroy a lot of documents that way. It could be a simple fix to still keep the same model but right now it's not very intuitive.

Well that's because we as users have been conditioned to make a copy of a document whenever an edit is required.

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.

I agree. But versioning isn't implemented in the iPad and they may never implement it because it's too complicated for users to understand. Without it, though, any program that just saves your document (permanently) without asking is going to be annoying.

Would anyone be shocked if the iPad eventually featured some version of Time Machine and that versioning just happened automagically in the background?

I agree. I was showing my iPad to a friend the other day and she asked me how to save a Pages document. It took me a few seconds to figure out how to explain that there was no need to save documents. Documents are just always there.

I was actually thinking the same thing... It really doesn't seem like it would be too hard to do on a networked computer with access to backup on the cloud and fast uplink.

Task-oriented UI?

You certainly do need a task manager on Android for the simple reason that certain types of applications can be battery hogs. They may not tax the performance of the device enough to be killed automatically. I know Android 2.x is supposed to monitor battery usage but it simply doesn't work very well -- or at all in some cases. Subsonic (streaming audio client) kills my phone's battery if I don't kill it manually with a task manager. The app does not include a quit option. It can kill my battery in about 3 hours even if I pause playback because it keeps its connection to the server open. Another app I use, Jabiru (jabber client), does the same thing but it does have a disconnect and quit option so I wouldn't need a third party task manager to deal with it. So it seems to me Android's multi-tasking is largely dependent on the applications you use.

I admit that in the beginning it is a bit unnerving not to be sure what the apps are doing under the hood. My response to suspicious activity is usually to uninstall the app, though.

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.

Android gives you a readout of which apps have been using the battery.

Yes that is what I meant, should have formulated it better.

There are two kinds of background processes in Android (unless it's changed since I last wrote an app, which is possible - that was for OS 1.5).

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.

These Android/iPhone apps architecture is very close to web page approach. In web environment, you can load the page, interact with page, you can close it anytime a do something else. Traditional application were different but these modern mobile apps do the same - you open app like page, you navigate somewhere else and OS close app automatically. Some apps are using cloud data but some can use local storage.

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 ...

I love daringfireball's new tagline.

"Insightful and Not Negative"

(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)

Moore's law seems to be in full effect for handsets. I think a lot of the innovation here is a stop gap measure before these handsets have virtual memory, making the complication behind multi tasking obsolete.

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?

I hope not. My iPad with 256MB of RAM and a relatively slow ARM processor feels snappier than my laptop with 2GB and a dual-core 64-bit Intel processor, partly due to the consistency: I never know, on the latter, whether an application will respond quickly (because it is active in memory), or slowly (because it isn't). If I could use iPhone OS's model on my laptop-- with more freedom due to the increased memory, but still omitting swap in favor of automatic saving/memory management-- I would.

though, who knows, maybe the declining cost of RAM will solve this problem for PCs, and eventually phones.

It gets a little silly to talk about "phones" in this context. Making and receiving one-to-one voice communications is already just one of many features, and arguably already not the main feature.

And, on the iPad, not a feature at all. :)

The close button on Windows Mobile never closed the apps either, it just minimized them. If you ran out of memory, Windows Mobile would close the oldest used application automatically.

A great blog post, the Emperor has No Close about this:

http://blogs.msdn.com/windowsmobile/archive/2006/10/05/The-E...

If anyone still uses Windows Mobile, I recommend WkTask (not sure it works on 6.5): http://soft.photoracer.net/docs/wktask_en.html

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?

The default is to minimize apps when you tap the close button, but kill them if you hold it down. You can change this in the preferences.

His closing thought on the matter:

"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.

It doesn't have the SPOD, but it does occasionally freeze with an app in an unusable state. The SPOD is only not there because they didn't add it, not because an unresponsive system is impossible with the iPhone OS.

SPOD doesn't mean an unresponsive system, just an unresponsive app so this a functional regression in iPhone if you can't switch to other apps while the frozen one recovers.

But sometimes it does mean an unresponsive system. All an application has to do is allocate a bunch of RAM (or spin the CPU on a number of threads >= cores) and the system slows to a crawl. It can't really kill those apps unless I ask it to, because work might be lost.

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.

on osX (or any other OS), if apps save as they go, excessive usage can be solved with a kill -9 whenever the OS likes..

I'm curious why iPhone can't page application memory out to persistent storage (whatever of that 16GB etc you're not using for music) when they're in the background and RAM runs low. That would be the ideal - frozen background apps saved to persistent storage until needed without sitting in RAM.

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.

When an app is swapped to disk, all it's code and data pages are stored. When it's resumed, the code and data pages are loaded back. This isn't so terribly different from relaunching the application (loading the code) and having the app restore it's state (loading the data). In fact, the app can even be more efficient in saving it's own state because it can discard anything it knows it doesn't need.

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.

Paging is a technique to free up RAM. Whether its used to enable interaction with multiple apps, to allow a single app access to more memory than physically exists, or to allow more apps to be frozen in the background is irrelevant. It is neither better nor worse than the system Apple has designed. Its just different.

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.

Of course, then you have to deal with resources – like when you unfreeze your app partway through typing a word, but in the meantime the user has changed keyboard layouts, or you unfreeze the camera program but meanwhile something else has been using the camera and left it in a different state.

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 ;).

Good points - except that under iPhone OS 4.0 the OS and apps already have to handle these situations.

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.

Ah true. Maybe they just want to avoid eating into the limited number of writes flash mem handles?

I'm glad he made this point, but he's still not giving Android enough credit. With Android, apps can create a service that can run and do whatever it likes. It's not limited to a couple APIs.

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.

Not true. The background services offered by the OS allow the apps to still receive calls/IMs etc while not in the foreground. According to Apple press release:

"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."

http://www.apple.com/pr/library/2010/04/08iphoneos.html

cpr and swernli are correct: Skype can "listen" for incoming calls.

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.)

That could have been done with a tweak to push notifications, no?

Your last paragraph isn't true about VOIP apps, but I can't say more due to the NDA.

I really don't understand why Apple has an NDA on its essentially public developer program. There are so many iPhone developers that all the standard rules and agreements will be made public almost instantly no matter what.

No, part of the privilege of being a registered iPhone developer is you get access to beta SDKs and information that the public does not. The idea is to give iPhone developers who are in their program a head start. The fear of getting booted from Apple's program is usually sufficient to bite your tongue before you saying something in public that should not be discussed.

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...)

http://developer.apple.com/iphone/library/documentation/Medi...

And part of the problem is what we see here, which is that potentially incorrect information cannot be authoritatively debunked, perhaps for months. This gives plenty of time for the wrong "facts" to get lodged in people's heads, so even when the truth comes out people will carry on with false beliefs.

Do you get acceptable battery life running an IRC client in the background? The client has to keep a persistent data connection open and will be constantly transferring data. I've not had much luck with IM clients on BlackBerry, WebOS or Android. I guess the bigger question is if the user's battery should be drained in a situation where they don't understand the ramifications of what they're doing. If you're playing a 3D game for an hour you're focused on the screen and can watch the battery meter go down. If you open the IRC client, forget about it, pocket the phone, and a few hours later fall down with a heart attack -- unable to call 911 that's a different issue entirely.

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.

I stay logged into gtalk on my Nexus One continuously. I don't notice any significant battery drain because of it, and I often have longish conversations with people while waiting for the train via gtalk. The gtalk app doesn't even show up as a significant user of battery power in the "Battery Use" list.

Actually, from talking with the OneSocialWeb [1] and BuddyCloud [2] guys, I understood that Android phones have a really sophisticated "always connected" philosophy. The main CPU can go into deep sleep and the phone still maintains a persistent data connection, waking up the CPU on incoming data. That's for the low-level IP stuff. TCP-over-GSM really sucks your battery.

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 [3] to replace XML-on-the-wire, instead of gzipping as the XSF recommends). Process One has their own system as well for OneTeam [4].

The future ideal is to use SIFT [5], but it is still experimental and as far as I know, only Prosody [6] has partially implemented it.

[1] http://onesocialweb.org/ [2] http://buddycloud.com/ [3] http://code.google.com/p/protobuf/ [4] http://www.process-one.net/en/solutions/oneteam_iphone/ [5] http://xmpp.org/extensions/xep-0273.html [6] http://prosody.im/ (dammit, how do I embed URLs in the reply?)

The reason is that Google has control over the XMPP server. They do not need to send you presence notification if your gtalk client is not in foreground. Just staying online is not the problem. The problem is that usually with XMPP the server sends presence asynchronously. There is no standardized way for a client to request not being send those. If you happen to have 200 or more users in your roster there is always someone going away or coming back. Receiving those packets is draining the battery.

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.

My mistake. I just looked through some of the documentation, and I was wrong. Previously I just read some of Apple's high-level docs, which didn't make it clear.

It'll be interesting to see if Snow Leopard's NSPurgeableData and related stuff moves to iPhone OS. (I gather Google's phone OS have something similar).

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.

> I gather Google's phone OS have something similar

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!".

http://developer.android.com/reference/java/lang/ref/SoftRef...

Android also has the MemoryFile class, which can be set "purgeable".

"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."

What's the link between blocks/grand central and multitasking on the iPhone?

It sounds like Grand Central is the mechanism through which multitasking roles are described/created; i.e. programmers declare the background parts of their app as closures (GCD blocks) which are handed off to a task manager.

I might be wrong on this.

none. grand central is a scheme to make it easier to parallelize your code, generally so it can take advantage of two or more cpu cores. not much use on iphone devices, which aren't going to have more than one core for a long time. blocks add closure-like abilities to C. multitasking, in this context, is a way to run two or more third-party apps at once. so, basically, no overlap at all.

Apple may be laying the groundwork for specialized multicore processors on mobile handsets.

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 http://arstechnica.com/apple/news/2010/04/inside-apples-auto...

Reply on news.ycombinator.com