Purpose of UIBehaviour

Doesn't seem to be a lot of info on the new UIBehaviour class...

I know from the limited documentation and looking at the UI source code that UIBehaviour is pretty much just MonoBehaviour with some of the Unity lifecycle functions (Awake, Start, OnDestroy, etc.) declared as empty protected virtual methods. I also know that most (all?) of the new UI classes (Image, Button, Selectable, etc.) derive from UIBehaviour.

I just don't understand why and when I should be using it as well. I tried creating a custom UI OnPointerDown event handler for one of my buttons and it seems to work fine when derived from MonoBehaviour instead of UIBehaviour.

Anybody know?

 

Was curious as well… this is where my research lead me first

 

I also looked into the reverse engineered code and searched for references.
Looks like this behavior is really a bit useless.
My best guess is that Unity Developer just wanted to write proper C# code without these magic function calls where you need to know the function name.
Maybe there is also a performance reason to have such a base class (the magic code doesn't have to check if the method exists... maybe there is somewhere a collection of UIBehaviours in the native part of unity).

Hope a Unity developer reads this and brings some light into the darkness

 

Note to help anyone who hit the problem I just had:

The UIBehaviour callbacks will NOT run in the Editor, even though this is the most obvious place they're useful/needed (writing custom UI components, UI layouts -- you need to make sure your UI looks the same in editor as it does in the game!).

You need to add ExecuteAlways/ExecuteInEditMode to every single one of your UIBehaviour scripts or nothing will work . Seems pretty dumb that UIBehaviour doesn't automatically provide this.

 

My research led me here.

 

I've asked myself the exact same question. Why this weird case is not better documented? Just one more redundant layer of abstraction

 

My guess is they wanted enforce inheritance of Unity lifecycle functions. For example, if Button is like

class Button { private void Awake {...} }

you could easily override Awake without knowing by writing

class MyButton: Button { private void Awake {...} }

. But when they are empty protected you have to do

class MyButton: Button { protected override void Awake { base.Awake(); // probably ...} }

, this way you get a compiler warning if you override a UI element lifecycle functionality by mistake.

I think this should be default for all Monobehaviors. Sometimes you override one Awake or Start without knowing then it becomes very hard to find what's going on.

 

As you can see

https://bitbucket.org/Unity-Technologies/ui/src/2019.1/UnityEngine.UI/EventSystem/UIBehaviour.cs

There was made for having more method related to UI for its framework to be called and for you to overriding it if you need. So if you don't need to extend these method, you surely don't need it