15

I have used:

[UIApplication sharedApplication].idleTimerDisabled = YES;

in a number of Apps developed and running under iPhone OS 2.x and never had any problems with it. They were clock apps so needed to run constantly and ignore the iPhone's idle Timer setting.

However, trying to achieve the same with a new App running OS 3.0 (and which needs to be deployed under 3.0 as it uses some 3.0 APIs) I've found the idle Timer to be either ignored or inconsistent.

My App plays music from the iPod library and when the music is playing it auto-locks regardless of the above setting. But once you unlock it, it then doesn't auto-lock again unless you play music again, in which case it locks again after the iPhone auto-lock time setting.

I'm amazed no-one else has come across this as I imagine it would affect a large number of Apps.

Just to clarify:
1. The above code is in ApplicationDidFinishLaunching
2. I know that the phone won't auto-lock when testing from xCode regardless of settings

If anyone has any thoughts I'd be very grateful...

Nifle
  • 11,745
  • 10
  • 75
  • 100
Craig
  • 683
  • 1
  • 8
  • 16
  • are you using an audio session when you're playing music? I'm thinking that somehow perhaps the idleTimerDisabled property is being reset somehow when you start to play music... perhaps your fix is as simple as putting another idleTimerDisabled=YES in your code just after you start the music playing. – David Maymudes Jun 29 '09 at 18:58
  • Thanks.. Yes - I tried that, thinking along the same lines. Made no difference. Cheers. – Craig Jun 29 '09 at 20:31
  • "I know that the phone won't auto-lock when testing from xCode regardless of settings" - thank you! I didn't realize that and I couldn't figure out why my app wasn't allowing the phone to auto-lock. – filipe May 03 '11 at 00:03

5 Answers5

16

Our app uses the MPMediaPLayer. We also had the idleTimerDisabled=YES code in the ApplicationFinishedLaunching, which works EXCEPT if untethered, and there is already a current nowPlayingItem which is left playing (or unpaused, if paused at app startup). Obviously this is all with the Settings -> General -> Autolock set to some timed value.

By adding idleTimerDisabled=NO, immedately followed by idleTimerDisabled=YES in one of the other bits of code AFTER we had figured out what bit of music we would get playing seemed to solve the problem. Just setting it to YES was insufficient.. and subsequent queries had always indicated the correct value (YES).. so it appears the Apple code ignores the setting of the value IF there is a current piece of music and that is not changed by your code.. but does notice a change of value.

This is all under iOS 3.0.

James Nelson
  • 1,793
  • 1
  • 20
  • 25
Neil
  • 176
  • 3
  • Hi Neil - thanks for this. I have actually just found a fix along the same lines. If you set up a timer for every 30 seconds to set the idleTimerDisabled to NO and then YES, it stays on regardless of the music playing settings. It's a bit of a hack but it works! – Craig Aug 12 '09 at 10:09
  • I found this same behavior in iOS 3, and the solution above worked for me. Since I have audio starting and stopping in my app which disrupts my idle timer setting, I set up a timer and each time it ran, I checked my application state and either turned the idleTimer off and then on again if I wanted it to be on, or turned it off if I didn't. But under iOS 4, I found that turning OFF the idleTimer in that loop keeps the device from going into idle mode! So I had to adjust my code to turn the idle timer off just once rather than each time through the loop. – arlomedia Jan 29 '11 at 16:47
3

Even in 2015, using iOS 8.2, this bug is still alive and kicking.

Here's my solution, using XCode 6.2.

iPhone - phone goes to sleep even if idleTimerDisabled is YES

Basically, even now, in 2015, the only way to safely make sure that the device doesn't go to sleep is to repeatedly call a piece of code to keep the device awake.

-(void)callEveryTwentySeconds
{
    //  DON'T let the device go to sleep during our sync
    [[UIApplication sharedApplication] setIdleTimerDisabled:NO];
    [[UIApplication sharedApplication] setIdleTimerDisabled:YES];
}
Community
  • 1
  • 1
Mike Gledhill
  • 27,846
  • 7
  • 149
  • 159
0

Sounds like a bug, file with Radar - I am not too surprised this has not been seen much as there are probably not a lot of apps that try to lock the screen open and play music.

Kendall Helmstetter Gelner
  • 74,769
  • 26
  • 128
  • 150
0

Having same issue. It does work when the device is plugged in. You can press lock button on top, and my NSTimer fires later and causes a vibrate. However if the device is not plugged in pressing the lock button puts the device to sleep. Any solution would be greatly appreciated.

  • iCodeblog posted about the idletimer, I said it didn't work, and the person who develops 'cute clock' was nice enough to reply. You have to do a hack, play a 1 second or longer silent sound every 10 or so seconds with NSTimer. This keeps the device awake even if the user hits the lock button.
  • 1
    Hi - Don't forget that the device won't go to sleep when connected to XCode - it doesn't mean that the idleTimer command is working. There doesn't appear to be a solution yet though. – Craig Jul 23 '09 at 10:11
0

I develop Seconds - Interval Timer for iPhone and iPod touch and I've had no end of trouble with this. The idea of my app is that people create timers based on a number of intervals where each interval can have it's own playlist or track played.

In iOS3 I had the problem that I couldn't disable the idle timer by just setting idleTimerDisabled = YES. In the end I came up with the same solution as Neil whereby I would periodically set it to NO, then immediately to YES again. This seemed to work.

I'm now updating the app to iOS4 (I know, iOS5 is just around the corner...) and now I have the opposite problem. If the MPMediaPlayer changes track before the idle timer reaches it's limit it gets reset. I've just tested this by creating an interval in my app that was 55 seconds, my auto-lock was set to a minute. At 50 seconds the screen dimmed as it prepared to lock, but at 55 seconds when the music changed it went back to full brightness and then didn't lock as it should.

Overall, the implementation of this seems flakey at best.

Brian Webster
  • 30,033
  • 48
  • 152
  • 225
Daniel Wood
  • 4,487
  • 3
  • 38
  • 36