# Unity Unity Software Architecture - how to make reusable UI classes that inherit from MonoBehavior

This topic is 758 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

So I am working on an indie game in Unity and I've recently decided to move all of my UIs (user interfaces) into Canvas game objects, which is fine and dandy, but it does require me to re-write some code. Specifically, I have the following architecture that relies on the interface game objects having a GUITexture component:

public class InterfaceHandler : MonoBehaviour
{

/// <summary>
/// Hides the GUI Texture.
/// </summary>
public void Hide ()
{
GetComponent<GUITexture> ().enabled = false;
}

/// <summary>
/// Shows the GUI Texture.
/// </summary>
public virtual void Show ()
{
GetComponent<GUITexture> ().enabled = true;
}

void Start ()
{

}

// Update is called once per frame
void Update ()
{

}
}

public class InterfaceHandlerA : InterfaceHandler
{

public Texture2D[] Images;

private int _imageIndex = 0;

public int ImageIndex
{
get
{
return _imageIndex;
}
set
{
_imageIndex = value;
}
}

// Use this for initialization
void Start ()
{
Hide ();
}

// Update is called once per frame
void Update ()
{
GetComponent<GUITexture>().texture = Images[_imageIndex];
}

}


The problem is that with Canvas, there are no GUITextures. Instead I have to use RawImage or Image. So now I have to either re-write the code above (there are many more classes that inherit from InterfaceHandler, InterfaceHandlerA is just one of them) or write all new code that does the exact same thing, except with RawImage or Image instead of GUITexture.

This seems like a good opportunity to stop, take a step back, and really think about how to properly engineer this thing. I want it to be re-usable and maintainable, so that if a year from now Unity decides to replace Canvas with something else and there are no more RawImages, my code would still work. I am thinking maybe some kind of Dependency Injection might work here, or perhaps Generics, i.e. something like this:

public class InterfaceHandler<T> : MonoBehaviour


I tried the approach above, but it tells me that type T doesn't have a property called 'enabled'.

Any other ideas? What would be the best way to architecture this?

##### Share on other sites
I feel like I'm missing critical info here, but in general I wouldn't bother. This smells like over-engineering, but I also suspect that it's possibly motivated by mis-estimations of canvas.

How many uniquely coded UI elements do you really need to tamper with?

If you're doing something unusual then more information is necessary to answer questions about how to structure it. If you're not then look closer at what's available from the engine to makes sure you're not reinventing the wheel or missing some more concise way to do what you need.

##### Share on other sites

Is this some weird sort of sprite animation? I can't see any other reason why you'd be trying to switch a texture every frame.

If you want to hide a UI element in Unity, then you disable the object itself or the canvas.

It looks like you're trying to make a direct 1-to-1 translation of your old code, but the new system isn't meant to be treated that way.

##### Share on other sites

Yeah, the per-frame update doesn't make any sense. The index variable gets set on demand, but then the texture is updated every frame. Why not just update the texture in the set method?

##### Share on other sites

I feel like I'm missing critical info here, but in general I wouldn't bother. This smells like over-engineering, but I also suspect that it's possibly motivated by mis-estimations of canvas.

How many uniquely coded UI elements do you really need to tamper with?

If you're doing something unusual then more information is necessary to answer questions about how to structure it. If you're not then look closer at what's available from the engine to makes sure you're not reinventing the wheel or missing some more concise way to do what you need.

I am not very familiar with Canvas, so it may well be over-engineering, but I can't help but feel there is a way to design this so that it's re-usable and not tightly coupled to a GUITexture or RawImage or some other graphics class.

And I currently have 8 UI elements that have scripts inheriting from InterfaceHandler above. Most of them either call the Hide or Show method (or both) and set the texture property of the GUITexture component. Here is one more of them, this one alternates two image to create a very simply animation:

public class InterfaceHandlerB : InterfaceHandler
{
private int _imageIndex;
private float _speed;

public Texture2D[] sweepingFrames;

// Use this for initialization
void Start ()
{
_imageIndex = 0;
_speed = 3.0f;

Hide ();
}

// Update is called once per frame
void Update ()
{
if (CurrentState == State.Clean)
{
GetComponent<GUITexture> ().texture = sweepingFrames [_imageIndex];

_imageIndex -= 1;
_imageIndex = Mathf.Abs (_imageIndex);

CurrentState = State.None;
}
}


##### Share on other sites

Is this some weird sort of sprite animation? I can't see any other reason why you'd be trying to switch a texture every frame.

If you want to hide a UI element in Unity, then you disable the object itself or the canvas.

It looks like you're trying to make a direct 1-to-1 translation of your old code, but the new system isn't meant to be treated that way.

Nope. That particular script simply sets a texture, to the GUITexture component, that shows what level the player is on in a mini-game, i.e. something like Level 1, Level 2, etc. Although one of the other scripts inheriting from InterfaceHandler does simulate a very simple two image animation.

Basically, I need a generic, re-usable way to hide or show a GUITexture, RawImage, or Image component and to also provide capability to change the texture (or sprite if it's an Image, as Image doesn't seem to have texture) attribute of said component to different images.

##### Share on other sites

You can use mechanim within canvas so that it's a lot easier to edit and manage your animations and they can be timed instead of frame locked.

##### Share on other sites

Nope. That particular script simply sets a texture, to the GUITexture component

So doing it in the Update function is the wrong place.

If you want to animate graphics, use their Sprite system. If you're changing text, use the Text object and change that. If you want to hide or show images, enable or disable the object or the component. Wrap these calls in functions if you like but trying to abstract away the entire engine is just going to cause more trouble than it solves.

##### Share on other sites
As others pointed out already, it would be better for you to just direclty use the methods and properties already available. Hiding an Image should be done by deactivating the game object. (This way, it also doesn't matter if it is an image, a text, or a composition of multiple UI elements.)
Same goes for setting the image: just assign it directly, unless you want to apply some special logic that really needs to be encapsulated in another component.

Besides that: You should store references to components you're using multiple times. Searching for them every time using "GetComponent" takes more time. If it is done once a frame, it's really worth the refactoring.
Also, you should calculate your _imageIndex with something like this._imageIndex = (this._imageIndex + 1) % this.sweepingFrames.Length;

##### Share on other sites

Nope. That particular script simply sets a texture, to the GUITexture component

So doing it in the Update function is the wrong place.

If you want to animate graphics, use their Sprite system. If you're changing text, use the Text object and change that. If you want to hide or show images, enable or disable the object or the component. Wrap these calls in functions if you like but trying to abstract away the entire engine is just going to cause more trouble than it solves.

I am not sure that creating abstractions would cause more problems. For example, currently I have 8 UI scripts for the minigame in question, which are tightly coupled with GUITexture. Now that I am switching to Canvas and planning on using RawImage components, I have to write 8 more scripts, tightly coupled with RawImage. Then what happens if I decide to add some Image components? I have to write more scripts, tightly couple with Image. While if I can somehow write generic scripts that handle all image components, that would save me a lot of extra code.

Somebody above mentioned using the Graphic class, instead of RawImage or Image, since both inherit from it. That sort of works, but Graphic doesn't have texture or sprite attributes, so I still have to write tightly coupled code.

I am currently pondering an architecture utilizing the Adapter design pattern. That might be what I am looking for.

1. 1
2. 2
3. 3
Rutin
14
4. 4
5. 5

• 9
• 9
• 11
• 11
• 23
• ### Forum Statistics

• Total Topics
633676
• Total Posts
3013279
×