iPhone app, Singletons, passing messages between ViewControllers & application design

I'm working on my first app now and it's going quite well, but I'm wondering if i'm using the correct app design.

I'm building an app which makes use of a navigationController to display a couple viewcontrollers.

In the first viewController a CustomObject is created and in the consecutive viewControllers properties for this customObject are chosen and set.

I've created a Singleton class which handles all coredata actions. creating a new object. saving the created object etc. The Singleton has a property currentObject. All ViewControllers have access to this singleton.

So for example, in view 1 the user tabs a button "new car". The CoreDataSingleton creates the new car object which is accessible using currentObject.

A new view is pushed and default values for the new car are shown.

The user tabs "select color", a new ViewController is shown where the color can be selected. Using the singleton.currentobject the color is set, the view is popped and other properties can be set and so on. Finally the user tabs "Save" and [Singleton saveCurrentObject] is called.

This method works fine, but I've been reading a lot of post on the web where people say that Singletons are bad, the worst you can do etc. etc…..

What do you think about this application design? If Singletons are bad, how would you implement this kind of funct开发者_开发问答ionality?

Regards, Michiel

---

I haven't coded too many core data applications, however, I can tell you that singletons are appropriate for handling global data that youer classes need to access. This is the preferred method as opposed to the appdelegate method.

See this thread for some thoughts on using singletons for core data apps.

---

Here is a good article to read up on Singletons vs AppDelegates. It explains why Singletons in most cases are a better way to implement global access variables, then with the usage of AppDelegates.

---

"Singletons are bad" is an extension of "globals are bad" mentality. In reality, if it works for you, great, use it. Really the key, as with anything, is that you know the shortcoming and pitfalls of using whatever algorithm you're using - as long as you know them, then theres nothing wrong with using them.

---

Well, you're other choices are to serialize the data and save it in a file or database and reload it as you go from view to view; or to pass the current object as a parameter as you push new table views. I really can't think of any other ways of handling the problem.

Neither of those is inherently better than the way you are currently doing it. Passing the object as a variable is sort of a pain, and serializing/deserializing is the slow, painful way of doing what you are currently doing.

The other nice thing is it seems easy to save the object in the event of application termination, too.