views:

61

answers:

5

I am working on an iphone application and don't know what the best way to hold temporary data across views. for example i have xml on a server and i parse the data into an object so that I can hold the information. The xml has some data that i want to be displayed on one view and other data that i want to be displayed on another view. I have a class called dataStore that I want to hold the data across the views, what is the best iphone practice to do that?

I have looked into many options and I think its a choice between:

1) use the dataStore as a delegate and hold the data in a delegate thaat can be accessed.

2) use the dataStore as a singleton class and only allow one instance of the class and access the data from the shared instance of the dataStore class.

3) maybe even an NSMangedObjectContext which i dont know about but am familiar with the android way of passing data through an application context and instance.

If someone could help me with choosing which is the best practice on the iphone i would be much greatly appreciated.

A: 

I prefer the singleton solution as it adopts the Foundation behavior. This makes the whole code much cleaner and as you are working in an view based application, you also follow the model-view-controller convention.

JustSid
A: 

In your case I'd recommend turning the dataStore class into a singleton. In the singleton, parse the data and have methods that return the required information for the view. Core Data (managedObjects) are good if you want the data to persist across launches. While common, storing data in the appDelegate is last option I'd pick.

Jordan
A: 

None of those are truly MVC. You want three classes:

  • The model, which contains the data,
  • The view, often done entirely in IB as a .xib,
  • The view controller, which is the .xib's File's Owner and has the data as an instance field. This one is responsible for passing the model's data to the view, and the view sets the view controller as its delegate and dataSource. This way, the view can be reusable, and only ever handles a fraction of the data (i.e. exactly as much as is actually visible).
Sören Kuklau
I am trying my best to implement the Model View Controller design pattern by having the views designed in interface builder and then having viewControllers but also have the view controllers interact with Data Access Objects(DAO) that in return interact with the datastore only and return data to the view controllers. So my confusion lies in implementing the model, what consists of an iphone data model?
Dan Ellis
The model defines the data, so in your case, it would handle downloading from the server, parsing the XML, turning it into an object you can handle (this may then be accessed by the viewController), and all that backwards in case you wish to send data back to the server.
Sören Kuklau
A: 
  1. No you can not let the dataStore be a delegate. You should never retain your delegates, so it is not a good place for data, only for behavior.

  2. Most probably a singleton. What you have here is probably a model fro your app, is there any reason why your app should be able to handle two models? Can it show many documents simultaneously? Do not write a single line of code in order to try to stop a client of your singleton from creating a second instance! Objective-C is a dynamic run-time and a persistent user will be able to anyway, so all your code do is add more lines of code with potential bugs.

  3. Do not bother with Core Data and a NSManagedObjectContext until you really need to. And you only need to if you intent to handle more data in your model than can ever fit into RAM.

PeyloW
+1  A: 

You could announce that the data has arrived using an NSNotification. You can send the temporary object along with the notification, as either the sender or in the info dictionary. The two objects that need parts of that data can then pull those parts out and retain those right then, and the temporary data object can be just that: temporary, lasting only till the notification is complete. Only the parts your views need and care about hang around, and each view controller can release its part whenever it makes sense.

Jeremy W. Sherman