Any particular reason that Sam spawned the button as a game object and later on grabbed the button component? Can’t you just instantiate it as a button in the first place? Presumably the latter is microscopically more efficient, but any downsides?
Button buttonInstance = Instantiate(buttonPrefab, contentRoot);
TMP_Text textComp = buttonInstance.GetComponentInChildren<TMP_Text>();
textComp.text = save;
buttonInstance.onClick.AddListener( () => savingWrapper.LoadGame(save) );
Button buttonInstance = Instantiate(buttonPrefab, contentRoot);
That’s what this part of the code is essentially doing, instantiating, placing it as a child of contentRoot and storing the button reference.
Maybe I’m not understanding your question?
I’m not 100% sure on this, but I don’t think this was always possible.
It used to be that Instantiate returned an Object, and it was common practice to cast that to a GameObject or component.
Then I think Instantiate was changed to always return a GameObject instead, but a lot of us kept casting anyway for a long time.
I’m not sure if/when it changed, but now Instantiate returns a generic type based on the type of object (Prefab) it’s copying. But I think a lot of us are still used to only having Instantiate return GameObjects.
I only discovered and started using Instantiate as T just a few days ago. It’s very handy to get a reference to a controller script or something straight away.
The documentation still specifies that it returns an Object. Change is hard.
@MichaelP
Sam instantiated as a GameObject and then did a GetComponentInChildren to get the button part whereas I went straight to the button (removing the need for GetComponentInChildren).
Was just wondering if I had missed a subtlety somewhere or if I had suddenly become better than Sam
@Anthony_Juarez
Thank you. That makes sense. Sometimes its helpful to be late to the party!
ok, I think I better understand your question now.
Don’t quote me on this, but I believe your way uses reflection (which is typically slower) and Sams way uses a way that Unity caches rather efficiently. That being said, I wouldn’t be surprised if Unity does some sort of internal cashing so it doesn’t matter.
From a performance point of view, the best way to figure it out is to run each way a lot of times (like 10k or 100k) and time it to see if you find any significant performance difference. Just be aware that this result can change depending on your Unity version as Unity adds (and I hear can remove) caching to some parts of its engine here and there.
I think for the purposes of the UI, that it’s not going to make a lot of difference in spawn time, since we won’t be doing this every frame, and in my own testing when the course first came out, even a very large assortment of game saves rendered so quickly that there was no discernable pause.
I remember those days quite well. I also don’t remember exactly when the syntax changed, and Unity’s documentation is (like much of Unity’s documentation) woefully underwhelming.