Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Event Triggers vs. Implementing Interfaces

Discussion in 'UGUI & TextMesh Pro' started by _alphaBeta_, Jan 10, 2017.

  1. _alphaBeta_

    _alphaBeta_

    Joined:
    Aug 8, 2014
    Posts:
    38
    I'm trying to understand if there's any performance and/or supportability considerations with implementing UI functionality with event triggers in the inspector vs implementing the interfaces directly in code. As an example, one could call a script method that does "stuff" via the "On Click ()" field in the inspector of a default Unity UI button. One could also attach a new script to that button that implements IPointerClickHandler and place the same "stuff" in "OnPointerClick."

    Is the "On Click ()" field, and others provided by the event triggers component, in the inspector mainly for convenience and/or those that do not want to go too far "under the hood"? I realize it may come down to personal preference, but I'm finding the event trigger interface to be clunky beyond basic functionality, and tracking changes is becoming cumbersome since this data is all stored as part of the scene and not in code. It would seem implementing the interfaces also provides access to PointerEventData.

    Am I missing anything here? Just two different ways to do things that appeal to different people? More to it than that? I'm finding both methods documented all over, but I've failed to find a compare and contrast to really distinguish them.
     
    kubajs likes this.
  2. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    I think this.

    Inspector-based event triggers expose functionality to level designers. If you're handing off work to non-programmers, they and you will appreciate it since it empowers them and frees you up to do other programming work. Event triggers also let you hook up functionality in prefabs without having to worry about maintaining code to do it.

    On the other hand, hooking up events in code has all the advantages you listed, with the disadvantages of hiding the connections from level designers and requiring programmers to maintain the connections.
     
  3. _alphaBeta_

    _alphaBeta_

    Joined:
    Aug 8, 2014
    Posts:
    38
    Thanks for taking the time. I just wanted to make sure I wasn't missing anything that I would come to regret later.
     
  4. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    Oh, you will. Isn't that the nature of programming? ;) You'll write the perfect code-based system, then the world's greatest level designer will join your project and ask you for UnityEvents, or vice versa. But other than that you outlined the pro's and con's perfectly in your original post.
     
  5. Antistone

    Antistone

    Joined:
    Feb 22, 2014
    Posts:
    2,836
    If you're considering mixing these approaches, I should mention I've had problems with Buttons containing a child object with an IPointerClickHandler, where click events on the child are not handled either by the child or the parent.
     
  6. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    BTW, if you run into this issue, you can hook up your events manually in code using onClick.AddListener(). Not as pretty as IPointerClickHandler, but it keeps it all in code.