Re: is this possible in iOS with constraints?
Re: is this possible in iOS with constraints?
- Subject: Re: is this possible in iOS with constraints?
- From: Matt Neuburg <email@hidden>
- Date: Fri, 02 Nov 2012 11:17:56 -0700
Aha. Yes, I did notice that I couldn't make constraints involving e.g. the built-in textLabel object; it's as if it wasn't even in the interface.
The second part of your answer, that not being in the view hierarchy means the autolayout engine won't operate, is the answer to my original question; as I suspected, what I'm trying to do probably just can't be done. Ah, well. It was clever…
I wonder if it would be worth my asking for a feature? Surely I'm not going to be the only one who would like to take a hierarchy of views that's *not* in the interface and ask it to exercise the constraint engine to see where everything ends up. m.
On Nov 2, 2012, at 10:41 AM, Luke Hiesterman <email@hidden> wrote:
>
> On Nov 2, 2012, at 10:22 AM, Matt Neuburg <email@hidden>
> wrote:
>
>>
>> On Nov 2, 2012, at 10:14 AM, Luke Hiesterman <email@hidden> wrote:
>>
>>> UITableViewCell doesn't currently support autolayout
>>
>> I guess I'm having a little trouble understanding what that means. I am placing content interface inside the content view of a UITableViewCell and handing constraints to the cell, and autolayout is working perfectly on that content: the content is repositioned when the cell gets wider and narrower (interface rotates) and it is enlarged vertically when the height of the cell is set. So you must be using "support" in some refined sense that I don't grasp. Can you expand a little? Thx! - m.
>
> Direct attempts to put constraints on direct subviews of the cell will crash, and any attempt to put a constraint on the frame of the cell itself wouldn't make any sense because a cell is either A. in the table view, in which case it's sized by the table view and not constraints, or B. it's not in the view hierarchy, in which case the autolayout engine won't do anything for you.
>
> Luke
>
>>
>>> , so no, you won't be able to have the constraints system calculate the height for you.
>>>
>>> Luke
>>>
>>> On Nov 2, 2012, at 10:10 AM, Matt Neuburg <email@hidden> wrote:
>>>
>>>>
>>>> On Nov 2, 2012, at 9:03 AM, Luke Hiesterman <email@hidden> wrote:
>>>>
>>>>> Cells are sized according to the value returned from heightForRowAtIndexPath:
>>>>
>>>> Obviously. And that is why I am calculating (in advance) the value that I will return from heightForRowAtIndexPath:. I've been doing that for years. The question is, though, can I now (iOS 6) have the constraints system somehow calculate that value for me, merely by putting the ultimate values into the labels of a test cell that isn't in the interface?
>>>>
>>>> The code I'm using now is at
>>>>
>>>> <https://github.com/mattneub/Programming-iOS-Book-Examples/blob/master/ch21p622variableHeights/ch21p622variableHeights/RootViewController.m>
>>>>
>>>> As you can see, I'm hard-coding the numbers in my precalc routine (viewDidLoad). Basically, I'm *guessing* what the constraints *will* do when I later give the cell height (using heightForRowAtIndexPath:) and the label resizes because of the constraints. What I'm saying is, how about if I perform the precalculation the opposite way, i.e. by resizing the label and letting it resize the cell? But I can't find a formula to do that. The code below (in this email) shows the sort of thing I've tried. m.
>>>>
>>>>>
>>>>> On Nov 2, 2012, at 8:07 AM, Matt Neuburg <email@hidden> wrote:
>>>>>
>>>>>> Okay, I have this wild and crazy idea. I've got a UITableView with cells that have different heights. The cells' content consists almost entirely of UILabels, and the height of each cell depends on what's going to go into those labels - the cell needs to grow to accommodate the text of the labels. The way I've always done this in the past is to calculate how the labels will be drawn, using NSString sizeWithFont etc, and then lay out the labels and calculate the needed cell size.
>>>>>>
>>>>>> But it occurs to me that in theory constraints could do all the work for me. I'm already using constraints to resize the actual labels when the cell changes size to assume its final height, but maybe I could use constraints to *make* cell assume its final height based on the content of the labels. The cell is in a nib, so if there were just one label, the code might be something like this:
>>>>>>
>>>>>> NSArray* objs = [[UINib nibWithNibName:@"Cell" bundle:nil] instantiateWithOwner:nil options:nil];
>>>>>> Cell* cell = objs[0];
>>>>>> cell.bounds = CGRectMake(0,0,320,50);
>>>>>> cell.lab.text = // whatever the actual content will be
>>>>>> [cell.lab sizeToFit]; // or something :)
>>>>>>
>>>>>> The idea is that the label will assume its final size and the existing constraints will push the cell height larger as needed. Okay, but it isn't working; the cell isn't growing.
>>>>>>
>>>>>> My theory is that this probably *can't* work because the auto layout stuff doesn't kick in unless the view is actually in the interface, which (as you can see) it isn't. And probably not until the next run loop, either, which is not good enough; I need to run through a whole lot cells and do this, right now, to calculate all the cell heights in advance of the table appearing.
>>>>>>
>>>>>> So, am I right that this is just impossible, or is there some cool way to do it that I just haven't stumbled on yet? Thx - m.
>>>>>>
--
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