Singleton and MonoBehaviour in Editor

Question

Hello all,

I'm using a simple singleton pattern in a script:

 public class EasySingleton {
   private static EasySingleton instance = null;
   public static EasySingleton Instance { get { return instance; } }
 
   void Awake() {
     instance = this;
   }
 }

Everything in-game works fine, but there is one annoying thing when working in the editor: if I press Play, make some code changes, and click back in the game view, I get NullReferenceExceptions when accessing "instance". Normally, such on-the-fly code editing works fine.

So my questions are: what events get called when switching from play mode to code and back without stopping the game before? How can I optimize such a singleton pattern to work smoothly in the editor? Does this work better with another singleton pattern?

Best regards, Felix

Answer 1

Best Answer

Answer by Bunny83 · Aug 15, 2011 at 06:33 PM

Yep, usually i use this one:

 private static EasySingleton instance = null;
 public static EasySingleton Instance
 {
     get
     {
         if (instance == null)
             instance = (EasySingleton)FindObjectOfType(typeof(EasySingleton));
         return instance;
     }
 }

To be on the absolute safe side you could implement a second check to create it if it's not found

 get
 {
     if (instance == null)
     {
         instance = (EasySingleton)FindObjectOfType(typeof(EasySingleton));
         if (instance == null)
             instance = (new GameObject("EasySingleton")).AddComponent<EasySingleton>();
     }
     return instance;
 }

Add comment · Show 6 · Share

Bunny83 · Aug 15, 2011 at 06:41 PM 0

Share

The problem is that when you change something during runtime Unity recompiles all scripts and therefore have to recreate every object instance. Unity uses it's own internally serialisation function to "save" the old state and to restore it after the objects are recreated. But Unity doesn't serialize everything so you will loose all non serialized fields. As long as you only use serialized fields (public or [SerializeField]) it should be ok.

fherbst · Aug 16, 2011 at 03:27 PM 0

Share

Yep, thats what I currently do - check if the singleton != null. Double-checking and creating if not existant is a nice idea, thanks.

GermanViscuso · Dec 10, 2013 at 11:23 PM 0

Share

Thanks Bunny83 this saved my life!

Lypheus · Feb 10, 2015 at 05:54 PM 0

Share

Double checked locking is a BAD idea : http://stackoverflow.com/questions/394898/double-checked-locking-in-net

Ins$$anonymous$$d, the simplest and best approach is: https://msdn.microsoft.com/en-us/library/ff650316.aspx

Bunny83 · Feb 13, 2015 at 02:58 AM 0

Share

@Lypheus: Your two links are not relevant here because:

$$anonymous$$y implementation doesn't have a double checked locking since i don't lock at all. Look at my examples carefully.
Unity's classes / interfaces aren't thread safe so usually multiple threads aren't be used.
The implemenation presented on those sites you've linked simply use the "new" keyword to create an instance. In Unity you can't create an instance of a component with "new". You have to use AddComponent on a GameObject. That's what i do in my second example.
The usual implementations of Singletons in Unity are singletons which are represented by serialized objects. Like you can see in the question the OP had such a case. He used the Awake callback to initialize the variable.
All those "double checked locking is bad" articles only talk about a multithreaded environment which is not relevant here since "FindObjectOfType" as well as "new GameObject" and "AddComponent" can only be executed on the main thread. So there's no way to implement a thread-safe version of a Component-based singleton in Unity.

Show more comments

Singleton and MonoBehaviour in Editor

1 Reply

Your answer

Follow this Question

Related Questions