App Background issue While in Background - iphone

My app is checking some algorithm in the background, after something like 30 minutes
my application seems to be like close (iphone turn to sleep mode i think). I need the app
to run this algorithm as long as it is in the background.
Do you have any idea how to set this 20 minutes timer to recount by some action?
maybe NSRunloop or something else?

You can't reset this timer or continue to run in the background on a stock OS iPhone (except for a limited amount of time, or if your is legitimately of 3 types, VoIP, audio or GPS).
The user can reset this timer by bringing your app to the foreground, perhaps after a notification or something.

Related

iOS 5 deep sleep prevention

I'm trying to build an alarm app that can fire an alarm while in locked-screen mode (the app is in the foreground, but the screen is locked). The alarm has to be triggered by a NSTimer not by uilocalnotification.
In iOS 4 I used the 'play silent sound every 10 seconds' hack to prevent the app from going to deep sleep and the timer events worked fine. However, in iOS 5 this doesn't seem to work.
Any ideas? Or this should work and I'm doing something wrong?
It seems that you actually can use the 'play silent audio' hack in iOS 5, but the audio has to be audible meaning you can't play it at volume set to 0.0.
You can use github.com/marcop/iPhoneInsomnia and set the volume to greater than 0, but it still doesn't work because the sound file is so short that the system kills your application before the timer is triggered and replays the sound. I solved this by setting the numberOfLoops of the audioPlayer to -1 (infinite repeat). Then it should work.
And you should also set the UIBackgroundMode plist key to an array of one string called "audio"
It's probably a dirty workaround, but in the past I have used the proximity sensor to turn off the screen instead of locking the phone. Simply place the phone upside down and the screen will turn itself off.
[[UIDevice currentDevice] setProximityMonitoringEnabled:YES];
This will allow you to retain full control over the device, while the screen does turn off.

NSTimer doesn't work in sleep mode?

In my App, i have set the timer for 3, 10 and 15 mins,but it goes to sleep mode and the audio doesn't ring.And after a long time it starts vibrating.Please help me with this issue.
Thanks in advance.
To save battery and resources, not all apps can run in the background, so when the device goes to sleep, your app might not be killed, but it does stop executing.
You can use UILocalNotifications to play the sound you want even if your app is not running.
Timer does not work in deep sleep mode, but you can make app awake by applying idleTimerDisabled property to TRUE, but remember, if you use this, battery will be utilized more....

Multitasking: Stop Background Audio at Specific Time

I am developing an iphone app which uses background audio (on an infinite loop) to continue playing after the app has entered the background.
My problem is I want to implement a "sleep timer" which stops playback after a specified period of time.
Is this possible? I have spent an hour looking for a method to do this with no avail.
EDIT: My current thought is to use a lower level API, the Audio Queue Services, and manually re-fill the queue with another instance of the loop during the AudioQueueOutputCallback. If the timer has expired I do not fill the loop. I'm assuming this should work since the documentation says audio callbacks are still fired when an app is playing multitasking background audio. Can anyone think of a better way or a reason why this wouldn't work?
While you queue sound data on the background your app remains fully functional and running as if it was in the foreground (well almost), so yes, you should just write a timer that stops the playback at a given time and it will be fired as expected.
Now to the second question: once you stop queueing things up, your app will be "frozen" until the user manually brings it to the foreground... So what you should do is start queueing audio data from the second file before the first one is done playing, and if you DO need to pause or stop, maybe a solution is to play 0 bytes (silence)?
I'm not actually sure this would be allowed in the App Store. An app is not allowed to execute at all in the background, with the exception of VoIP apps and push notifications.

Iphone app is delayed for 10 -15 minutes when iphone is in sleep mode

I have created an app that uses NSTimer, which gets triggered each second.
My problem is that if the Iphone is in sleep mode i get a delay for 10 to 15
minutes before the event is triggered. I have stackoverflowed and googled this
and the reason for this seems to be that the phone stops listening for certain
events when in sleep mode.
Some people have solved this issue by playing a mute sound, not allowing the
phone to sleep.
What could be the reason for the delay?
The mute sound solution seems to be a very "dirty" one. Is there some other way to solve this?
If I use the mute sound solution will it the pass the apple review?
Code:
timer = [NSTimer timerWithTimeInterval:1.0f target:self selector:#selector(goAction)userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
-(void)goAction {
// Here i check for some dates and then call the activateBeepAlarmView
}
Well since no one has answered my three questions I will have to answer them:
1. What could be the reason for the delay?
I will have to quote Ben S:
Once applicationWillResignActive gets called on your application you simply stop receiving events:
The delegate can implement this method to make adjustments when the application transitions from an active state to an inactive state. When an application is inactive, it is executing but is not dispatching incoming events. This occurs when an overlay window pops up or when the device is locked.
The point of sleep mode is to save energy. To do so, the device stops listening for events like the ones you're asking for. NSTimer events will still fire since they don't require expensive (battery-wise) hardware monitoring. Also, alarms are implemented using NSTimer, so they need to be able to function even when in sleep. Otherwise, people might not wake up and blame their iPhone.
2. The mute sound solution seems to be a very "dirty" one. Is there some other way to solve this?
No, currently I haven't found another solution, please feel free to correct me if I'm wrong.
Check out this blog post how to do it.
3. If I use the mute sound solution will it the pass the apple review?
Yes
When the iPhone goes to sleep, so does your app and the runloop that runs the NSTimer.
You seem to think that an NSTimer is some sort of hardware based timer. It is not. It operates completely within the software of the app that launches it. I don't know what is waking your app up but it is definitely not the NSTimer.
In short, what you want to do is impossible. You can't sleep the phone and then have an app still active and running. The mute sound technique is just a kludge to keep the phone awake and the app running.
If you need the phone to stay awake, you need to set the application's idleTimerDisabled to YES. This will prevent the phone from sleeping and the app can remain active. But once you let the phone sleep, it cannot be awaken from app code. Only the hardware can do that in response to an alarm or an incoming message.
What happens in your app when the NSTimer is triggered each second? Please provide code showing the creation of the timer as well as the code for the selector that is called when the timer completes.
Also what do you mean by a "delay for 10 to 15 minutes"? Is the delay always that long or is that how long you wait to awaken the iPhone and then the event is triggered?
Depending on what you need to do every second you can handle this situation in different ways. Please respond and we'll try to work our way through this.
Bart
#Jakob,
This is impossible with the "Official SDK". If you're developing apps for jail broken phone, then you can use IOKit framework for this. For more info please refer this.

idleTimerDisabled not working since iPhone 3.0

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.