

Mobile Multitasking - anderzole
http://daringfireball.net/2010/04/mobile_multitasking

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

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

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

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

~~~
roc
And apps like Pages already have an import.

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

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

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

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

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

------
xal
I love daringfireball's new tagline.

~~~
mattparcher
_"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>)

------
johnrob
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?

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

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

------
wvenable
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...](http://blogs.msdn.com/windowsmobile/archive/2006/10/05/The-
Emperor-Has-No-Close.aspx)

~~~
izendejas
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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
antrix
> 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...](http://developer.android.com/reference/java/lang/ref/SoftReference.html)

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

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

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

~~~
brisance
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...](http://arstechnica.com/apple/news/2010/04/inside-apples-
automatic-gpu-switching.ars)

