Quick Download of Multiple Attachments in Apple Mail
To download a bunch of attachments quickly, look in the header of the email message that they came in. Make sure the triangle adjacent to the paperclip icon is pointing to the right (click the triangle if needed), and then drag the paperclip icon to your Desktop or to another folder. Release the mouse button and all attachments copy to that location.
Written by
Tonya Engst
Recent TidBITS Talk Discussions
- Alternatives to MobileMe for syncing calendars between iPad/Mac (1 message)
- Free anti-virus for the Mac (20 messages)
- iTunes 10 syncing iPod Touch 4.1 (2 messages)
- Thoughts about Ping (16 messages)
Related Articles
- Look! Nook Took Books (18 Aug 10)
- Take Control's Problems with Apps and Docs in iOS (25 Jul 10)
- iOS 4: Essential Early Reading (28 Jun 10)
- iOS 4 Available for Download (21 Jun 10)
- iTunes 9.2 Released to Support iOS 4 and iPhone 4 (16 Jun 10)
- AT&T Suspends iPhone 4 Pre-Orders Temporarily (16 Jun 10)
- Does the iPhone OS Need Multitasking? (08 Feb 10)
- Free TidBITS News iPhone App (04 Jan 10)
Published in TidBITS 1034.
Subscribe to our weekly email edition.
- iPhone Signal Strength Sets Bars Too High
- Hulu Plus Brings Subscription TV to iOS
- Amazon Releases Cheaper Kindle DX
- How to Share Purchased iBooks
- Pondering Friendship Online: Focus on Intimacy
- Pondering Friendship Online: Expand Asymmetrically
- TidBITS Watchlist: Notable Software Updates for 5 July 2010
- ExtraBITS for 5 July 2010
What is Fast App Switching?
Those of you who have just used iTunes to install a shiny new iOS 4 on your iPhone or iPod touch, or who are about to obtain a shiny new iPhone 4, may find yourselves wondering about one of the touted features of this new system, fast app switching. What is fast app switching? What does it have to do with multitasking? Does it operate only through the new Home button double-press behavior? And why, for most apps, does nothing very remarkable or new seem to be happening?
Return with us now to those thrilling days of yesteryear (was it really just four months ago?), when Adam penned his provocative "Does the iPhone OS Need Multitasking?" (8 February 2010). As Adam pointed out then, in his prescient and trenchant analysis, multitasking means different things to different people. You might mean (1) what happens on Mac OS X, where multiple applications really do run simultaneously and you return from application A to a window of application B to find it in the state you left it. Or you might mean (2) the mere ability to switch rapidly between recently used applications, which save state on quitting so that they behave as if they'd remained in the state you left them. What Apple has actually implemented is something a little more ambitious than option 2, but still considerably less resource-intensive (and potentially dangerous) than option 1.
Here's the long and short of it. When you are running an app in iOS 4 and you press the Home button once to leave it, the app doesn't quit. Instead, it goes into suspended animation, like the scientists in cryogenic hibernation in "2001: A Space Odyssey." The app simply stops receiving events from the system; its run loop isn't looping. The app is both backgrounded and inert; but it is still "running," in the sense that its resources and interface are still present, so that it doesn't have to be relaunched from scratch in order to resume. That way, when you come back to that app, no matter how, the app can simply pick up doing what it was doing when you left off, instantly.
This behavior is fast app switching, and is most of what Apple calls multitasking on iOS 4. (It is not the whole of iOS 4 multitasking, because some apps with specialized functionality will register with the system to be allowed to go into suspended animation with one thread still active; such functionality is strictly limited to playing audio, location detection, and voice-over-IP. But in this article I'm not concerned with those situations.)
The fast app switching interface that you get when you double-press the Home button (a gesture also correctly predicted by Adam's article) is thus all but irrelevant to the story. Indeed, it comes as a surprise to early adopters of iOS 4.0 to realize that the fast app switching interface does not list running apps. It lists recently used apps. It's a convenient way to leave an app and launch (or resume) a different, recently used app, but it could just as well have been present back in the earliest versions of the iPhone OS. It's mere interface, the iPhone equivalent of the Mac's Command-Tab switcher. It's also a very good, very welcome interface; I wish the iPhone had worked like this all along, because switching between apps, especially between a specific pair of apps, is something I do very often. But it has nothing to do with the underlying multitasking technology of fast app switching.
You actually have no easy way to learn what apps are running (suspended). When you launch or resume an app, you can usually tell the difference between whether the app was terminated or suspended, because a terminated app will go through its launch procedure (which may involve a splash screen and other obvious clues), whereas a suspended app will just appear, instantly, right where you left it. And you have no easy way to truly quit (terminate) an app. When you leave an app, no matter how - whether you use the fast app switching interface or just single-press the Home button - the system does what it does; it isn't up to you.
Therefore, you should be wondering at this point how an app ever really quits. Surely your iPhone won't be filled with the frozen bodies of dozens of suspended apps until you reboot? There are three ways an app can be genuinely terminated:
- The system can, at any time, terminate a suspended app (again, just like the scientists in "2001: A Space Odyssey"). It would decide to do this, not because it has gone bonkers (like HAL 9000), but because every suspended app, even though it isn't using any CPU time, is nevertheless using some memory, and memory is a limited and precious resource on a mobile device. The system reserves the right, therefore, to reclaim memory by terminating a suspended app.
- You can terminate a suspended app manually. That's what happens if you double-press Home to enter the fast app switching interface, tap and hold on one of the four icons there to go into "shaky mode," and then tap the red delete button on any of the four icons. (If the app isn't running at all, of course, then you're just removing it from the list of recently used apps.)
- If an app has not been specifically recompiled for iOS 4, then when you leave it, no matter how, it is terminated.
That final point is key, especially because it contradicts everything I've said about multitasking so far. It turns out that in order to participate in multitasking and allow itself to be suspended, every app must be recompiled for iOS 4. An app that doesn't appear to behave any differently when you resume it on iOS 4 from how it behaved when you relaunched it on earlier versions of the system simply hasn't been recompiled yet. That, as a moment's reflection will show, would be the vast majority of apps!
Clearly it will take some time for developers to recompile for iOS 4 and get their updates past Apple's App Store gatekeepers and onto your device. Until they do, you won't see all that much benefit from multitasking on iOS 4. Only Apple's own apps, and those few apps that have already been updated, are acting in a new way.
Moreover, recompiling for iOS 4 is non-trivial (as I just found out while doing it for the TidBITS News app - see "Free TidBITS News iPhone App," 4 January 2010), because it will also require some rewriting. The app instantly participates in multitasking with no changes in code, merely by virtue of linking to the new iOS 4.0 frameworks - but that doesn't make it a good multitasking citizen.
One major issue is that an iOS 4-native app is notified when it is suspended, but not when it is terminated. Thus, it must do all the things to save state when it is suspended that it used to when it was terminated, just in case it later is terminated. Another issue is that the app, as it is suspended, needs to stop doing things that might cause trouble later. It must explicitly reduce its memory use if it doesn't want to be a candidate for later background termination by the system. It must cease any network activity. It may have to cancel a modal state, such as an alert that might not make sense when the user resumes later (possibly days later).
Those are all things I had to worry about when updating the TidBITS News app for iOS 4.0. Basically I had to consider every state the app might be in at the moment the user comes along and suspends it. That turned out to be remarkably difficult - and the TidBITS News app is very simple and small! Imagine, then, how long it will probably take before your favorite third-party apps are updated.
But when they are updated, you'll be switching between them with lightning speed. That's when you'll really experience fast app switching, leaving an app and coming back to it later to find it immediately ready to resume from where you left it. That's iOS 4's version of multitasking.
Get the all-new Dragon Dictate for Mac from Nuance Communications
and experience Simply Smarter Speech Recognition.
Learn more about Dragon Dictate: <http://nuance.com/dragon/mac>
I'm actually in a similar boat, as I had double-click home set to bring up my favorites in the Phone app. That was how I always interacted with it (and with my contacts), so I relegated both of those apps to a lesser-used screen. Time to change my habits. :)
I do have a doubt on this: "If an app has not been specifically recompiled for iOS 4, then when you quit it, it is terminated".
Apps are updated as we speak, but having had the iOS 4 for weeks now, I always saw third party apps, obviously not yet updated, sitting in the background when double clicking on the home button.
So what do you mean with this last point? Is there any change on the post GM iOS4?
You are the second person to write me who has been confused in this way, imagining that what you see when you double-click the home button is a list of running apps, so I have added language to the article to emphasize this point.
This reminds me of the problem I have on the iPad where I can't tell in advance whether an app will open into full screen (it's iPad-native) or into the iPhone simulator box. :)
Keep up the good work!
Cheers
Rick
After tapping an icon's red minus tag, it disappears from the recently-used list (and doesn't show up the next time I visit), not unlike tapping on the X to remove an app. However, the app still shows in its normal home page location. Does that mean I have found the way to actually quit an app?
(The app I tested has recently been updated but has a short startup time so I can't be sure whether the next invocation went thru startup or not.)
But I wonder about this: MapQuest seems to be quite the battery-burner, yet once I no longer need it, I have to go thru the rather contorted click/hold-and-tap-minus approach? (Often, while driving, once I've worked my way out of an unfamiliar neighborhood.) Isn't this a bit ugly?
That said, I've been testing the Navigon GPS app and in my experience it just terminates in the background after a little while on its own, even when it shouldn't.
So I think Apple's answer would be, "It will just work - you shouldn't have to think about quitting apps."
And I think the real-world answer will be, "Well-written apps shouldn't be a problem; others might be."
While we know they won't "multitask", will apps that are recompiled for iOS4 be able to resume from a saved state rather than relaunch?
I know some apps were able to do this under iOS3 but will recompiling for iOS4 provide this functionality automatically for 3G owners or will it, once again, be very app specific?
This is not completely accurate. It turns out you can distinguish between a suspend event and a termination event. When an app suspends, applicationDidEnterBackground: is called on your app delegate. When an app is terminated, applicationWillTerminate: is called instead.
Check out the section titled "The Application Life Cycle" in Apple's documentation: http://bit.ly/dsMQAu
after two years of developers generally not saving states, i don't understand why apple hasn't done a matching 'fast restart' process.
and trying to use it. 3.x apps mixed w/ free interpretation of 4.x guidelines. talk about fragmentation problems!
Unsaved data and settings have nothing to do with relaunching an app in the same state as it was left. Though the latter is good practice, the safety of your data is not affected.
Also, I don't understand what you mean by fragmentation problems. Some apps will suspend, some will terminate. So what? More and more apps will be written to relaunch where they left off no matter what, as users start to demand it.
Apple has made the right choices given the hardware constraints.
if you say so. most people i think would expect those apps where it was appropriate, such as a web browser, to return to a state including data entered in a web form, if the form hadn't been submitted and the page hadn't been closed. mobile safari still now today throws away user-entered data!
this is an iphone 3GS. i wrote the paragraph above, did 'select all' & 'copy', then switched to enough other apps to really put pressure on free memory. came back to iOS4's safari and what do i see? the page is being reloaded -- the popover web form is gone, the entered text is lost.
Maybe I'm showing my colours, but it seems when Apple doesn't implement some obvious feature (multitasking in this case, or more properly, fast app switching (FAS)) it's because they want to do it right within their design philosophy.
I can wait.
And another thing, I'm not sure what the turnover in apps is, but I doubt most of the 200,000+ apps will be rewritten anytime soon, that is, we're more likely to get a new version rather than an update, which makes sense, since from your experience rewriting an app to include FAS is non-trivial.
I figure the most-popular apps will likely be updated quickly for at least basic fast app switching.
I'm already seeing updates with multitasking to many of the hundreds of programs I use regularly, including TomTom's navigation software (updated with background location support).
http://cli.gs/9AsaQ
See http://www.folklore.org/StoryView.py?story=Switcher.txt
I suppose developers need to write in a "stop" button into the program that they didn't need before. It's analogous to the iPod app. If you listened to a song, and switched to safari, the song keeps playing unless you go back and turn it off in the app. Pandora and Nav apps would just stop on Exit. Now I guess they both will have to add a UI that says "although I am now allowed to run in the background, I choose not to at this time".
In the TidBITS News app I had to face an analogous problem: what if the user suspends me while streaming one of our podcasts? My tests suggested that this might continue in the background, and I didn't want to take a chance on that, so when the user suspends, I cancel podcast streaming. All part of being a good multitasking citizen, as I say in the article.
I think that most people agree that the new limited and controlled background processes are a major new feature of iOS4. I love that Pandora will have a hook to do background processing IF I WANT IT. I love that AirSharing will be able to finish a download IF I WANT IT. I love that there are supposedly Location Services hooks for Navigation apps to continue guiding me even if I get a phone call. That's the implied beauty of MultiTasking.
I was just curious if you knew, because of your informative article, how developers and Apple will control the processes/UI so that I can be sure that my apps aren't continuing their processing WHEN I DON"T WANT THEM TO. (no shouting there, just emphasis ;-)
I thought your toolkit and developer guidelines might shed light on how Apple suggests this should be treated. iPod app has a Pause, Pandora probably will.
I just upgraded my app to iOS4 and enabled fast-switching. The changes are actually quite small to make it work reasonably well:
0. Rebuild the app with iOS4. As the article pointed out, this step along enables fast-switching, though the app might not behave reasonably in all cases.
1. Save app state in applicationDidEnterBackground callback. Because the app in bg might be killed without notice, and next time it will be launched not resumed. When this happens, you still want the user to feel they return to where the left.
2. Now user can change app settings (assume you have settings.bundle) without quitting the app. App needs to register NSUserDefaultsDidChangeNotification and catch all the pref changes upon resuming. I usually register this in my viewcontroller in viewDidLoad and unregister it in viewDidUnload and dealloc.
One thing to point out: multitasking doesn't mean you don't have to save app state. App might still be killed so it's needed.
But the App Store notice saying that an app has been *tested* with iOS 4 *doesn't* mean that the app has been recompiled for iOS 4. It means no more than it says: the app works okay in iOS 4 (according to the developer - this is just a checkbox in the app submission form).
Here's an analogy. Version 1.0 of the TidBITS News app worked fine on iPhone but not on iPad, not even in the "iPhone simulator" on the iPad (because of a bug in that simulator). We had no way of knowing that would happen, because when we wrote TidBITS News there was no such thing as an iPad - so the app had never been tested on an iPad. Once we had iPad, we saw the problem, and we worked around the problem and submitted Version 1.1 of TidBITS News. Now it works fine on iPad. But it's still not an iPad-native app; it runs in the "iPhone simulator". So now it is iPad-tested, but not iPad-native.
Some curious behavior with the iOS and state -- if I click on the link to a webpage from the Tidbits app, close and return to Tidbits, I go back to the the TidBits article and not the web page I was on (sure make sense, but also a bit confusing first time).
My comments here are as a user of the phone and not a programmer, but earlier this week got into this "state loop" as I called in:
Can't connect to 3G after sending a file
App keeps sending file
Force quit app
App returns to state of sending a file
Must manually stop file send either in outbox or by canceling upload.
It not only lets you override settings per app, but also adds little black and blue badge overlays telling you if an app is natively backgrounded currently (blue), or by backgrounder itself (black).