On Tue, Feb 24, 2009 at 10:48 AM, Jon C. Munson II <jmun...@his.com> wrote:
> [Jon C. Munson II] With regards to the dox, and I'm not being grumpy or > "short" when saying this, if, situationally speaking, these things were > *explicitly* explained (and not just "conceptually" explained), I'd probably > have a better time of it. > I'm NOT one of those people who learn well from > reading technical documentation, particularly if that documentation is > geared more to conceptions than real-world/practical example. Is that truly your argument? There is API reference (the basic nuts and bolts describing the objects / methods available in the API) and the conceptual documentation that explains how it is best used (and the design methodology behind it). This is how the world of software development works. They are two different reference tools geared for the two primary necessities when learning a new platform (in the sense of language+architecture+API). It's a necessary evil you're going to have to accept because nobody on this list wants to spend time repeating or pointing to text that directly and clearly answers your questions (as you asked them, anyway). > This is why Hillegass' book was extremely useful to me as I could see the > concepts put to practice. This is essentially a tutorial. It's a third reference tool that's a helpful addition but not intended to replace the documentation when you need to understand more than what the tutorial covers (which is almost always the case in a real project). Since there's no completed Core Data reference book yet (Pragmatic Bookshelf has a book in development: http://www.pragprog.com/titles/mzcd/core-data ), there are only web tutorials, but again: that's not your problem. Your problem is that you need to go back to the basics of Bindings / KVC / KVO and learn them in detail because this is the basis of your problem. Essentially, you've watched a video on assembling a lamp from a kit, screwing in the light bulb, plugging it in, and turning it on. What you're now trying to do is design your own lamp with more complicated parts. Well, you need not only to read up on the intricacies of complicated lighting design (conceptual), but to look up the specs on each of those parts to see if they work together in the way you're imagining (API reference). No general lamp assembly tutorial is going to exist for your particular design and no assembly tutorial is going to teach you much more than you need to know (for assembly) about all the parts, how they were selected, why they work together the way they do, and how you might interchange some of those parts for more complicated things -- its' beyond the scope of the tutorial. In short, you STILL have to understand the concepts and frequently reference the specific components you wish to use. There is quite simply no way around this. > That being said, I did think there was some sort of message that > NSArrayController was responding to. I had hoped there was a method or > delegate method one could employ that would get implemented in response to > whatever message that is, but didn't see one. > > Not knowing which/what message to search for prompted the post. > > Having said that, and following with what you replied, I found this on the > 'net (typos not withstanding): > > [[NSNotificationCenter defaultCenter] addObserver:self > selector:@selector(managedObjectContextUpdatedNotification:) > name:NSManagedObjectContextObjectsDidChangeNotification > object:[self managedObjectContext]]; > > Assuming that goes in init, is this the correct message, etc., to be > listening for? No. This is a notification. This has nothing to do with Bindings / KVC / KVO. You can of course listen for this notification and react to it, but this is not what NSArrayController is relying on. Again, it's relying on KVO (because it's "O"bserving the Managed Object Context (MOC) keypath of either your application delegate (if Core Data Application) or your persistent document instance (if Core Data Document-Based Application). Again, this is the only Core-Data-related aspect of this use of Bindings (that it's observing the Core Data MOC, rather than some other KVC/KVO-compliant key). The MOC says a managed object changed, so the array controller sees if that change included anything it's interested in (instances of the entity it's managing) and re-fetches from the context. That's it. > Anyway, I do appreciate the time and patience of those on the list who do > take the time to reply and offer assistance. Then please show this by taking the advice we're giving you. Specifically, despite the fact you find it difficult, read all the prerequisite documentation anyway. Also refrain from declaring something is not covered in documentation you clearly did not read carefully, if at all - it's annoying to those who take the trouble to point it out to you when it's right before their/our eyes, plain as day. If you don't *understand* what you're reading, quote the part you don't get, state what you think you understand so far, and ask for clarification. -- I.S. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
