iOS Core Data Architecture tips wanted

Question

I just want to get a few pointers on the best way to architect my first Core Data app, and the main objects and interactions I will require.

The data is stored remotely

Answer 1

Thanks dtuckernet, here is what I did do - gathering info from lots of sources, which I believe is the best solution. Anyone feel free to criticise (constructively)....

1. I have my Core Data stack in CoreDataStack.h (singleton) - not entirely necessary, but it unclutters my app delegate class.
2. I have a base CoreDataBackedTableViewController : UITableViewController
3. Each of my table view screens extends CoreDataBackedTableViewController and have an ivar to a ModelController class.
4. An example ModelController class has a - (NSFetchedResultsController *) getData method which constructs the NSFetchedResultsController (also keeps a ref to it) and returns it to the view controller which also stores it in CoreDataBackedTableViewController (which listens for updates and edits to the data). Having the ModelController class allows me to encapsulate my data access to potentially have 2 different view controllers use this (iPhone and iPad perhaps)
5. In getData - i make a call to my backend webservice asynchronously. Using delegates for callbacks
6. The backend is using SBJSON for parsing and NSHttpConnection and a hand rolled HttpService class.
7. When the backend returns with data, it calls the delegate on the ModelController which updates core data - and my fetchedResultsController knows about this and automatically updates my interface ! How cool is this bit - not a lot of effort involved on my part. I have to do some detection on whether i've already downloaded the data before or not to avoid duplicates.
8. Ready to roll this out to the rest of my app....

If anyone wants any clarification on any of the steps, just let me know.