Quote:
Originally Posted by eddietr
Yeah, so I can describe something I did in general terms.
So we had a bunch of items on a server that users could view and edit and add to and then we would sync those items back to the server.
So the items are model objects. But those models don't need to know about all the issues with transport over the net (codes as JSON in our case) and nor did they need to know how to deal with failures (phone network disconnects, server is slow, server is down, etc.)
And the models themselves didn't need to deal with the issues of merging updates and changes.
So on both the phone side and the server side, we had these model objects. Which were managed by a controller that exposed what looked like a simple array of those objects. That controller hides all the complexity behind that. That controller also takes care of dumping objects from memory when we're tight for memory, and reconstituting those objects when they are needed again and so on. It hands out proxies to objects when they aren't immediately available so the user interface is always smooth.
Internally the controller knows what to do with inserts and updates and merges and that sort of thing. And that controller uses another controller that deals with the specifics of managing the network and queuing network operations that can't happen at the moment for various reasons, etc.
And then our view controllers just need access to an array of stuff (and be notified when that stuff changes). They don't care about any of those details. They don't care if the objects they are getting are real or proxies. They don't care if those objects are coming from local cache or the network itself.
So we have a single instance of an "array" controller that behaves like a simple mutable array. A pointer to that instance is stored in the app delegate. In turn, that controller uses another controller to send and retrieve actual objects from the server.
There's a little more to it than that, because the controllers have helper objects for certain things. But I hope that at least gives you a high level real world case.
|
Very good explanation!
So, on the iPhone (or the server, for that matter), a View or VC that wants to access the "array" does so by referencing the appDelegate. In effect, isn't the appDelegate acting as the "model" even though it has subordinated the creation, maintenance and manipulation of the "array" to other classes?
What happens if a VC wants to search or sort the array for presentation does it do that itself, or request it from the "model" controller through the appDelegate?
Quote:
|
But that would be a nice project. It's not a huge amount of work, but it is work to make it generic enough to actually be useful to other developers. Would you help with it?
|
.
I would gladly help in any way I can. I am relatively new to Cocoa, but I understand the concept and see the need to define "where to put the data and the methods to manipulate it".
I have 2 apps (of sufficient scope) in development which would benefit from this.
TIA Dick
