Re: an interesting delegate design issue raised by IB...
Re: an interesting delegate design issue raised by IB...
- Subject: Re: an interesting delegate design issue raised by IB...
- From: "Michael B. Johnson" <email@hidden>
- Date: Wed, 12 Sep 2001 10:57:57 -0700
- Organization: Pixar Animation Studios
Ondra Cada wrote:
>
>
Michael,
>
>
>>>>>> Michael B. Johnson (MBJ) wrote at Wed, 12 Sep 2001 08:46:52 -0700:
>
MBJ> >[[view delegate] addImage:xxx]; [view reloadData];
>
MBJ>
>
MBJ> Actually, this is something I don't understand. My image view registers
>
MBJ> for notifications from its data source, and the data source sends out
>
MBJ> notifications when images are added, deleted, or updated, so a call to
>
MBJ> reloadData is unnecessary. This seems even cleaner to me - or am I
>
MBJ> missing something that my scheme will miss?
>
>
I guess this:
>
>
for (i=0;i<MANY;i++) [[view delegate] addImage:xxx];
>
[view reloadData];
>
Hmm, seems like a classic optimizing early problem to me :-)
*If* you implemented the response to the notification in the image view as "redisplay the view NOW"
then the one you propose (and Apple uses for similar cases) make sense - it would be silly to pay
for a redisplay for every image (although one could argue that that *is* what you want). But nobody
does that. You would implement it like this:
- (void)respondToNewImageNotification
{
[self setNeedsDisplay:YES];
}
which means that the next time through the event loop the image will get redrawn. If you're in a
tight loop, adding images, you will just end up marking the image dirty n times, and then get one
redraw at the very end, unless you're adding them in another thread (certainly a possibility), but
in that case you'd probably get a nice interleaving of images being added and new ones showing up in
chunks (like I said, you could argue for this). And for that case, I already have a addImages:
method, if I really did just want to add a bunch of images in one fell swoop.
>
Of course, you can send those notifications using NSPostWhenIdle, which
>
would easily solve this problem (but not some more elaborated ones).
>
like what? I'm interested - I wouldn't do it this way, but I'm interested in what problems might
arise from doing it this way.
>
OTOH, the "automatic display" is a very nice thing generally and I would
>
keep it; adding a method "addImageWithoutNotification:" or alike would cover
>
IMHO all needs perfectly.
Ooh, I really don't like that. It would be too easy to have things get out of sync.
I can see in a database context, where it's not as much about instantaneous feedback about what's
happening, but rather a desire to conduct transactions very efficiently, that you want to leave this
optimization to the programmer, but in this case (and most others I can think of, but I'm an
animation systems guy, not an enterprise database guy) my way is cleaner and more correct (i.e. less
likely to have the model and view get out of sync).
- wave