I am able to register for UIApplicationDidBecomeActiveNotification and properly receive events. But sometimes I receive these notifications WHILE the app is still running. I suspected memory problems to trigger an app resign/resume but could not confirm this was the case (I saw once a memory warning at the same time). Any reason why these methods would be called while the app is running (no call, no lock, etc.)?
I am registering for these notifications:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(appDidBecomeActiveNotif:) name:UIApplicationDidBecomeActiveNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(appWillResignActiveNotif:) name:UIApplicationWillResignActiveNotification object:nil];
(This is done once in a singleton constructor using dispatch_once)
The corresponding functions:
-(void)appDidBecomeActiveNotif:(NSNotification*)notif
{
NSLog(#"appDidBecomeActiveNotif called");
}
-(void)appWillResignActiveNotif:(NSNotification*)notif
{
NSLog(#"appWillResignActiveNotif called");
}
Here are some logs:
2013-04-11 09:28:11.401 App[1499:907] appWillResignActiveNotif
2013-04-11 09:28:13.505 App[1499:907] appDidBecomeActiveNotif
This is what the docs says about those notifications:
UIApplicationDidBecomeActiveNotification
Posted when the application becomes active.
An application is active when it is receiving events. An active application can be said to have focus. It gains focus after being launched, loses focus when an overlay window pops up or when the device is locked, and gains focus when the device is unlocked.
UIApplicationWillResignActiveNotification
Posted when the application is no longer active and loses focus.
An application is active when it is receiving events. An active application can be said to have focus. It gains focus after being launched, loses focus when an overlay window pops up or when the device is locked, and gains focus when the device is unlocked.
So, are there any overlay window pop ups or are you locking the device or anything like that?
Also, why not use the methods in the AppDelegate to listen to those events?
EDIT
The problem, it seems, is MapKit's pop up asking the user to use it's location.
Related
I'm having a hard time handling interruptions in my OpenGL ES 2.0 iOS app. This really pertains to OpenAL, which I think I know how to handle, but the issue is that my interrupt handler never ends up being called. I've tried registering for notifications with:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(interruptionHandler:)
name:AVAudioSessionInterruptionNotification
object:nil];
among other methods (AVAudioPlayerDelegates etc.).
On the iOS Simulator, if a user swipes down to bring up the Notification Center, or swipes up to bring up the Control Center, and then gets back into the app, the OpenAL code needs to be reset because it stops working. But, how do I capture these two interruptions?
I am currently dealing with Smartcard reader connected to a IOS device as an external accessory. When application goes to the background and remains there for a few (let's say 10-15 seconds) the reader is disconnected by iOS in order not to drain battery. This sends notification to NSNotificationCenter that the reader (EAAccessory) has been disconnected. When app comes to the foreground, it usually takes some time till the reader is connected back.
I am able to handle with these notifications using following methods:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(EAaccessoryConnect) name:EAAccessoryDidConnectNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(EAaccessoryDisConnect) name:EAAccessoryDidDisconnectNotification object:nil];
The problem is, sometimes when application is in the background for a longer time (longer than 20 minutes), more than one EAAccessoryDidDisconnectNotification is obviously posted to the notification centre as well as EAAccessoryDidConnectNotification.
When I receive EAAccessoryDidDisconnectNotification I have to adequately handle it and allow some time till the EAAccessoryDidConnectNotification is received. However when another EAAccessoryDidDisconnectNotification comes, it messes up with my settings and the user is logged out from the application.
My question therefore is - is it possible to check which notifications have been sent to the NSNotificationCenter while app was in the background just after the app comes to the foreground, and remove multiple notification of the same kind - leaving only one notification of a kind. Or is there any other solution you suggest me to implement to deal with this?
just want to make sure i'm on the right path.
I'm creating a local notification as an alarm clock. when the user hits button... I want it to DO STUFF.
I'm thinking I have to call my method in
(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
.. .for when the application is closed
(void)applicationWillEnterForeground:(UIApplication *)application
... for when the application is in the background... when user hits okay
Is there a better way to do what I'm trying to accomplish... DO STUFF when user hits okay on notification?
thanks in advance
According to the documentation of local and push notifications, you should call application:didFinishLaunchingWithOptions: in both cases :
Handling Local and Remote Notifications
Let’s review the possible scenarios when the operating delivers a
local notification or a remote notification for an application.
The notification is delivered when the application isn’t running in the foreground.
In this case, the system presents the notification, displaying an alert, badging an icon, perhaps playing a sound.
As a result of the presented notification, the user taps the action button of the alert or taps (or clicks) the application icon.
If the action button is tapped (on a device running iOS), the system launches the application and the application calls its
delegate’s application:didFinishLaunchingWithOptions: method (if
implemented); it passes in the notification payload (for remote
notifications) or the local-notification object (for local
notifications).
If the application icon is tapped on a device running iOS, the application calls the same method, but furnishes no information about
the notification .
They can not be forced to call. only Monitoring.
UIApplicationDelegate Protocol
These methods provide you with information about key events in an
application’s execution such as when it finished launching, when it is
about to be terminated, when memory is low, and when important changes
occur. Implementing these methods gives you a chance to respond to
these system events and respond appropriately.
If you want you're ViewController get Notification there method. try this
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(applicationDidFinishLaunching:) UIApplicationDidFinishLaunchingNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(applicationEnterForeground:) name:UIApplicationWillEnterForegroundNotification object:nil];
- (void)applicationDidFinishLaunching:(NSNotification *)noti
{
//do stuff
}
- (void)applicationEnterForeground:(NSNotification *)noti
{
//do sutff
}
I have read over many stack overflow questions where people ask to terminate their app oppose to let it run in the background.
The main answer I found was to set the application does not run in background BOOL to YES in my info.plist
I have done this and cleaned my project but still my application runs in the background when the user presses the home button. This solution simply does not work.
What can I do to make my application quit when a user presses the home button.
My app is currently running on iOS 6.
Any help is appreciated :)
This answer is for your first comment, not the original question. Have your iPod view controller register for the UIApplicationDidEnterBackgroundNotification notification. The implementation should stop the music. This is a much better user experience than choosing to have your app terminate on suspend.
// Put this in a good place like viewDidLoad
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(backgrounding) name:UIApplicationDidEnterBackgroundNotification object:nil];
// Handle the notification
- (void)backgrounding {
// app is leaving the foreground, stop the music
}
// In your dealloc method add:
[[NSNotificationCenter defaultCenter] removeObserver:self name:UIApplicationDidEnterBackgroundNotification object:nil];
In the AppDelegate's didFinishLaunchingWithOptions:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(contextChanged:)
name:NSManagedObjectContextDidSaveNotification
object:nil];
This is so I can merge changes to the data from other threads.
Question: Do I need to bother removing this listener in applicationWillResignActive or applicationWillTerminate? It doesn't seem like there's a point. I guess I'm asking if it's normal to have listeners like this in the main loop that never get removed.
You can never remove it, but if your app receive a notification (it won't happen in this case) while it is in background the notification will be queued and delivered to the application when it comes up again (if the app isn't killed ofc).
If don't want notifications that happen when your app is in background to be delivered once it comes up you can remove the listener in the methods you pointed out.
In this case, actually, it doesn't matter.