[TIMOB-3121] Does Not Fire Resume Event When Returning from iOS Multitasking Bar
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Trivial |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-11-01T12:48:17.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Sprint 2011-28, Release 1.8.0 |
| Components | iOS |
| Labels | n/a |
| Reporter | Jon Alter |
| Assignee | Blain Hamon |
| Created | 2011-04-15T03:37:27.000+0000 |
| Updated | 2012-02-10T00:52:22.000+0000 |
Description
In iOS when a user double taps the home button to bring up the multitasking bar, Titanium fires a pause event. If the user double taps the home button again to dismiss the multitasking bar, Titanium does NOT fire a resume event.
Found the same results when testing SDK versions 1.5.1, 1.6.0.RC1, 1.7.0 w/ iOS SDK version 4.2
Associated Helpdesk Ticket
http://developer.appcelerator.com/helpdesk/view/72951">http://developer.appcelerator.com/helpdesk/view/72951
Similarly, when a notification (e.g. text message) is received, a pause event is fired, but no corresponding resume event is fired if the user dismisses the notification (and stays in the app).
Also, when the device is locked and unlocked, there is a pause event, but no resume event.
I now see that "resumed" (with a D) events are being fired when returning from the multitasking bar. I haven't tested it yet, but I assume this is the case for dismissing notifications and unlocking as well. Maybe the "resume" event is an additional event only for when the app is relaunched from the background?
So, maybe this is working correctly? Hopefully the documentation will make the distinction between resume & resumed clear?
Here's the breakdown of iOS native app delegate calls to Ti.App events: -(void)applicationWillEnterForeground:(UIApplication *)application fires a 'resume' event - (void)applicationDidBecomeActive:(UIApplication *)application fires a 'resumed' event -(void)applicationWillResignActive:(UIApplication *)application fires a 'pause' event Cross-referencing with http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIApplicationDelegate_Protocol/Reference/Reference.html gives us: Resume: In iOS 4.0 and later, this method is called as part of the transition from the background to the inactive state. You can use this method to undo many of the changes you made to your application upon entering the background. The call to this method is invariably followed by a call to the applicationDidBecomeActive: method, which then moves the application from the inactive to the active state. Resumed: This method is called to let your application know that it moved from the inactive to active state. This can occur because your application was launched by the user or the system. Applications can also return to the active state if the user chooses to ignore an interruption (such as an incoming phone call or SMS message) that sent the application temporarily to the inactive state. Pause: This method is called to let your application know that it is about to move from the active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state. An application in the inactive state continues to run but does not dispatch incoming events to responders. Should this be a documentation or parity issue instead?
Quick update: Android represents the lifecycle in a different fashion, so this is all iOS. So let's call this a documentation issue and note that the behavior is te expected one.
Validated & accepted pull.
Tested On: Mac OSX Lion TiMob: 1.8.0.v20110819142548 TiStud: 1.0.4.201108101535 Devices: iPhone 4 version 4.2.10 iPad2 version 4.3.5 iPod 3
Missed reclosing this issue during scrub.