Re: NSOperation and lazy loading
Re: NSOperation and lazy loading
- Subject: Re: NSOperation and lazy loading
- From: Graham Cox <email@hidden>
- Date: Tue, 15 Sep 2009 14:30:36 +1000
On 15/09/2009, at 2:18 PM, Christopher Drum wrote:
So what is the recommended architecture for the original requester
to remain interested in receiving the image when it finally finishes
loading? I believe I need the requesting object to register for a
notification of some sort, which means that in order to receive the
image from a Person object, the requesting object must handle both
cases: the image is immediately available (because the Person object
cached it) or the image is currently nil but will be ready later. If
that's the case, then why would I ever do anything BUT listen for
notifications? On the other hand, that seems like a strange
architecture when all I want to do is ask an object for some piece
of data, which may be cached and ready to go the next time its
requested!
Am I just thinking myself into circles here? Am I perhaps (and this
is very likely) making this harder than it needs to be? NSOperation
seems to be very easy to use when the object that needs some work
done spins off its own NSOperation to do that work, but when there
an extra layer of abstraction the process gets confusing quickly.
Hi Christopher,
An easy way to handle this is to give your object a full image
property, e.g. it also has a -setImage: method. The client is an
observer of this property, via KVO or bindings. When the image is
loaded, it calls its own -setImage: method (via the main thread) to
store the image which also notifies any observers that the image has
changed. They can then request the image again or just grab its new
value from the KVO notification.
--Graham
_______________________________________________
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