On Sun, Aug 15, 2010 at 12:08 PM, Matt Neuburg <m...@tidbits.com> 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 (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
