In a UIViewController subclass I create a bar button item that fires an event up the responder chain:
UIBarButtonItem* editListsButton = [[UIBarButtonItem alloc] initWithTitle:@"Edit" style:UIBarButtonItemStyleBordered target:nil action:@selector(edit)];
self.navigationItem.leftBarButtonItem = editListsButton;
[editListsButton release];
In an ancestor UIViewController subclass’s implementation (i.e. in the .m file) I have the following:
@interface GroupController (PrivateMethods)
- (void) edit;
@end
- (void) edit {
... do something here ...
}
And of course in the corresponding .h file I do not declare the edit method. This was a random mistake on my part.
Should this work reliably anyways? What is the requirement for how to declare the method so that it receives the edit events?
BTW, I have reports that touching the “Edit” bar button item causes the app to crash every time it is touched, but only from a few of many thousands of users. I can’t reproduce it.
There is no “visibility” for Objective-C methods beyond where you stick the declaration at compile time. At runtime, they are all the same.
First, action methods take an argument — the sender. Thus, your method really should be declared as:
Note that
IBActionis actually #defined to bevoid. It is used by Interface Builder only. Since you are doing things programmatically, you could usevoid. Of course, that begs the question as to why you are doing things programmatically since that is almost always a waste of time, but… beyond the scope of this question.In any case, yes, it should work reliably. Whether or not a method is declared in a header makes zero difference at runtime.
Given that your crashes are rather intermittent, it sounds more like you might have a memory management problem (or other latent crasher). Did you build-and-analyze your code? Got a crash log?