Re: what happens when layout constraint height and frame height conflict (iOS)?
Re: what happens when layout constraint height and frame height conflict (iOS)?
- Subject: Re: what happens when layout constraint height and frame height conflict (iOS)?
- From: Matt Neuburg <email@hidden>
- Date: Mon, 26 Nov 2012 12:57:40 -0800
My view does not translate its autoresizing mask. But you are confirming my suspicion that some issue is lurking here. I wonder if it wouldn't be better if some kind of runtime warning were issued when I do this sort of thing...
It would help me if you could suggest a method call that would exercise the constraint system, e.g. perhaps causing the frame to snap back to height 36, thus proving to the student that this behavior is problematic. I tried things like layoutSubviews and layoutIfNeeded but nothing happened. Thx -
m.
On Nov 26, 2012, at 12:37 PM, Kyle Sluder <email@hidden> wrote:
> On Mon, Nov 26, 2012, at 10:46 AM, Matt Neuburg wrote:
>> I have noticed by experimentation that if I have a layout constraint on a
>> view that sets its height at (say) 36, I can later change the view's
>> frame in code to set its height at (say) 50. The view's height does
>> visibly change, but logging proves that the layout constraint does not
>> change.
>>
>> (1) How can this be? The view would appear to be violating its own layout
>> constraint.
>
> Constraints don't care about the view's frame. They only care about each
> other. When the constraint system runs, it calls -setFrame: on the
> views. It never pays attention to what values they have.
>
>> (2) More important: Is this a bad situation? In other words, once I've
>> decided to use layout constraints at all, must I then use them for
>> everything and avoid frame/bounds? Can something bad happen later because
>> of this conflict?
>
> Yes, this is a bad situation. You should use constraints. You run the
> risk of your views being resized whenever the next layout pass is
> triggered.
>
> Additionally, my statement above is a lie: constraints don't care about
> the current frame of your views, but if a view is set to translate its
> autoresizing mask into constraints, and either the X or Y dimension is
> not fully stretchable, it updates these constraints' constants with the
> values from the frame whenever the frame changes size.
>
> So that means you CAN cause a conflict by calling -setFrameSize: on a
> view if you're still mixing constraints with autoresizing-mask-based
> layout.
>
> --Kyle Sluder
--
matt neuburg, phd = email@hidden, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
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