Re: who stole my UIView?
Re: who stole my UIView?
- Subject: Re: who stole my UIView?
- From: Matt Neuburg <email@hidden>
- Date: Sun, 15 Aug 2010 12:08:18 -0700
- Thread-topic: who stole my UIView?
On or about 8/13/10 9:53 AM, thus spake "David Duncan"
<email@hidden>:
> -[UIView layer] has this to say: "Warning: Since the view is the layer¹s
> delegate, you should never set the view as a delegate of another CALayer
> object. Additionally, you should never change the delegate of this layer."
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.
> 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.
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.
>> All I was trying to do was save a little memory by not bothering to create a
>> bitmap and draw into it; I was just looking for a way to draw directly into a
>> layer's context (without subclassing). This seems like an innocent enough
>> thing to want to do...
>
> This can be accomplished directly using UIImageView and
> UIGraphicsBeginImageContext(). The data is marked copy-on-write, so you won't
> be using additional memory, provided that you are on iOS 3.2 or later (there
> was a bug in 3.1 and prior where UIGraphicsBeginImageContext() used a format
> that caused Core Animation to make a copy of the data).
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.
m.
--
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Exploring & Customizing Snow Leopard
http://tinyurl.com/kufyy8
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
_______________________________________________
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