Re: who stole my UIView?
Re: who stole my UIView?
- Subject: Re: who stole my UIView?
- From: Kyle Sluder <email@hidden>
- Date: Sun, 15 Aug 2010 12:40:55 -0700
On Sun, Aug 15, 2010 at 12:08 PM, Matt Neuburg <email@hidden> wrote:
> My point with regard to this warning is merely that I was never *in* the
> UIView class documentation. The warning needs to be, or be repeated, in the
> CALayer class documentation.
But you were mucking with a UIView's layer tree. I would assume
familiarity with the UIView documentation before doing such a thing.
>> In general however, it is advisable to treat objects that are created on your
>> behalf as at least somewhat special, in that you don't know the full extent of
>> the dependencies that the creator setup on that object. You weren't just
>> working with a CALayer here, you were also working with a UIView and you need
>> to be mindful of its requirements as well.
>
> Perhaps, then, this property should not have been called "delegate". I mean,
> what I'm learning here about the CALayer delegate is completely contrary to
> the nature of delegation throughout the rest of the Cocoa frameworks. In
> general the whole point of delegation is that you get to appoint a delegate
> and get called back to influence the behavior of an instance without having
> to subclass. There is complete freedom on how you do this. And so that is
> what the programmer naturally expects in this case as well.
CALayer isn't part of UIView. As far as CALayer is concerned, its
delegate is just a regular, run of the mill object. It's the UIView
that is imposing special meaning on the layer's delegate.
> This is the only case I've ever run into where there are these hidden rules
> on not changing the delegate - because the delegate property is essentially
> misused to form the view tree.
Layer-backed NSViews do the same thing. It's just dangerous to muck
with relationships between objects that you didn't set up if you don't
know what you're doing. It's not a misuse of delegation at all.
Would you have preferred if CALayer had special private hacks to
integrate with NSView and UIView?
> That's very good to know! Still, a full-fledged UIImageView seemed too
> heavy-handed. My idea was to put up a vanilla UIView and draw directly into
> its layer using drawLayer:inContext:, thus never having to summon up an
> extra bitmap or context at all. Luke's clue that the way to do this safely
> is to go view->layer->layer and set the delegate of that *second* layer is a
> great solution.
Since UIViews are well-documented to be the delegates of their layers,
why not just implement the delegate methods in your UIView subclass?
Alternatively, override +layerClass to return an appropriate CALayer
subclass, and configure this layer instance from within your UIView
subclass.
--Kyle Sluder
_______________________________________________
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