Resolved Target action methods v delegates v IBActions

Discussion in 'iOS Programming' started by MickeyT, Jan 10, 2013.

  1. MickeyT, Jan 10, 2013
    Last edited: Jan 10, 2013

    MickeyT macrumors member

    Joined:
    Apr 26, 2010
    Location:
    Newcastle, United Kingdom
    #1
    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
     
  2. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #2
    Target-action methods are pretty much what setting up IBActions is.
     
  3. MickeyT thread starter macrumors member

    Joined:
    Apr 26, 2010
    Location:
    Newcastle, United Kingdom
    #3
    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
     
  4. MickeyT thread starter macrumors member

    Joined:
    Apr 26, 2010
    Location:
    Newcastle, United Kingdom
    #4
    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.
     
  5. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #5
    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.

    And resolved?
     
  6. MickeyT thread starter macrumors member

    Joined:
    Apr 26, 2010
    Location:
    Newcastle, United Kingdom
    #6
    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.
     
  7. PhoneyDeveloper macrumors 68040

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #7
    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.
     

Share This Page