On Jul 14, 2009, at 02:14, Christopher Campbell Jensen wrote:
So what is needed is for me to be able to pass this "narrowed down
data" from one view to another in a way so that the next view can
make changes/further refinement before passing it on to the next one.
Now the question is, how do I do this? Will I have to either:
1. Create connections between the three sub-views by creating them
all, then passing in pointers to the other two to each of them?
2. Each view passes the current "narrowed down data" back to the
super-view (MainViewController), and have him pass it on to the
relevant sub-views
3. Can this "narrowed down data" be somehow temporarily stored in
core data so that each view only has to access the MOC and ask for
the current "subset"?
I am sure it is becoming pretty clear that I really don't have my
head wrapped around how core data functions, and it's abilities. My
reasons for choosing to use core data, is it seemed the most
sensible way to achieve easy lookup of data together with persistent
storage. Plus it's one of the core frameworks, and makes sense to me
to maximize my learning benefit by not avoiding them :)
Nope, it's not a core data matter. Your difficulty is a conceptual one
with the MVC design paradigm.
Your data model exists independently of the views. Typically, it is
the responsibility of the controller to link the data model for any
view that wants to use it, and there are two patterns for that:
coordinating or mediating controllers.
The data model provide an interface (an API, if you will) to the
"outside world" (the controllers and views). It's responsible for
maintaining its own integrity, and it doesn't care who uses its "API".
Thus, if the search view re-selects a different subset of core data
entities (classes) for the other views to use, it tells the data
model, which reconfigures itself. The change of state must then be
propagated to all other API clients (i.e. views and/or controllers)
that care. That mechanism is typically KVO (that is, the clients are
registered to observe changes in specific data model properties) or
notifications (the clients are registered to observe broadcasts from
the data model).
You should be very familiar with the concepts in:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
before proceeding. You *can* design applications without following
that approach, but you'll miss out on what Cocoa gives you for free.
Also, you may want to try this without core data first. Starting with
core data is very much jumping in at the deep end before you can swim.
It's not even clear that core data is the correct technology -- you
seem to really need an underlying database, not so much a
sophisticated object-graph management system (though I may easily be
wrong about that). Core data is *not* the former, but *is* the latter,
with persistence.
I'm not trying to be discouraging. With enough smarts, you can come up
with a solution by brute force. But if you want to use what Cocoa has
to offer, it really is necessary first to know what Cocoa has to
offer. :)
_______________________________________________
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
