The Singleton

When we started the development of our game, we managed all our objects locally within the scene. We didn't want or need to worry about the lifetime of our services/managers. However, as almost always is the case, our game matured, and we started using multiple scenes. Now, we needed our services or manager classes to be easily accessible by child scenes and almost anywhere in our code.

In games of old, we would have just created a global or static variable to track game state across scenes or scripts. A global static class could work, but suffers from a number of limitations, as follows:

  • Static classes are lazy loaded and can be especially fragile in Unity.
  • Static classes cannot implement an interface.
  • Static classes can only be derived from an object. They cannot inherit from MonoBehaviour and thus be used as components in Unity, which means that they cannot also use Unity Coroutines or other base methods, such as Start, Update, and so on.

Let's take a look at the difference in declaring a standard MonoBehaviour game object and one that uses Singleton with the updated GPSLocationService script.

Tip

Feel free to open the updated scripts in the editor of your choice while you follow along.

The previous implementation of the GPSLocationService was declared as follows:

public class GPSLocationService : MonoBehaviour 

This, as we saw many times now, is the standard way to declare a Unity component. Compare that to the new class declaration of the GPSLocationService:

public class GPSLocationService : Singleton<GPSLocationService> 

Note

Review and understand how the Singleton class definition works. The script is located in the Assets/FoodyGo/Scripts/Managers folder.

This may look strange: declaring an object to inherit from generic type called Singleton with itself as the type. Think of the Singleton class as a wrapper that converts the instance to a global static variable that is accessible anywhere in code. Here is an example of how the GPS service was accessed before and is now:

//before, GPS service object was set as a field of the class which had to be set in the editor 
public GPSLocationService gpsLocationService; 
gpsLocationService.OnMapRedraw += gpsLocationService_OnMapRedraw; 
 
//after, the GPS service is now accessible anywhere as a Singleton 
GPSLocationService.Instance.OnMapRedraw +=  GpsLocationService_OnMapRedraw; 

There is one critical element that you should be aware of when working with our implementation of Singleton. We will always make sure that we instantiate a Singleton manager or service as a game object in a scene. This is done, so we can take advantage of the Start, Awake, Update, and other methods. However, if you do not add these objects into a scene and then try to directly access them in code, they will be accessible but will likely be missing important initialization set in the Awake or Start methods.

Take a look at the classes that consume the GPSLocationService: the MonsterService, CharacterGPSCompassController, and GoogleMapTile. As you will appreciate, the differences are subtle but significant.

In this chapter, we will add another consumer of the GPSLocationService and also make the new service a Singleton. This new service will be the GooglePlacesAPIService, and we will cover it in the next section.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.38.3