iPhone Accessible Object Storage

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 differ开发者_开发百科entiate 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!

---

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.

---

I would lean towards a UserStore object able to populate the User object from a Core Data store as required, storing all of your users including the current user. That's the Mac/iPhone-specific database but you might use sqlite or some other store in other situations.

Even if you don't need to persist the user data you can get some benefit by giving yourself access to use full tools like predicates and NSFetchedResultsController for sorted presentation of your data.

The singleton seems perfectly reasonable and I have done a few apps using this strategy. If you think in terms of MVC you will have the views accessing the model (store) and all is well. I am not keen on choosing a pattern for the sake of having a pattern but Singleton is a design pattern and in this case I think it's the right one.