I have developed an iPhone app which gets the microphone recorder inputs every second using NSTimer, calculate the amplitude of sound, and take appropriate action if required. I have noticed that when my iPhone gets locked, my application stops running(it doesn't fire the timer callback function). When I unlock iPhone, it start automatically. Could anyone please tell me how can I allow application responding when iPhone gets locked? Is there any other way around such that iPhone shouldn't get locked when my application is running? What should be Apple's recomendation on this?
I found this article but not sure it is correct way to do.
Thanks.
You cannot prevent timer from being stopped when application goes into idle state. Only one possible way is to disable idleTimer of the application.
application.idleTimerDisabled = TRUE;
//or
//Disable screen dimming if no user input occur on device.
[[UIApplication sharedApplication] setIdleTimerDisabled:YES];
Related
When press the lock button in app,system will call :
-(void) applicationWillResignActive:(UIApplication *)application and
-(void) applicationDidEnterBackground:(UIApplication *)application
So how can I do to make my app only resignActive but not enter background,and I can run my timer when screen locked(Timer can't execute in background mode).
One method is set the property "Application does not run in background" in .plist to YES,it worked, but my app can never enter background again,however I want it will enter background when press the home button.
Update: I want to play some music in my app at a certain time,just like a music alarm,and I still want it works fine when the screen locked,because keep the screen on may waste a lot of battery,and I don't need to do any thing when user press the home button and exit my app.
Open your Info.plist file and add Application does not run in background. Set value to YES.
Application must have special privileges to do any processing in background such as Audio service/Voip service/Location service.
"I can run my timer when screen locked(Timer can't execute in background mode)"
you cannot run a timer in background which will keep running without using any tentrum and doing so...apple will not accept your application on appstore - that's the worst side if you are targeting appstore...
You can not prevent your app from entering the background. This is decided by the operating system (iOS) and is out of control from applications. However, from reading your updated question, I don't think this is what you need to do.
You can execute background tasks with [UIApplication beginBackgroundTaskWithExpirationHandler;] (see reference). If you want to have something happening after a certain interval, check out [UIApplication scheduleLocalNotification:].
Some services such as VOIP, Audio and CoreLocation are allowed to run in background. Using these for other than their intended purposes (for example, playing silent audio) may risk your app being rejected.
Note that there is nothing you can do to prevent your application from entering the background. It is just that some tasks are allowed to execute in the background. Because of this, you cannot do GUI operations and NSTimers will probably not fire (at least I know some cases where they don't).
It would help knowing what you want to run in the background in order to suggest a solution.
Unless you are playing audio BEFORE the move to background you cannot start audio playback when the app is moved to the background or the screen is locked (which has some weird specifics) suffice to say, its as if you were in the background without actually receiving the applicationDidEnterBackground notification.
The best you can do is schedule a local notification, but in this case your music is limited to 30 seconds and must be part of your application bundle.
My iPhone application has two states: UI and Game.
Game is played using device tilting only so I switched auto-sleep off on game start:
[[UIApplication sharedApplication].idleTimerDisabled = TRUE;
But as soon as I return to UI, I want auto-sleep to be active again. So on game finish I restore it:
[[UIApplication sharedApplication].idleTimerDisabled = FALSE;
After a long game playing, it resulted in immediate darkening of the first UI screen that I go after the game.
So it seems that when idle timer was disabled it was still calculating time. And it had fired immediately after "enabling". How can I fix this problem?
I don't know if the idleTimer can be reset programmatically, but an option is to require the user to touch the screen before it goes back.
Another option is set your own timeout once you are back and wait for it to complete before you set idleTimerDisabled = NO. Remember to clear this timeout if you start the game again.
This answer may be usefull.
I also had problems when using Music/Audio players, which seemed to reactivate the timer.
ps: in ObjectiveC you should use YES/NO instead of FALSE/TRUE
I have an alarm clock app which works on a timer. When the alarm is meant to go off and the screen is switched off, it should start playing audio from AVAudioPlayer, but it doesn't. Then when i turn the screen back on, i can see that the rest of the code fired as expected (a stop button is now on the screen). How do i get the AVAudioPlayer to play when the screen is turned off?
Is there any way for me to detect that the screen is turned off?
#zoul is correct that using the default audio session category will result in sound form your app being disabled when the user locks the screen. See the Audio Session Programming Guide for direction on which audio session category you should choose.
However, even once your audio session category is set correctly, you'll have another issue to tackle. When the screen is switched off, your application gets suspended per Apple's documentation here: Executing Code in the Background. This means that when the user locks their phone or switches to a different app, your app will stop running and stay in a freeze-dried (task-suspended) state until the user activates your app again. At that point, your app resumes execution as if nothing happened. That's why it appears that your app has continued to function when you unlock the screen.
For alarm behavior, you'll probably want to schedule the delivery of a local notification. A local notification will ensure that the system provides your alert to the user at the time you request, and allows the user to activate your app. See Scheduling the Delivery of Local Notifications for details on how to accomplish this.
Maybe you have the wrong audio category? See the documentation for AVAudioSession, especially the audio category settings.
I'm making a Web app (at chirpid.com) for the iPhone that plays audio files for cricket chirp identification. The user can start and stop the audio by tapping screen buttons. But if the user taps the home button while a sound file is playing, it continues to play in the background (an iOS4 feature). I want to stop the audio in this case. Is there an event or property that I can use via Javascript in Safari to determine when I have been put into the background?
You could manually trigger the "stop" button like this when closing the application.
- (void)applicationDidEnterBackground:(UIApplication *)application {
if(audioIsPlaying) {
[btnStop sendActionsForControlEvents:UIControlEventTouchUpInside];
}
}
You get 5 seconds to do anything when using the applicationDidEnterBackground: function.
That should be enough to stop the audio ;-).
I would guess you need to create a listener that listens to system events...
Perhaps you should read this book: http://books.google.com/books?id=a09NMFdA6m0C&pg=PA94&lpg=PA94&dq=iOS+home+button+event+javascript&source=bl&ots=4Nop45gmwI&sig=8mTEGQI1ym65H7XjmBSzRQ2KyMc&hl=en&ei=_qDWTrmMDsPh4QSR9I2rAQ&sa=X&oi=book_result&ct=result&resnum=6&ved=0CEsQ6AEwBQ#v=onepage&q=iOS%20home%20button%20event%20javascript&f=false
iOS4 has some kind of lock function you can assign to buttons, perhaps you could tie in a script to turn down volume that way.
If you found the solution be nice and post it here for others to see.
Best of luck!
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...
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.
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];
}
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.
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.
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.