views:

721

answers:

3

Hey friends,

I am developing an iPhone app for some sweet undergrad research I've been working on. Sadly, my school doesn't offer software engineering / design classes so when it comes to questions of best practices in OO Design, I do a lot of reading.

My Dilemma:

My application loads a view (v1) where, upon user's button click, v1's controller class executes an action method. This action method should fill an array with objects. After that, the user will either execute the action again or click a different tab to load another view. Other views in the application will use the array that v1 populated.

So, where should this shared array be declared? Right now, it's in the AppDelegate class from when I was testing features without a GUI. Should I grab the AppDelegate singleton and add items to it in the v1ViewController? Should it be declared as static?

Thanks for the help!

^Buffalo

A: 

You could store it in an ivar in the app delegate. You don't need to make it static since the app delegate is a singleton anyways (there's never more than 1 instance).

If the app delegate is getting a bit complicated, you can factor out the data storage into a separate model object or perhaps use Core Data.

Daniel Dickison
+3  A: 

Using the app delegate to store data that's shared between views and view controllers is reasonable and appropriate.

In my apps, I view the app delegate as the controller part of MVC, with UIViews and view controllers all being part of the "view". I prefer to use a variant of MVC called Passive View that keeps the model and view parts of my app strictly segregated with only the controller connecting them.

I'm assuming that the array of objects you're storing is your app's model, so storing them on your app delegate makes sense. As Daniel D said, there's no need to make it static.

The app delegate is really the heart of your program. You create and initialize your model and views in your -applicationDidFinishLaunching: method and save your model data and view state in -applicationWillTerminate:. When your view controllers receive events that changes your model, you can call methods on your app delegate to make those changes.

Don McCaughey
Follow-up Question:When interacting with a singleton, which is the better way to talk to it:[[MyAwesomeSingleton sharedInstance] gimmeSomePizza];orMySingleton *s = [MySingleton sharedInstance];[s gimmeSomePizza];I guess what I'm wondering is, do you make the sharedInstance method call every time or do you define a pointer to the sharedInstance and then reference the pointer?
Buffalo
Either way is fine. In general, there's no detectable performance difference between the two. Choose the method that makes reads better to you.
Don McCaughey
A: 

Follow-up Question: When interacting with a singleton, which is the better way to talk to it:

[[MyAwesomeSingleton sharedInstance] gimmeSomePizza];

or

MySingleton *s = [MySingleton sharedInstance]; 
[s gimmeSomePizza];

I guess what I'm wondering is, do you make the sharedInstance method call every time or do you define a pointer to the sharedInstance and then reference the pointer?

Buffalo