As already suggested, you could subscribe to NSManagedObjectContextObjectsDidChangeNotification
and try to analyze it. I see two disadvantages in this. First, this notification is called a lot and on any change in any object. Calls will not literally happen at the moment when the change happens, but still any change is reported in this notification. Second, the subscriber needs to know all the contexts where the new Book is created. You might think of subscribing to this notification with nil for context to receive this notification for all the contexts. But this is even more overwhelming and dangerous, and not recommended by Apple (you will receive this notification also for the contexts that you don’t own).
What I would recommend for each place that creates a Book to have its own notification. Like XYBookAddControllerDidAddBookNotification
, XYBookListControllerDidDeleteBookNotification
and so on. In this case:
- The place that displays counts doesn’t have to know anything about the context where change was made.
- The place that displays will only respond to specific add/remove events instead of analyzing heavy traffic of objects-did-change notification.