Reputation: 3163
I've built a WatchKit app with a hierarchical structure that can receive actionable push notifications. When the notification comes in, the action is to push one particular interface controller so that the user can view it immediately without having to drill down through menus.
Apple's documentation on handleActionWithIdentifier:ForRemoteNotification:
states that this method is only called on the initial interface controller, so my code for handling the remote notification in the initial interface controller looks like this:
override func handleActionWithIdentifier(identifier: String?, forRemoteNotification remoteNotification: [NSObject : AnyObject]) {
if let notificationIdentifier = identifier {
if notificationIdentifier == "myActionIdentifier" {
pushControllerWithName("myActionController", context: nil)
}
}
}
However, the problem is, if the user was already viewing this myActionController previously and then had suspended my app, and then later this notification comes in and the action is taken, the app will push this same myActionController onto the stack again. Then when the user taps the "back" button, they'll just pop onto the previous myActionController, which will look the same. This problem stacks, as well - if the user receives multiple notifications of this type and takes the action on all of them, the myActionController will just start stacking up.
I'd like to remedy this problem by in handleActionWithIdentifier:forRemoteNotification:
checking what the current active interface controller is, and if it's already myActionController, don't do anything (because it will reload once willActivate:
is called on it anyway). I know this is possible (sometimes) in iOS, for example on a UINavigationController, but I don't know if it is possible in WatchKit. Does anyone have any ideas?
Upvotes: 3
Views: 1802
Reputation: 3347
I have almost the exact same scenario in my own WatchKit app, and I've handled it by tracking which view controller is currently being presented. In a simple version, you could track the name of the last view controller you've presented and clear it in the presenting controller's willActivate method (as it will be called when the presenting controller is re-displayed). If you received your notification while something is presented, you can then decide if you need to dismiss/pop the controller first.
It might be more than you want/need, but I've written a JBInterfaceController
subclass that wraps a lot of this functionality: https://github.com/mikeswanson/JBInterfaceController
Upvotes: 3