I'm using both NSWorkspaceDidActivateApplicationNotification and NSWorkspaceDidLaunchApplicationNotification notifications to know which app the user is interacting with.
The problem is that, if an application is just opened and still launching, I first receive a activate notification, and soon afterwards a launch notification.
Is there any way to know within the activate method that the app is still launching and not yet ready for use? (Still bouncing in the dock)
I see that the ichat sample project by apple does not use the above approach and instead only listens to launch notifications. It then uses kAXApplicationActivatedNotification to add an AXObserver to the app. Is this the preferred way? (And also NSRunningApplications to add an observer to all already loaded apps).
I wanted to keep using just plain simple NSNotifications because I think it may be less memory intensive. (No need to keep an observer around for each and every app loaded).
check the NSRunningApplication object passed in the userinfo of the NSWorkspaceDidActivateApplicationNotification
NSRunningApplication *app = [note.userInfo objectForKey:NSWorkspaceApplicationKey];
if(app.isFinishedLaunching)
NSLog(#"up");
Related
Please note that I am referring to macOS, and to scheduled local notifications. I want for the application to be able to handle when the notification is presented, not when the user actually taps the notification.
UNUserNotificationCenterDelegate has methods for handling a notification when the app is in the foreground:
https://developer.apple.com/documentation/usernotifications/unusernotificationcenterdelegate/1649518-usernotificationcenter?language=objc
However it appears there is no way to handle one that is presented when the application is in the background
Any ideas on how to do this?
I am using Local notification in my application.it is working fine in foreground and background.
Now, What i need,if i remove my app from background then i want to cancel all notification
before that.
so , there are not any method are calling in appdelegate when i am going to remove my app from background, obviously it is going to Suspended state so no method is going to called.
so is there any other way to do this ?
Thanks in advance...
Considering your app is not one of the supported background execution modes, like audio, VoIP, or navigation,
Your app will generally never see willTerminate, because the system generally only terminates your app once it's already suspended (in the background). Once your app is suspended, it gets no further chance to act, so there's no callback for that.
The didEnterBackground delegate message or notification should be considered your last chance to clean things up or save state before possible termination.
Here and here are good overview of the application lifecycle notifications & delegate messages on iOS 4.0 and later.
Does anyone have any insights into when/under what conditions applicationWillTerminate is called in iOS 5/6?
I've got some logic i'd like to execute whenever the application terminates (not moves to the background), for example if the user navigates to the application bar at the bottom of the screen by double tapping the home button and force quits the app.
when i try to do this on a test device, applicationWillTerminate does not seem to get called. Is there a reason for this?
My plan B is to tie that logic to some persistent object like a singleton or a static that is automatically destroyed when the app quits.
Any suggestions?
thanks
Have you read the documentation for applicationWillTerminate:,
It says,
For applications that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the application. For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
There is a "maybe" mentioned there. Probably that answers your question. So it is not necessary that this will get called when you quit the app. Probably you might have to use UIApplicationExitsOnSuspend to disable multitasking and then it might get called while putting in background. But that again depends on your app requirement. If you cannot disable multitasking, you might have consider doing that in applicationDidEnterBackground method or so. I am not sure if there are any other delegate methods which will help in identifying the force quit.
In iOS one can purportedly use the CLLocationManager's startMonitoringForRegion: method to register a delegate to respond to the device moving into a specific geographic region, even when the app isn't launched. From the CLLocationManager Class Reference:
In iOS, the regions you register with the location manager persist between launches of your application. If a region crossing occurs while your iOS app is not running, the system automatically wakes it up (or relaunches it) in the background so that it can process the event. When relaunched, all of the regions you configured previously are made available in the monitoredRegions property of any location manager objects you create.
I assume if the app is relaunched, iOS doesn't actually bring it to the foreground. I couldn't find any good samples illustrating where startMonitoringForRegion fits into an overall application, so my questions are:
Does one have to register the delegate for startMonitoringForRegion from somewhere specific? I'm guessing it can't be plonked in a view controller if we're launching the app without bringing it into the foreground. Can someone give an example with some context around it?
If we decide we do want to bring the app into the foreground as a result of entering the region, how would we do so?
When is startMonitoringForRegion registered with the OS and when is it unregistered? Does the user have to have launched the app at least once (even if it's since been killed) for the initial registration to take place? What about if the user powers off the device? Will our handler be registered the next time the device is powered on, or will the user have to launch the app at least once again?
Does one have to register the delegate for startMonitoringForRegion from somewhere specific? I'm guessing it can't be plonked in a view controller if we're launching the app without bringing it into the foreground.
False. A view controller object still does exists if it's allocated-initialized, even if its contents are not presented.
If we decide we do want to bring the app into the foreground as a result of entering the region, how would we do so?
Not possible using public APIs (I'm not sure whether an app in the background can use - [UIApplication openURL:] with its own URL scheme to bring itself into the background, but I doubt it); however you may be able to use the SpringBoardServices framework to launch your app:
SBSLaunchApplicationWithIdentifier(CFSTR("com.mycompany.theBestiPhoneAppEver"), false);
When is startMonitoringForRegion registered with the OS and when is it unregistered? Does the user have to have launched the app at least once (even if it's since been killed) for the initial registration to take place?
If the user never runs your application, code inside will never be run, so it won't get registered.
What about if the user powers off the device? Will our handler be registered the next time the device is powered on, or will the user have to launch the app at least once again?
Now that's a good question. I don't know it off the top of my head, nor did I find an answer in the documentation (probably you haven't found that either), so I'd say you just better try it yourself to be sure.
I'm using Apple's view controllers quite alot in my app (like MFMessageComposeViewController and ABPeoplePickerNavigationController). So when I receive a notification (Local or Remote notification) how would I deal with it the most elegant way since I can not interact (send messages) to Apple's view controllers.
My assumption is that if the user is actively using the app and in i.e MFMessageComposeViewController he does not want to get disturbed/interrupted with what he is doing. But if it was me I would get a bit confused if I was doing something and I would hear boing sound (from the notification) and then nothing more happened.
So would a reasonable way to handle this do let the user finish doing his task in whatever Apple view controller he is inside and then display the notification for the user?
Or dismiss the Apple view controller and handle the notifaction and then put the user back in the Apple view controller?
I'm not quite sure I understood you exactly correct, but to me it sound like you want to do something like this:
If the user is composing a message in your app and there is an incoming notification, lets say a push notification from the facebook app, you want to handle this event somehow in your app by letting your MFMessageComposerViewController do something.
As answer to this request I would like to state the following:
You should be able to send messages to your MFMessageComposerViewController if you extend this class (i.e. create a class called MyMessageComposerController and let it extend the standard controller, and do whatever you need there)
However, you can't really do anything about the push notification, it comes from another app and this functionality is built into iOS, you can not make the push arrive later when the user is finished typing, it will always arrive and the user will always be the one to decide if he/she should keep typing or look at the notification. The only thing you can do is to make sure that your app saves everything that the user has typed so that he/she can continue typing when returning to your app.
Assuming you don't just want to display an AlertView or something similarly modal over the message composer, I would do something like the following:
assign a MFMessageComposeViewControllerDelegate to the composer.
show the composer as usual.
queue/remember the notifications received while the composer is in play (through the normal application:didReceive{Local|Remote}Notification: messages)
when the composer is closed, the delegate receives its messageComposeViewController:didFinishWithResult: message.
Do... whatever... with the stored/queued notifications.
Whether you delay responding to the notification until the user is finished with the composition or interrupt them is a trickier situation. If it's a relatively unimportant notification or notifications that are frequent, I'd tend towards the queue/delay approach. But for "important" notifications, I'd have no problems in interrupting the user. Of course, that just moves the question to what determines importance. And that is very much dependent on the app.