iOS Target action methods v delegates v IBActions

[MickeyT]

After seeing how a UISegmentedControl deals with segment changes, I asked myself the question "how many more event triggers are needed!"

I had become comfortable with why delegates/protocols and IBActions are needed; I had reasoned that IBAction would be okay for a user interface event (i.e. a button is pressed), whereas delegates/protocol calls are needed because not all events might be user interface driven (i.e. the change of location).

I was working through an exercise in a book, where part of a "challenge" was to implement a UISegmentedControl. I went to the apple documentation fully expecting to see a set of protocol methods and that a delegate can be set up for them, with one of the methods being triggered on a change of segment. There wasn't.

I tried linking my segment control to the Touch Up Inside event (just because that works with buttons), but that action doesn't trigger anything. So I went with the documentation by implementing the target action thing and it works fine.

Why is the target action functionality required? Why has this not been created so that one of the IBAction events listed works when the segment is changed and do it that way, or just have delegate functionality like a text field does?

Thank you

 

[dejo]

Target-action methods are pretty much what setting up IBActions is.

 

[MickeyT]

So is it that basically if there isn't an action there when you right-click on something in interface builder, the appropriate action will most likely be implemented in one of the two other ways?

Thank you

 

[MickeyT]

Actually I suppose checking the documentation first is the way to go - presumably it will always tell you the appropriate way to implement responses to events.

Sorted - thank you again.

 

[dejo]

Actually I suppose checking the documentation first is the way to go - presumably it will always tell you the appropriate way to implement responses to events.

Yes, checking the documentation first is usually the best approach, once you're comfortable with the fundamentals. Otherwise, they can seem a tad overwhelming for the uninitiated.

Sorted - thank you again.

And resolved?

 

[MickeyT]

Yes, sorry. Resolved. I thought i had already flicked the resolved switch?? Sorry if not. I think I get it - anything that inherits from UIResponder seems to have these so ill watch out for them.

Thanks again.

 

[PhoneyDeveloper]

It has to do with a view being a descendant of UIControl. UIControl has a bunch of built-in events that can be posted. That's the list of touchUpBlahBlah events. Look in UIControl.h. And that's what you see in IB.

You might consider the differences between UITextField and UITextView. They are obviously quite similar in functionality but one is a control and the other isn't. It took me a long time to realize that I could get UITextField to send a value changed message to an action method rather than by a notification.