I am working on a multiple view controller scheme and a user may change a value shown in the deepest view. Say A is top, B is second and C is third.
When using a navigationbar in C to return to B, a table reload in A must be performed. (the table is small, so I don't bother with optimizing to update one row only).
Using a protocol, I suppose C should offer a protocol and A can use a delegate to carry it out in a function like 'someRowIsUpdated'. The disadvantage in my opinion is that A should include a header of C to know that protocol. When adding some other controller, say some sibling, one must update the source of A, a开发者_如何学Godding an extra include. This seems the wrong way to me.
An alternative would be to pass some id downwards from A when instantiating B and C when B instantiate C. That seems quite clumsy too to me.
When C wants to notify A to do something, what is the best way? Notification? I'd prefer to have C include a header from A, not the other way around.
Any thoughts?
Notification indeed seems to be the most essential solution here, I think. It also gives you good flexibility if you'll want to change something later.
This being core data, you have to be careful with notifications. The reason is that core data should not be used on multiple threads because of certain locking mechanisms of the underlying persistent store.
Thus I would recommend passing a unique NSManagedObjectContext
down the controller chain, and even an appropriate NSManagedObject
subclass for convenience. There is no need to refer to or communicate with a parent controller if you have access to the data model. This is also a much better design pattern.
You will find that the few lines of code for #importing
classes and declaring properties will end up being far less than dealing with notifications. (IMHO, also far less "clumsy". ;-))
精彩评论