iOS: UIMenuController

File this one under: For my own future reference.

UIMenuController was introduced as public API in iOS 3.0 (along with UIPasteboard and Copy and Paste functionality). This is now a technology we take for granted in the iOS world, but it really wasn’t that long ago that Apple hadn’t provided this seemingly basic service.

Recently I was using this API in DeepDish GigBook to update some fairly crufty workflow. I am not going to explain how to use UIMenuController, as the documentation is fairly straight forward. What I will mention is a few “gotchas”.

1. There is no target for an UIMenuItem.

It is whomever is the First Responder. In other words, your controller class probably (in most cases) is what will handle the actions, so you want to make sure it can become the first responder. Add the following to your controller implementation:

- (BOOL)canBecomeFirstReponder
{
    return YES;
}

IF you don’t do this, then passing the message -setMenuVisible:animated: to the UIMenuController will have no effect.

2. Implement - (BOOL)canPerformAction:(SEL) sender:(id) in your controller:

There is little reason not to, and many reason why you should. This will be implemented in the same controller that also implemented -canBecomeFirstResponder. This will allow you to enable or disable (effectively hiding) any menu options you may or may not want at any particular time. It avoids having to recreate the menu items list every time the user invokes your menu through whatever gesture.

- (BOOL)canPerformAction:(SEL)action sender:(id)sender
{
    if ( action == @selector(myMenuItemMethod:) ) {
        return YES;
    }
    else if (...) {
        return ...;
    }
    else {
        return [super canPerformAction:action sender:sender];
    }
}

Of course, there might be situations where the same view might support different menu configurations depending on some context, in which case you probably do need to rebuild the menu list each time. But in case where you don’t…

3. Remember that your menu items are persistent:

Whatever menu items you add will remain there until they are set again. If you think about it, this makes sense since UIMenuController is a singleton.

This one bit me due to two reasons. 1) I didn’t have -canPerformAction:sender: implemented, 2) I assumed that menu items list must be rebuilt prior to each invocation of the menu. What happened was a different subview was presented within the main view of the controller, and the subview contained an UITextView. When the user double tapped the text view, and had some text on their pasteboard, the Paste menu option was displayed, along with the other menu options already installed by an earlier menu displayed in the same view. Oops.

The first solution was to nil out the menuItems when the menu was dismissed. This seemed a bit of hack. The better solution was to follow item 2 above since my menu items never changed as long as I was in this particular view. In this case, since a subview only required the basic Copy, Cut, Paste, Select, Select All, etc. the controller would return NO when the controller itself was no longer the first responder. Revisiting our implementation of -canPerformAction:sender: from above:

- (BOOL)canPerformAction:(SEL)action sender:(id)sender
{
    if ( action == @selector(myMenuItemMethod:) ) {
        return [self isFirstResponder];
    }
    else if (...) {
        return ...;
    }
    else {
        return [super canPerformAction:action sender:sender];
    }
}

Cheers!

Tags: , , ,

Comments are closed.