Well it's nothing terribly magical, and I'll assume that anyone reading this can parse out the header vs module code and that stubs of course have code in them, but maybe this will help the idea:
>snip
Got it!
It seems as there 4 stages of evolution of the Model.
1) Define data in the View/VC that uses it (or anywhere else that makes sense) -- works for examples and simple apps.
2) Load up the appDelegate with data definitions and the methods to manipulate them-- where I am.
3) refactor the Model definition/methods out to separate class(es)-- where exorcyze is.
4) design speciality classes to:
---- define the data (the model)
---- define the methods (and external interfaces) that act on the data (the Model Controller)
where eddietr is.
What is interesting is that (in 3 and 4) the appDelegate becomes the point-guard (distributing the ball) without being overloaded with unnecessary complexity (neither are the VCs or the Views).
i think I like this... It makes sense... I can implement as much (or as little) as I want to support a specific app, without feeling like I am going down a bad-practices blind alley.
As with all things, it is better to understand both ends of the spectrum when deciding to implement a technique.
exorcyze-- thanks for sharing your work... it really helps to show the way!
eddietr-- look forward to your tutorial/solution... I may not need to implement it for every app, but (hopefully) I can code even my most basic apps in such a way that they can easily be extend to a Model/Model Controller implementation.
Realistically. if the eddietr solution is not too expensive, I will implement it in every app for reasons of consistency, standardization and ease-of maintenance.
Just to clarify - I still have seperate model classes broken out. I also have a controller to manage the collections of those, and a controller for managing the marriage of those data collections to the database.
From what it sounds like to me, the primary difference in my approach from what eddietr is doing is that I have the last two combined ( collections and data access methods for populating them ), and I don't have a layer for managing proxies etc. My data connections were local in this case, so I didn't need any additional level of complexity in there. =)
Just to clarify - I still have seperate model classes broken out. I also have a controller to manage the collections of those, and a controller for managing the marriage of those data collections to the database.
From what it sounds like to me, the primary difference in my approach from what eddietr is doing is that I have the last two combined ( collections and data access methods for populating them ), and I don't have a layer for managing proxies etc. My data connections were local in this case, so I didn't need any additional level of complexity in there. =)
Thanks for clarifying-- I went back and reread your post.
It appears that your approach will do the job nicely for most apps.
Thinking out loud here:
I started out (following many of the examples) putting my model definition/data/methods in the View Controllers where they were first needed.
Later, frustrated by the difficulty of accessing them from other places in the app and spurred by the need to save and restore data at termination and startup, I moved the model to the appDelegate.
This works fine, except it kinda' feels wrong-- too abstract, and the appDelegate gets humongous & confusing in an app that uses multiple classes of data.
That's where I am today.
The next logical step in the evolution of my apps will, likely, be to your approach.
Again, this should suffice for most apps.
I also have a need to periodically update/synch the model to/from an external source. This could range from several times per hour to one time per day.
From his description, it appears as if eddietr has a solution that handles real-time dynamic data (stock market quotes, baseball scores, multiplayer games states, etc.).
While this is more capability than I currently need, I can see advantages to using such an approach. It should be able to handle the periodic update/synchs with ease.
I am interested in seeing the eddietr solution. While it may be overkill for most apps, it will be useful to understand what is required to deal with "live" data.
Yup, if I needed something more robust than simple data access ( caching, etc ) then I would just either put another layer in for the retreival of the data that would handle it, or have some helper classes that those methods use ( if it needed to be on a case-by-case basis ).
Just wanted to say a quick thanks to coondog for starting this thread, and eddietr, exorcyze, and dicklacara for all the information. This has been one of the best aids I've had in iPhone programming so far.
I've been muddling for a few weeks through exactly these same sorts of questions, and struggling through exactly the progression of data-model sophistication that dicklacara described.
They talk about best practices for data flow within your application and specifically, between view controllers. In short, using the application delegate, global variables and singleton methods are all bad practices. Instead, communicate only the data that needs to be communicated to the next view controller via properties or custom initializer methods in the view controller that is being pushed onto the stack.
Linear Mode
