Question

Fairly early on in my app, when I was a lot less experienced than I am now, I wanted to spice up some transitions between view controllers with my own custom animations. Having no idea where to start, I looked around SO for a pattern like MVC that could be accessed from nearly any controller at any time, and as it turns out, a singleton was the way to go.

What I didn’t realize is that there seems to be a strong and well-defended hatred of the singleton pattern, and I myself am starting to see why, but that is beside the point.

So, a while later, I decided to move my very same implementation into a category on UINavigationController (after all, it handles transitions!), kept the original classes around for comparison, and am wondering which method would work best. Having thoroughly tested both implementations, I can say without a doubt that they are equal in every way, including speed, accuracy, smoothness, frame-rate, memory usage, etc. so which one is ‘better’ in the sense of overall maintainability?

EDIT: after reading the well-written arguments you all have made, I have decided to use a singleton. @JustinXXVII has made the most convincing argument (IMHO), although I consider every answer here equally worthy of merit. Thank you all for your opinions, I have upvoted all answers in the question.

Answer 1

I’ll make the case for a singleton object. Singletons are used all over UIKit and iOS. One thing you can’t do with categories is add instance variables. There are two things about this:

1. MVC workflows don’t tolerate objects with intimate knowledge of other objects
2. Sometimes you just need a place to reference an object that doesn’t really belong anywhere else

These things go against each other, but the added ability to be able to keep an instance variable that doesn’t really have an “owner” is why I favor the singleton.

I usually have one singleton class in all of my XCode projects, which is used to store “global” objects and do mundane things that I don’t want to burden my AppDelegate with.

An example would be serializing/archiving objects and unarchiving/restoring. I have to use the same method throughout several classes, I don’t want to extend UIViewController with some serializing method to write and read arbitrary files. Maybe it’s just my personal preference.

I also might need a quick way to lookup information in NSUserDefaults but not want to always be writing [[NSUserDefaults standardUserDefaults]stringForKey:@"blah"], so I will just declare a method in my singleton that takes a string argument.

Until now i’ve not really thought too much about using a category for these things. One thing is sure though, I’d rather not be instantiating a new object a hundred times to do the same task when I can have just one living object that sticks around and will take care of stuff for me. (Without burdening the AppDelegate)