I'm trying to use the new Mountain Lion NSUserNotificationCenter for my application (which isn't too hard actually). Posting notifications works like a charm via
NSUserNotification *userNotification = [[NSUserNotification alloc] init];
userNotification.title = #"Some title";
userNotification.informativeText = #"Some text";
[[NSUserNotificationCenter defaultUserNotificationCenter] deliverNotification:userNotification];
However, i'd like to dismiss all notifications that are on the screen once the app gains focus. E.g. like the new Messages app does it. When new messages are received in the background, notifications are shown. When the app becomes active again, these are dismissed automatically and vanish from the screen and from the Notification Center.
To replicate this, I've registered a method to the NSApplicationDidBecomeActiveNotification notification which also gets called succesfully. In there I call [NSUserNotificationCenter defaultUserNotificationCenter] removeAllDeliveredNotifications].
This, however, has the effect that notifications that have been collected in the Notification Center are removed while the corresponding "bubbles" that are displayed in the top right corner are still displayed.
Iterating all delivered notifications and removing them each on their own has the exactly same effect, as has using scheduleNotification instead of deliverNotification.
Am I the only one experiencing this, or am I missing something to dismiss the on-screen part and the Notification Center part of a notification programatically?
The Messages app is probably using the private NSUserNotificationCenter _removeAllDisplayedNotifications or _removeDisplayedNotification: method.
You can try to use these methods to test if this is what you are looking for. Just add this category interface to declare the methods:
#interface NSUserNotificationCenter (Private)
- (void)_removeAllDisplayedNotifications;
- (void)_removeDisplayedNotification:(NSUserNotification *)notification;
#end
Unfortunately, since these are undocumented methods, you can not use them in an app distributed through the App Store. If this is indeed what you are looking for, then you should file a bug and ask for these methods to become part of the public API.
As of 10.9, the following methods remove any displayed notifications:
// Clear a delivered notification from the notification center. If the
// notification is not in the delivered list, nothing happens.
- (void)removeDeliveredNotification:(NSUserNotification *)notification;
// Clear all delivered notifications for this application from the
// notification center.
- (void)removeAllDeliveredNotifications;
The behavior seems to have changed since 10.8, as any displayed notifications are removed as well when these methods are called (thanks #0xced for clarification).
removeDeliveredNotification is removing the displayed notification for me (on 10.11), the caveat being the identifier on the notification must be set.
Related
I'm in a bit of a pickle here. I have an app written for ios7.1 and we are now trying to make the same app support ios 8.1.
In this app we have several popovers. I've gone through the fix of having them show up properly as a popover in iOS8 but when I click on the popover it doesn't respond as expected.
Here's how it is being presented (all hooked up in storyboard):
in DashboardViewController:
if ([segue.identifier isEqualToString:#"showRHSMenu"]) {
_rightNavController = segue.destinationViewController;
_rightNavController.preferredContentSize = CGSizeMake(220, (_rightNavController.tableView.rowHeight * _rightNavController.dataArray.count));
_rightNavController.modalPresentationStyle = UIModalPresentationPopover;
UIPopoverPresentationController *popoverPresentationController = _rightNavController.popoverPresentationController;
popoverPresentationController.delegate = self;
}
in _rightNavController, a protocol is declared to communicate with DashboardViewController. this works and gets executed in ios7.1 using UIPopoverController but in iOS8.1 using UIPopoverPresentationController, it does not trigger.
I have confirmed that the user clicks register in the rightNavController but the protocol/delegate is not being executed.
Can anyone help please?
An old question, but hopefully this helps someone else.
I ran into the same problem today, and the solution was to declare the popover controller as an instance variable rather than a local variable. As a local variable, it gets garbage collected any time after the method returns, regardless of whether the popover view is still on screen. (Garbage collection seems to be a lot more aggressive/efficient in iOS8, so likely just exposed a bug that you already had.) Keep a handle to the view controller until the view is dismissed, and all the delegate methods should work fine.
I'm trying to implement Game Center invites in a 2-person realtime game. Since invites are not supported in the simulator, I'm testing this on one device running iOS5 and a second one running iOS6 (this is done on purpose).
If I'm using the old-fashioned built-in GKMatchmakerViewController UI on either device to initiate the invite, it works fine both ways - when the iOS5 device initiates the invite as well as when the iOS6 device initiates it.
However, in iOS6 I want to use my own UI to select the player to invite, so I'm using GKMatchRequest to programmatically issue the invite, setting the playersToInvite attribute.
The problem is, the other (iOS5) device gets the push notification, launches the application, runs the [GKMatchmaker sharedMatchmaker].inviteHandler, shows the Game Center UI with the invite details, but even when the iOS6 device sends a finishMatchmakingForMatch request - the iOS5 device doesn't proceed any further. No other handler / delegate is called on the iOS5 machine, no GKMatch object is returned, and it continues to show the Game Center UI with both players marked as "Ready" and with a message saying "Waiting for [iOS6 player] to start the game". The only button on this UI is a Cancel button.
Here's the code snippet that sends the invitation on the iOS6 machine:
GKMatchRequest *request = [[[GKMatchRequest alloc] init] autorelease];
request.minPlayers = 2;
request.maxPlayers = 2;
request.playersToInvite = [NSArray arrayWithObject:playerID];
request.inviteMessage = message;
request.inviteeResponseHandler = ^(NSString *playerID, GKInviteeResponse response)
{
if (response == GKInviteeResponseAccepted)
[[GKMatchmaker sharedMatchmaker] finishMatchmakingForMatch:self.match];
};
[[GKMatchmaker sharedMatchmaker] findMatchForRequest:request withCompletionHandler:^(GKMatch *match, NSError *error)
{
... [whatever]
}];
And here's the code snippet for the invite handler on the iOS5 machine:
[GKMatchmaker sharedMatchmaker].inviteHandler = ^(GKInvite *acceptedInvite, NSArray *playersToInvite)
{
if (acceptedInvite)
{
GKMatchmakerViewController *mmvc = [[[GKMatchmakerViewController alloc] initWithInvite:acceptedInvite] autorelease];
mmvc.matchmakerDelegate = self;
[navController presentModalViewController:mmvc animated:YES];
});
else if (playersToInvite)
{
... [whatever]
}
}
The sequence is as follows:
iOS6 sends a findMatchForRequest request with the iOS5 player id.
A push notification is shown on the iOS5 machine.
The application is launched on the iOS5 machine and the inviteHandler is called.
The GKMatchmakerViewController is shown on the iOS5 machine with the invite details, and the iOS6 user has a spinning "Connecting" status.
The inviteeResponseHandler on the iOS6 machine is called and sends a finishMatchmakingForMatch request.
The status of the iOS6 user in the iOS5 Game Center screen changes from spinning "Connecting" to "Ready", and at this point both players are marked as "Ready".
The iOS6 machine gets a match: player: didChangeState: callback, showing the iOS5 player as GKPlayerStateConnected, so as far as the iOS6 machine is concerned the match process is finished and the game can begin.
Nothing whatsoever happens from now on on the iOS5 machine. It is stuck with "Waiting for [iOS6 user] to start the game" until it is cancelled by a timeout. It never receives any GKMatch object at any point, so it cannot start the game.
Since things work fine if I use the standard Game Center UI on the iOS6 machine rather than a programmable invite, it means that the standard UI must do something more to tell the other machine that the game has to start. However, I browsed through all the relevant Game Center objects and couldn't find anything else to send.
I should mention again that the reverse configuration (iOS5 initiating the invite using the standard UI) works fine on both machines.
Help, anyone?
I am having a similar problem. One of the things I did to partially solve is to use programmatic for ios6 users, and viewController for ios5 users. I think you are doing that too but your inviteHandler code only seems to have viewController code. Were you able to fully solve your issue?
Hmmm……
A question about UILocalNotification and the notificaton's alertLaunchImage.
My app uses UILocalNotifiaction(s) to get users' attention. As usual, an alert is presented with "Action" and "Close" buttons. When the user taps Action, the image specified by alertLaunchImage is presented. The alertLaunchImage is a screenshot of of one of the views of the app which is shown after the data is initialized when launched normally.
Here are the 3 cases when the notification is delivered:
App is running in foreground - no alert, no launchImage is shown as designed. No problems.
If my app is running in background when the notification is delivered, the launchImage works like a charm. No problems. The launchImage with no app-related data is shown and then the app fills up the data. This part works seamlessly.
However, if the app is not running when the notification is delivered, the sequence is confusing - or I missed something. The app gets launched and shows the alertLaunchImage instead of the Default image. Then is goes thru several other screens (as part of initialization and data processing) before the actual screen (live version of alertLaunchImage) is shown.
This can get very confusing to the user. My question comes in here. How can this be avoided?
R/-
Sam.!
you can try cleaning up the alert view settings in applicationWillTerminate:
According to the UIApplicationDelegate reference applicationWillTerminate::
"This method lets your application know
that it is about to be terminated and
purged from memory entirely. You
should use this method to perform any
final clean-up tasks for your
application, such as freeing shared
resources, saving user data,
invalidating timers, and storing
enough application state to
reconstitute your application’s
interface when it is relaunched"
HTH,
Oded
If your app is launched by a local notification, you will receive that notification in the options passed to -application:didFinishLaunchingWithOptions:. Based on that, you can write code that navigates to the correct screen without animations.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
UILocalNotification *localNotification = [launchOptions valueForKey:UIApplicationLaunchOptionsLocalNotificationKey];
if (localNotification != nil) {
// startup by local notification
} else {
// normal startup
}
}
I'm extending Appirater (a stand alone class that presents an UIAlertView to the user to solicit a rating for your app) by adding a single button that when selected will dismiss the alert, and bring up MFMailComposerViewController so the user can email feedback.
My implementation was/is to post a notification in Appirater, and then using [self presentModalViewController: vc animated: YES] from a viewController that listens for the notification. That viewController is the super class of all my main viewControllers.
It works in one of the main viewControllers is up, but crash's from within other viewControllers are the current viewController and I see the following warning in the console:
2010-12-17 11:27:59.632
Wine.com[18514:207] * Terminating
app due to uncaught exception
'NSInternalInconsistencyException',
reason: 'Attempting to begin a modal
transition from to
while a transition is
already in progress. Wait for
viewDidAppear/viewDidDisappear to know
the current transition has completed'
I tried delaying the sending of the notification from Appirater, but that does not seem to help.
Ideas/pointers?
I had a similar error when clicking on a UIButton to open a Modal View. I changed the UIButton's listener from UIControlEventAllEvents to UIControlEventTouchUpInside. Basically, it was firing the Modal View on Touch Down Inside and then trying to create another instance of the Modal View on Touch Up Inside.
The problem was that by implementing this in a superclass, I needed to make sure only the currently active viewController was processing the notification, not ALL 5 of them.
What method must I implement in my cocoa application’s delegate so that on launch, it’ll open a url? (http/https, in this case) I’ve already implemented the url schemes, I just need to know how I can get my application to open on a url notification.
Update: I’m sorry, I wasn’t very clear. My application IS a browser that support https/http urls, but can only open them when it’s already running. What can I do to implement support for open urls in my app on launch?
When an application finishes launching on OS X, NSApp (the global NSApplication instance for the program) sends its delegate the applicationDidFinishLaunching: message (via the notification system). You can implement that method in your delegate to handle the notification and open a browser window in response, using NSWorkspace. Something like the following would work:
// Your NSApp delegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
[[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:#"http://www.example.com/"]];
}
It's not a delegate method. You need to implement an Apple Event handler for the getURL event.
As luck would have it, this is exactly the case Apple uses to demonstrate implementing an Apple Event handler.
I already had implemented the getURL event, so that alone isn’t enough to get the application to open a url on launch. The trick is that the AppleEvent must be installed in applicationWillFinishLaunching: not applicationDidFinishLaunching:. Otherwise, the event isn’t sent at all because the app hasn’t registered it in time.
To implement a protocol handler that you can select (in Safari preferences, for example) as the "default browser" and which will launch in response to HTTP / HTTPS, you need to do a few things.
Add .scriptSuite and .scriptTerminology files to your project resources. These will tell Mac OS X that you'll be handling the GetURL command.
Add a CFBundleURLTypes key to your Info.plist file listing the "URL Schemes" that your app will handle.
Also in Info.plist, add the NSAppleScriptEnabled key with the value YES.
Add a new class to your application as a subclass of NSScriptCommand and implement the -(id)performDefaultImplementation selector. From within this function you will find the clicked URL in [self directParameter]. Pass this on to your app's URL handler!
For the full details check out the article:
http://www.xmldatabases.org/WK/blog/1154_Handling_URL_schemes_in_Cocoa.item