Question

I am currently writing a multi-user social iPhone app which interfaces with a server.

I have a User class, which stores all the general data about each user (name, id, etc etc). However, where I am tripping up is how best to store these users.

Currently, I have a Singleton called “UserManager”, which stores an array of each user in the application (downloaded from the server – on initial launch you are prompted to input some basic details), as well as a separate user object to differentiate the actual current user of the app. The user list needs to be accessed from many different parts of the app, including a map which shows where they are (if they choose to reveal it), to a list of other users to enable sending messages to them, etc.

To be completely honest, the Singleton solution doesn’t sit right with me. I have always heard to avoid Singletons wherever possible, however I’m drawing blanks on what is better to use.

I only have a fairly basic understanding of Design Patterns, though obviously I know that shoehorning a pattern when its not required is a horrible idea.

So I returned here to ask you good people in what manner you would store this kind of data! I don’t necessarily mean iPhone only either, this is a wider problem. I fail to understand properly how I should do this kind of thing in any situation.

Thanks in advance!

Answer 1

You’re on the right track in that you want some sort of data controller object which will handle your user data objects from you. You could make this object a singleton, or you could not. The alternative is to have your application controller (app delegate usually) instantiate the data controller, and pass it on to each of your window or view controllers at launch time. One advantage is that it would be easier to modify your application to have multiple data controllers; this isn’t as important for an iPhone app, but it may be an issue for a desktop app that could have multiple document windows open at once. On the other hand, a singleton is probably going to be simpler to code and may prevent bugs down the road.

You might find the last few paragraphs on the Apple MVC design pattern documentation interesting, it talks a little bit about separating the model controller / view controller roles.