Pause/Resume events do not fire when locking/unlocking screen in ios < 5

Details

Description

I have tested this in the iOS simulator (4.3.2) and an actual device running iOS 4.2.1. When locking the screen with the power button and then unlocking it, in iOS 5, the pause and resume events fire properly.

However, in iOS 4, these events do not fire.

Anyone else seen this? Is there any fix on the way?

Issue Links

is duplicated by

CB-150pause/resume events do not fire when locking/unlocking screen in ios < 5

Resolved

relates to

CB-329Add warning if multi-tasking is not supported on an iOS device (to console log)

By the way, even though the iPhone 3G does not support multitasking, when locking / unlocking the screen (button at the top of the phone or Hardware->Lock in the Simulator), the app is still running (unlike when clicking the menu button, which indeed causes an application to close completely).

Avidan Chen
added a comment - 14/Mar/12 15:04 Both iPhone 3G & the iOS Simulator.
By the way, even though the iPhone 3G does not support multitasking, when locking / unlocking the screen (button at the top of the phone or Hardware->Lock in the Simulator), the app is still running (unlike when clicking the menu button, which indeed causes an application to close completely).

ah it becomes much clearer now. pause/resume are for multitasking states (going into and out of background). For iOS only, there are "resign" and "active" events that you can listen to, for lock and unlock states respectively. I just tried the code below on an iPod Touch 2nd Gen with iOS 4 (no multitasking), and it works for lock/unlock.

Avidan Chen
added a comment - 14/Mar/12 16:40 The problem is, there is inconsistency between iOS 5 & 4 in this issue.
In iOS 5, when you're locking / unlocking the screen, the events pause/resume do fire.
So why don't they in iOS 4?
By the way, the events resign/active are not documented in the Events section of the API reference.

Section: Moving to the Background
When the user presses the Home button, presses the Sleep/Wake button, or the system launches another app, the foreground app transitions to the inactive state and then to the background state. hese transitions result in calls to the app delegate’s applicationWillResignActive: and applicationDidEnterBackground: methods,

So according to that iOS 5 doc, what you see is correct. But, on iOS 4, when locking the app, the applicationDidEnterBackground event is never called (pause).

Shazron Abdullah
added a comment - 14/Mar/12 18:36 They are perfectly consistent with Apple's changing whims on every iOS version's basis Let me explain.
See: https://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
Section: Moving to the Background
When the user presses the Home button, presses the Sleep/Wake button, or the system launches another app, the foreground app transitions to the inactive state and then to the background state. hese transitions result in calls to the app delegate’s applicationWillResignActive: and applicationDidEnterBackground: methods,
So according to that iOS 5 doc, what you see is correct. But, on iOS 4, when locking the app, the applicationDidEnterBackground event is never called (pause).

Thanks for the explanation. It took me some time, but after I first encountered this issue (was a couple of months ago) I eventually found out that applicationDidEnterBackground does not fire in iOS 4 when locking the app. I overcome this issue by manually implementing the resign and active events (I'm still using phonegap 1.2.0 which does not have these events).

However, I thought it would be best to create a consistent experience for JavaScript developers who are not familiar with the details of iOS events. Wouldn't it be best to fire the pause/resume events instead of resign/active? We would need some logic to make sure that pause/resume does not fire twice in iOS 5, but it would make the behavior consistent.

Avidan Chen
added a comment - 14/Mar/12 20:17 Thanks for the explanation. It took me some time, but after I first encountered this issue (was a couple of months ago) I eventually found out that applicationDidEnterBackground does not fire in iOS 4 when locking the app. I overcome this issue by manually implementing the resign and active events (I'm still using phonegap 1.2.0 which does not have these events).
However, I thought it would be best to create a consistent experience for JavaScript developers who are not familiar with the details of iOS events. Wouldn't it be best to fire the pause/resume events instead of resign/active? We would need some logic to make sure that pause/resume does not fire twice in iOS 5, but it would make the behavior consistent.
What do you think?