devsugar: Understanding iPhone 4 backgrounding
If you're looking for a simple and easy-to-follow introduction to iPhone 4's new backgrounding abilities, head on over to Oliver Drobnik's weblog and check out his latest write-up. You'll find a lovingly crafted graphic that walks you through the iPhone application lifecycle, showing how an application reacts to system changes like incoming phone calls or users' home button presses. A small portion of the chart appears at the top of this post.
Don't miss Drobnik's write-up in addition to his flowchart. I like the case he lays out for using applicationDidEnterBackground as the perfect place for saving state before giving up application control. As he points out, applicationWillTerminate will not get called in many application suspension cases.
Drobnik continues to refine his write-up, so keep checking back in for last-minute tuning and updates.
Share
Categories
If you're looking for a simple and easy-to-follow introduction to iPhone 4's new backgrounding abilities, head on over to Oliver...
Add a Comment
I'm still confused at Steve saying "if you have a task manager, you're doing it wrong" in regards to multitasking, and yet here we have a task manager, and I find myself frequently going in and quitting apps to regain memory.
July 07 2010 at 4:41 AM Report abuse Permalink rate up rate down ReplyIt's not a real task manager. It's actually only a list of recent apps. Removing and app from the list does not regain you any memory with apps built for SDK < 4. Only IF it's suspended in background or running then the removal will also trigger a kill.
July 07 2010 at 5:07 AM Report abuse Permalink rate up rate down ReplyOn iOS 4, there's no need to save UI state upon the app being killed. Because, it doesn't really make sense if you want to continue a previous state after it's being killed.
By default the UI state doesn't change if the app is entering the background loop.
hmlong - if your app is being killed it is already suspended therefore not "running", so there is nothing it can respond to as such.
July 06 2010 at 4:44 PM Report abuse Permalink rate up rate down ReplyI agree. It's a common practice on mobile platform to directly kill a bg task without giving it any chance to run even one line of code. This ensures the OS can reclaim the resource in a timely manner.
Android works similarly. All activities are recommended to save state on onPause(). But there is one thing Android does better: it saves the view (activity) stack, and state of ui controls for you. On iPhone you'll have to do all these on your own. Not complicated but lots of boring work.
It's already suspended, true. But it's still intact and in memory, thus there is in fact something to communicate with before completely killing it.
July 07 2010 at 3:01 AM Report abuse Permalink rate up rate down ReplyLooks like Apple should add a method indicating that your application is being killed. Understand you're being killed due to low resources, but saving state on every applicationDidEnterBackground (switch) seems a bit wasteful.
July 06 2010 at 4:05 PM Report abuse Permalink rate up rate down ReplyDeals of the Day
more deals- $15 Apple iTunes Gift Card for $8 for new Saveology customers
- Philips Fidelio Docking Speaker Station for iPhone / iPod for $38 + $6 s&h
- Retro 80's Case for iPhone for $11 + $2 s&h
- HHI 360 Dual-View Stand Case for new iPad w/ $2 credit for $12 + $3 s&h
- HHI ReElegant Smart Cover Companion Case for new iPad from $5 + $3 s&h
- Used Apple iPad 64GB WiFi + 3G for $240 + free shipping
Software Updates
more updatesFeatured Stories
more stories
Popular Stories
TUAW (or The Unofficial Apple Weblog) is a website devoted to tips, reviews, news, analysis and opinion on everything Apple.
10 Comments