Discussion Button: Set on Editor vs onClick.AddListener

I open the debate to know your opinions, pros and cons. Above all the most important thing, what is more optimal?
thank you for your answers

 

Optimal for what?

Do you anticipate the user will press this button so many times per frame that the connection of a delegate would be a performance factor?

As far as choice of technique, I use both, depending on situation, team, use case, complexity of callback etc.

 

I wonder about those things as well. Is setting things in the Inspector merely a way for avoiding coding, making things easier for people who are new to coding, or is it the best way to go?
Same for finding objects/components by GetComponent in code, or dragging objects in a slot in the inspector.

 

Again, it is all context.

If you're on a team and expecting non-engineers (artists, designers, etc.) to hook up methods, then use the editor, or else you will be on the hook to support the entire team with this menial task.

If you're runtime-instantiating buttons based on how many levels your user has actually discovered and unlocked, then you obviously must do it in code.

Be sure to understand:

- what you are doing
- when you are doing it
- who else might be doing it with you / for you

This is actually engineering. You are engineering a solution and your decisions have real consequences.

Attached is a simple example of a dynamic UI, one that discovers an indeterminate number of sprites in a Resources/ folder and makes buttons for each.

 

Thx for you answer, I mean optimization, for example... I understand that if you leave methods like Awake even if they have nothing inside, the game becomes less and less performate and if the awake and start have a lot of work the loading time is longer. When it is set from Editor what really happens?

 

I did not come to a complete decision, but putting the functions from the code does not allow to find quickly which is the script that is assigning that function, alog as well as making a call of a function in code from invoke, this does not allow the nageavion in the code.

 

Thanks. The wondering is not about getting it to work, but more about, which way is "better" when you are able to do both? It doesn't really matter right now, my games are too small to even notice a performance difference. But it is something to work towards, if needed.

 

yep, there are pros and cons for both ways

 

Oh my goodness, how often is this code running?!!!! Do you even CARE if it takes half a billisecond versus a full billisecond when you set up a button!?

DO NOT OPTIMIZE "JUST BECAUSE..." If you don't have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window -> Analysis -> Profiler

Failure to use the profiler first means you're just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Don't forget about the Frame Debugger either, available right near the Profiler in the menu system. Remember that you are gathering information at this stage. You cannot FIX until you FIND.

Notes on optimizing UnityEngine.UI setups:

https://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

At a minimum you want to clearly understand what performance issues you are having:

- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as "reimport all textures as 32x32 tiny textures" or "replace some complex 3D objects with cubes/capsules" to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you're properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

 

Thanks again for your complete and dedicated answer, I know the traditional ways to find performance problems, I mean, I am like Senior at this moment, I just want to open the discussion with other developers to know our opinions about this case. I once had to work on optimizing a mobile game and one of the big problems with slow loading levels was that the Awake and Start were overloaded with stuff.

 

Personally I prefer to never code anything that can be done with data, so I would always connect these in the editor. Except, as Kurt mentioned, if I were generating buttons at runtime.

For me ease-of-implementation and maintainability are high priority.

 

In UI Toolkit, you don't really have a choice. You can only subscribe to button events via code.

(Does make me wish they would provide a way to reference over visual elements via the UI builder).

Though with uGUI I'd generally assign buttons through the inspector if I can, and via code for generated/dynamic stuff.

I don't think either of these would make a major difference to a performance in most projects. There are bigger fish to fry performance wise.