iPhone - Differentiate UIApplicationDidBecomeActiveNotification notifications - iphone

When registering the UIApplicationDidEnterBackgroundNotification, I notice that this notification is not triggered when the device enters in sleep mode.
But, when waking it up, the UIApplicationDidBecomeActiveNotification notification is triggered. It is also triggered when coming back from background mode.
So how can I know if my application comes back from background mode, or is activated following a wake up of the device ?

Those don't balance each other; they are posted for unrelated events. I believe you want UIApplicationWillEnterForegroundNotification when detecting your app coming back from the background, and UIApplicationWillResignActiveNotification when detecting certain other situations (including sleep.)
Note that UIApplicationWillResignActiveNotification also shows for events such as "incoming phone call was ignored" and "the operating system displayed an alert that is not part of your process" (e.g. a text message.)

Related

can we get iPhone earphone jack plugged in/out event while application is running in background?

I want to perform some event when user plugged in/out earphone in iPhone only application is running in background. Simply explanation, I am running music player in background with earphone plugged in, now after some time I am removing earphone (plugged out), at that time I want to show alert "Earphone Plugged Out".
In foreground, we can get this event, that I researched and got, but if we are running the application in background can we get this plugged in /out event?
You are not able to get event in background while if you app is active, you will get notification. please look on apple docs for more detail.
thanks
Yes you should be able to due that, since you have the AudioSession running for backgeround mode you will recieve the jack unplug notification.
But You can't show a UIAlertView you will have to scheudule a UILocalNotification with the current date as firedate. How ever I as an user will find it very anyoing if an app fires an notification to alert me of an action I performed.

Is a Timer disabled automatically when app resigns active on the iphone?

Playing around with Timers, and trying to make them behave right when app is sent to background, killed etc.
Judging by the generated comments in xcode, you should disable/invalidate timers on resignActive/enterBackground events.
However, i havent done that yet, but checked what happens to my timer when i click the home button and then re-enter the app.
I basically have a method in my view that the timer triggers every second:
NSLog(#"workedTimTimerTick workedTime; %#", timeString);
And when i exit the app, the output stops, when i re-enter the app, the output starts again...
Since i'm not doing anything code-wise to the timer on those lifecycle events, how come it stops getting called?
Input appreciated!
Your app is suspended when it enters background mode (Application States and Transitions).
Your timer won't fire when the app is in background and the time spent in background isn't taken into account for the timer delay.

Differentiate if the app became inactive because the home button being pressed or an incomming phone call

I know that whenever the app becomes inactive, the UIApplicationWillResignActiveNotification local notification will be posted. In the opposite suituation, the UIApplicationDidBecomeActiveNotification notification will be posted.
A client want the app to act differently according to the interruption, he wants the app to close when the home button but to remain active if the user receives a phone call. It doesn't seem to be possible, I'm correct ?. If It's possible how can I do It ?
Edit: I know how to close my app whenever an interruption is received , my question is if it's possible to differentiate if the cause of the interruption was the home button being pressed or an incomming phone call, so my app responds differently in each case.
Using CTCallCenter notifications allows you to differentiate between incoming call or send-to-background using Home or multitasking tray reasonably reliably.
If you want the app to quit when the home button is pressed, you should set the UIApplicationExitsOnSuspend key to YES in the app's Info.plist file. If you edit the plist in Xcode, this key is displayed as Application does not run in background.
Then you can handle all of your termination in response to the UIApplicationWillTerminateNotification notification (or equivalently, in the appDelegate's applicationWillTerminate: method.
More information here: http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html

Receiving Notifications with App in background mode

I have an app, that will keep track of everything the user do in the iPod app. To do this, I added few observers to NSNotificationCenter, like MPMusicPlayerControllerNowPlayingItemDidChangeNotification. But my problem is, I only get those notifications when my app is in the foreground, if its in the background, the system add the notification to a queue, and then the next time my app becomes active it delivers it to me. I have no interest in this queue, since I want to receive real-time notifications.
Is there any way for me to get those notifications even if my app is in suspended state? I want to run just 3 lines of code everytime I get this NowPlayingItemDidChange notifications for example.
Here is where I add the observer.
MPMusicPlayerController *iPodMediaPlayer = [MPMusicPlayerController iPodMusicPlayer];
NSNotificationCenter *notificationCenter = [NSNotificationCenter defaultCenter];
[notificationCenter addObserver: self selector: #selector(handle_NowPlayingItemChanged:) name:MPMusicPlayerControllerNowPlayingItemDidChangeNotification
object:iPodMediaPlayer];
[iPodMediaPlayer beginGeneratingPlaybackNotifications];
Also, if I add another kind of object to the observer instead of iPodMediaPlayer, the observer won't call the method.
Thanks a lot,
Abras
iOS applications are suspended when they are not in the foreground. There are three exceptions to this rule. You can have code execute in the background if your application is
a) Playing audio. This means the application itself is actually generating audio. My understanding is that the MPMediaPlayerController iPodMusicPlayer object only controls the playback of the external iPod process, rather than playing audio from the app itself. Perhaps you could have some success if you called applicationMusicPlayer instead of iPodMusicPlayer and set the appropriate background flags in your applications Info.plist. This seems like the most legitimate way to get your application to work, but you wouldn't be able to control iPod playback from the iPod app, only your app and the system audio controls.
b) Get your app to monitor the location. If the app is using the GPS it can continue to execute in the background. Downside to this is that the GPS will drain battery, and users might be creeped out that you're requesting their location.
c) Ask UIApplication for extra time. If you use UIApplication's beginBackgroundTask method, your application will continue to run for a finite amount of time in the background. If your users are going to come into your application once every ten minutes or so, this could work as well.
Hope that helps.
Multitasking in iOS is currently a very restricted one. You may start a background task using beginBackgroundTaskWithExpirationHandler: method (of an UIApplication object), but it is intended to finish a finite-length task before going suspended. All background tasks may expire (and get terminated) before it finishes its job. You can check how much longer your application can run by checking backgroundTimeRemaining property of the application object.
As I explained here iOS receive Media Player Notifications when app is in background, there seems no way to get notifications from iPodMusicPlayer.
About Omar Raul Qazi answer:
a) i tried and I had no success. The music kept going down when pressing home button. I think this background flag only works for normal AudioSessions and not for MPMusicPlayer...
b) I am not sure this would work and I don't think Apple would like it when looking for approval
c) You can run in background only synchronous task. You cannot wait there for a notification. Am I wrong?

App not playing sound when screen turned off, but doing everything else as it should?

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.