1

I'm working on a multiplayer game iOS app and I've come to a point in the design where it seems that I would benefit from creating two singletons but I don't know if there is a superior design pattern.

  1. A live game singleton: to get/set properties and start/stop the game from anywhere in the app.
  2. A location manager singleton: to manage user location updates/properties from anywhere in the app but especially from inside of the live game singleton because the game mechanics affect the properties of the location manager.

And if you are wondering do I really need to interact with these objects from absolutely anywhere in the app, the answer is a definite yes. This is a live multiplayer experience so everything related to gameplay needs to persist cleanly throughout the app's lifecycle.

So would this be a correct use of the singleton pattern or is there a better method, and if there is why is it better?

rmaddy
  • 314,917
  • 42
  • 532
  • 579
user3915477
  • 275
  • 4
  • 11
  • What are your other options? – donlys Nov 01 '16 at 16:57
  • Read http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons – rmaddy Nov 01 '16 at 16:58
  • You will be very sorry down the road if you use a singleton now. Consider a future update where you need to support tracking more than one live game at a time. – rmaddy Nov 01 '16 at 17:00
  • "You will be very sorry down the road" - sorry I still don't see why that would be the case. Is there something more fundamental than the example you gave? – user3915477 Nov 01 '16 at 17:17
  • Singletons also create a memory issue, because they always reside in the memory and are not deallocated. – Bhavuk Jain Nov 01 '16 at 17:24
  • @user3915477 Let's say you create a `LiveGame` singleton. Throughout your app you have code such as `LiveGame.instance.whatever`. Everything works. Now you realize you need to support separate `LiveGame` instances. Now, every single reference to `LiveGame` in your app needs to change to reference a specific instance. You now have to refactor your entire app. That's painful. Plan ahead. Pass the `LiveGame` instance around properly from controller to controller now. Then you don't need to refactor your entire app later. – rmaddy Nov 01 '16 at 17:29
  • @BhavukJain unless he's reading and writing a massive amount of things from this singleton that's really a non-issue. – Zolnoor Nov 01 '16 at 18:57

1 Answers1

0

I believe that you need to take a look at dependency injection. You should someway instantiate your objects passing a Game and LocationManager instances during each other object construction time (i.e. pass them as constructor arguments to any object that will need either or both Game and LocationManager instances).

Actually, there will be only a single instance of Game and LocationManager that will be created during game initialization and the top-most object in your game will start to inject both objects like a cascade!

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206