Re: Newbie Object Sharing Question
Re: Newbie Object Sharing Question
- Subject: Re: Newbie Object Sharing Question
- From: Joseph Crawford <email@hidden>
- Date: Fri, 30 Jan 2009 22:50:10 -0500
Sorry I misunderstood the question then :) Just a newbie trying to
lend a hand where I can. Thanks for correcting me.
Joseph Crawford
On Jan 30, 2009, at 9:47 PM, Ken Thomases wrote:
On Jan 30, 2009, at 1:51 PM, Joseph Crawford wrote:
Why don't you create a base controller that those 2 controllers
subclass, that way they would inherit the functionality of reading
those properties, also they would inherit the methods for getting,
setting, etc.
BaseController
-- Controller 1
-- Controller 2
in Base controller define those properties and any methods for
interacting with them
in Controller 1 and Controller 2 have your Class specific stuff
there, because they both inherit from BaseController you would get
those properties.
This is completely irrelevant to the original question. Having a
common base class does not make two objects share state.
On Jan 30, 2009, at 2:46 PM, Brian Slick wrote:
I want both view controllers to reference MyListItemArray.
You want both view controllers to reference _an instance_ of
MyListItemArray. MyListItemArray is a class.
So in each one I do something like:
MyListItemArray *listArray = [[MyListItemArray alloc] init];
As you seem to have figured out, this is creating (allocating and
initializing) a new instance of the class. This newly-created
object is separate and distinct from other objects in your program,
even ones created by execution of this same line of code at other
times.
[...] It starts to sink in that what I have done is create a
*local* instance of MyListItemArray in each view controller, and
what's local to ViewControllerTabA has nothing to do with what is
local to ViewControllerTabB. I'm getting local copies of the
array, not the source array.
As near as I can tell, there is no "source" array, nor is there any
copying going on.
You have explicitly created two separate arrays from the get-go.
You have then filled them out separately to have similar initial
contents.
It starts to occur to me that I don't actually want an instance, I
want the real deal.
That statement is nonsensical. There is no "real deal". An
instance is real. It's not some pale reflection of something else.
You do want an instance.
I suspect that perhaps you don't understand the difference between
an object and a pointer to an object. The reason I suspect that is
because the simple solution to your dilemma, the thing you're not
seeing, is that you want a single instance referenced from multiple
places using multiple pointers.
I read through some documentation about model objects and objects
in general, and stumbled upon the concept of Singletons. Some
additional searching lead me to this blog post:
http://cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html
...which seems to describe exactly what I want. I reconfigured
MyListItemArray as a singleton, and remapped my data source
methods accordingly, and everything seemingly works perfectly.
Items added in one view are displayed in the other, and so on. It
works so well that I have to assume there is a catch.
I can't shake the feeling that this seems more difficult than in
ought to be, and generally when I feel that way there tends to be
a single line of code solution that I haven't found yet. Are
singletons really the only way (that doesn't involve saving to a
file, I suppose) to share a model object across multiple view
controllers? I think I'm missing something really fundamental.
Yes, I think your are missing something fundamental -- the ability
to share references to an object simply by assigning multiple
pointers to point to the same thing.
A singleton implementation is _one_ solution to the issue you're
having, but it's not necessary, and not even recommended for
something as simple as this.
One stumbling block is that you have two view controllers, but
evidently no central application controller. View controllers
should have logic and state specific to a view and that view's
relationship to the model. An application controller manages your
application overall. It manages the other controllers, including
your view controllers. It has the primary responsibility for
managing the application-global (as opposed to, for example,
document-specific) model, and for providing access to that model to
other parts of the program.
Since you were concentrating on the view controllers, you thought
you had to create the instance of MyListItemArray in each view
controller. It follows that you got one such instance for each view
controller.
You should have a single application controller object (an instance
of some custom class). This application controller is often also
the application delegate. It is also often instantiated in the main
nib, where the "delegate" outlet of the main application object is
connected to it.
If your application has one central list of items, then it would be
the application controller's job to create and load that model. It
would hold references to the model objects in instance variables.
It would provide access to those model objects to other parts of the
program. One way would be to pass the references in to the view
controllers when those view controllers are initialized. Another
way would be for the application controller to expose those
references through properties and have the view controllers
reference those properties -- the view controllers would need a
reference to the application controller to do that. Again, they
could get such a reference by being passed it, or if your
application controller is your application delegate, they can obtain
the reference using [NSApp delegate].
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden