iPhone design: Multiple tableviews of a single datasource

I have an app that is working, but I'm not happy that I've got the best (or simplest) solution in place. The app has a single database with a number of tables with typical one-to-many references. So far so good and nothing unusual.

The app has 3 tabs, each one can display a list of records from one of the tables. If a user touches a table row the navigation view on the tab then pushes a new table view showing the details. Think of you address book and you get the idea.

On the details view of a record I've got sections containing the links to records in the other tables. So touching one will navigate to that record, changing to the appropriate tab.

The tricky bit is when editing a record, because it can affect the data displayed on another tab. Originally I looked into performing updates to table views based on the core data changes sent through from the core data saved notifications. However I found that working out what changes needed to be made to a table view based on that was too difficult and unreliable. mainly because I don't have a before and after data graph to compare. So currently when a cor开发者_Python百科e data save happens, the table views just remember that their backing data may have been affected and they do a full reload on next display.

Whilst my system works for keeping the data in sync across the table views, I'm sure there must be a better way. I'm considering whether KVO might be the better option with table view controllers tracking individual fields and objects within the data graph so they can respond to precise changes triggered by other table views. The core data notifications approach feels a bit like a hammer approach to a problem that needs a subtle tap.

How have others dealt with this sort of issue?

Your confusion is caused because you are trying to think of Core Data in SQL/Relational-DB terms.

Core Data is not SQL. Entities are not tables. Objects are not rows. Columns are not attributes. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.

The solution to your problem is simple: You just have all tabs use the same managedObjectContext. If each tableview is populated by a NSFetchedResultsController, the FRC should automatically update each tab's tableview with changes made in other tab's views because the FRC automatically receives managedObjectContext notifications.

In any case, notifications are the way to go. For example, if you have a managed object displayed in one tab that is somehow edited in another, you can have that tab's active view controller register for a NSManagedObjectContextObjectsDidChangeNotification.

However, you might want to change your design. The interface grammar does not teach users to expect a lot of side effects from changes in one tab showing up in another. Neither does it do automatic tab switching. Tabs should only be changed under user action.