Start
Closed this issue · 2 comments
Hi Jordan,
I've been using yaSingleton for a while now on a number of projects. From time to time I find I need to implement a Start initialisation as the Initialize method fires too early to grab Scene objects. I'm wondering if there is an architectural reason for not hooking up the Unity Start functions in yaSingleton? Perhaps I'm missing a trick in the way I'm structuring my projects.
Dave
Heyo Dave,
Sorry for the late reply, I need to manually check github to find out any new comments (I'll double-check the settings after replying; I've been adding those email notifications for a while now xD).
I didn't implement the Start method for one reason — to highlight the fact that the singleton is based on a ScriptableObject and not on a MonoBehaviour. If I happen to need it, I see it as a flag that my architecture needs some thinking to get it where I want it to be. I'll have an extra tip on how to make that easier in a bit.
My preferences aside (since simple is almost always better), you can easily hook up to a Start method to your singletons. The SingletonUpdater is an ExecutorBehavior so it does support a Start method (and most other methods). You can hook it up in the Initialize method. It should be safe to use for most intents and purposes.
Architecture-wise, I'm a big fan of serializing most state in ScriptableObjects with a couple things in mind — to be able to pass them around using the inspector and to give me convenient events with which I can track changes to said state. To get the gist, you can check out the SavedValue and some of the serialized variables in the Workflows part of the Elarion library (it's focused on the Workflows part but it also has a small UI kit and a few other handy things I extracted from my failed game startups xD).
Note: We can have a chat some time about this because I was too lazy to document it properly xD
Hey Jordan!
No Worries, time not heeding the beck and call of the unwashed masses of the Internet is time where you have your priorities in the correct order :p
I think you're right about the "architecture smell" of needing Start in a ScriptableObjects. Really my current project is super old (>5yo!) and full of so many different mismatched paradigms that I have swapped between as I've learned that I am past trying to get it "right" for this one. Just "good enough." will do :) I'll keep this in mind as I build out other new ventures.
you can easily hook up to a Start method to your singletons.
Yup, that's what I have been doing. :) Though it always felt dirty.
ScriptableObjects are pretty great, your SavedVariables look interesting, my initial feel was that they are too granular as I feel you only want to persist sets of state? But the hookups to Events are pretty cool. I'll have a further look at how you are using them.