I’ve been playing around with iOS development and I’m getting to the stage where I want to create something beyond a simple app. However, I’m not confident that I understand how to partition an application correctly.
For the purposes of simplicity, imagine a (very) simple audio player application. Let’s say there are two view controllers, accessible via a UITabBarController which is instantiated the main AppDelegate class.
Each of these view controllers has the following responsibility:
-
PlayerViewController – A sound player which plays the “current” audio sample when the user presses a button.
-
SelectorViewController – A sample selector, that uses a UIPickerView to display the available audio samples so that the user can select which sample they want to play.
So far, so good. However, what I don’t quite understand is where I should store the data on the available samples, so that both of the views can find out information on the available samples, trigger a sample to play, etc.
As both view controllers need to access this “model level” information, would creating an “audio manager” singleton class be a sensible approach, or is there (much, much more likely I’m guessing) a better means of solving this problem that I’m overlooking.
Any pointers would be much appreciated.
I’ve used this pattern (Singleton data manager) several times in serious apps. It’s quite straightforward, easy to understand, easy to use, although this pattern is despised by OOP purists.
If nobody tells you it’s wrong to use a singleton, go ahead, just be sure to check Apple’s documentation on the recommended implementation (there is a bunch of methods to overload).
Oh and BTW, Apple uses it a lot in the iOS SDK, so it’s a common practice (see class methods beginning with ‘shared’).
UPDATE:
Another possibility is reusing an already existing singleton, the Application delegate for instance. It might feel cleaner, or not, it’s more a matter of taste. It has the advantage of giving a clear “entry point” where you allocate/create/init your data manager.