I know that to enable self-sizing we need to set to estimatedRowHeight a specific value but I can't get the purpose of doing it. For example, what if I set the property to 600 but my actual cell size is only 40 ?
In my projects, I always set a random value to it and it works well.
Please explain to me, I'm very curious. Thank a lot.
It is used to estimate the height of the content view (not the table view's size itself). Table view needs to know the height of its content to allow scrolling smoothly without actually loading all the cells. If your estimatedRowHeight is quite different from the real cell's height, then when you try to scroll you may see the scroll indicator flickers. Or when you try to reload table view, the high possibility that you may see the cells appears in a weird way and with unexpected animations.
It helps auto layout prepare an initial value for the display until the actual height is being calculated by the constraints you set to the elements inside the cell from top to bottom
Related
I tried to make self-sizing cells. I got it to work but with some bug. Which I think is because of wrong constraits. So I kindly ask you if you could look them.
Problem is that after scrolling in tableview, all my views are going to stretch. I thought that it would happen because of not setting height constraint but it seems not to be problem.
Illustration(pretty normal):
After scrolling and coming back up:
And these are my constraints for this view which all of them looks good to me:
And if you want to know how I made cells to resize, then like this:
tableView.estimatedRowHeight = 105//Because my row height is 105
tableView.rowHeight = UITableViewAutomaticDimension
When this sort of thing happens, the implication is that you are not supplying sufficient constraints to size the cell's contentView from the inside out. You can readily confirm this using View Debugging to pause the app when you see your incorrectly sized cell; you will then be able to study the actual values of your constraints and see what the problem is.
EDIT Now that you've posted your constraints, it's easy to see what the problem is: There is nothing at all connecting your interface elements to the bottom of the contentView. But that is the whole point of self-sizing cells: you must have, as I already said, sufficient constraints running all the way from the top of the contentView to the bottom of the contentView. That is what determines the height — and so you are not determining it.
I hope someone reading this might be able to shed some light on this problem.
I have a plain UITableView containing custom UITableViewCells, each cell is a different height provided by tableView:heightForRowAtIndexPath: and the table does not scroll. The cells themselves are really containers for one or two UILabels nothing very special. Three of the cells show a custom disclosure when editing apart from that no disclosures are used for anything else. The custom disclosures are UIImageView's assigned to the cells editingAccessoryView with 28x29 images however the UIImageView size is set to 40x29 to give a better position using contentMode Left.
This should work fine but what happens is when the disclosures appear in edit mode they don't all share the same position - two might be the same x and the third might be 5px different. This seems to be dependant on the height given to each cell, they basically move around. I can't see how they are associated but have found one set of heights that give the expected results of all three being in the same position. This isnt ideal but has been working fine till now - I have no choice but to change the heights and so the alignment is a big problem.
If I remove the custom disclosures then the standard disclosures work perfectly?
I've tried lot's of things, i.e.
removing the extra width on the UIImageView
reducing the size of the image
playing around with the cell heights - the disclosures just move around
replacing the UIImageView's with other controls - no difference
If you have any ideas why this might be I'd love to here them, thanks.
My guess is its because you are using content mode left in the UIImageView. Use content mode center.
The views get stretched in all directions when the height changes, but the image stays on the left edge of the view...
On an iPhone, how do you figure out the width of a table view cell's content view when it is showing a certain accessory view (disclosure indicator, etc)?
I need this in order to calculate the correct cell height for cells that contain wrapping, variable-length text. But when the table view delegate is asked for a cell height, it doesn't actually have the actual cell instance, so it can't just query the content view bounds directly.
I can easily hard-code a 20-pixel margin on the right which appears to be accurate for a plain style table view in portrait orientation with a disclosure indicator, but would prefer to do it the Right Way so that it keeps working if Apple decides to tweak the margin.
(This is related to this question.)
Personally, I would just hard code the values -- simpler and things will break in a predictable way.
But were I to do this programmatically, I would create a UITableViewCell, set up the editing properties / accessory views you need to measure, and then ask it how big its contentView is.
Of course I would probably heavily cache this -- doing allocations when asking UITableView asks you for height information sounds to me like it would be slow (check with a profiler first though, as always).
I would have a subclass of UITableViewCell that holds all its subelements. You can cange the frame of certain elements when the cell enters and exists editing mode. There is a good example of this in Apple's Table View Programming guide under the section on creating a custom table view cell.
I believe the UITableViewCell's contentView property is the view that contains your labels etc., so the width of that should be your available size to use.
I wonder if it's possible to adjust the width of a grouped tableview.
I want to have a wider table.
Is this possible? and how?
Sorry to be blunt Mike but you're wrong. The table's width is not already set to the maximum. creator7 hit the nail on the head, you can resize tables, including grouped tables, in Interface Builder. If you need it larger than the screen (can't imagine why you would want this...), you might need to do further sizing programmatically. If the table has been added in IB, then best to do this programmatic resizing in the viewWillAppear:(BOOL)animated method.
The width on tables is already set to the maximum.
you have to increase the width of the table using interface builder manually for scroll upto its width add the tableview as subview of a scrollview.
I want to resize my table view cells from inside the cell instead of from the UITableViewDelegate. I am resizing them based on asynchronous content, so I can't size them in the delegate.
I tried setting self.frame inside the cell, but the table view was really unhappy about that. Cells were overlapping and all kinds of craziness was going on.
You simply have to use the table view to control height. You can tell the table a cell has altered by using the calls to remove and then re-add specific cells, so you don't have to reload the whole table - but the height has to be fetched using the delegate callback tableView:heightForRow:atIndexPath:
I don't see why this is not practical though. You can have any number of asynch systems running that update a central height cache held by the table view delegate - every time you create a cell you can assign it the delegate as a reference so it has a way to talk back to the table and let it know cells need reloading and what the new heights are.
If you think about it, the poor table view is a scroll view that has to manage all these separate cells and keep them together visually - so it's really unkind of a cell to go rogue and start altering frames without letting the table view know what is going on anyway. It's best to let the table drive and tell it what to do.
No you can not set the cell's size without using the UITableViewDelegate. Changing the size of the cell with actually change the size of the cell, but it will not change the offsets that the UITableView draws the cells with. Which will result in overlaps, and gaps all over the place.
Your friend is tableView:heightForRowAtIndexPath:, and it should be fast. If you override it, then the table view can no longer make the assumption that all rows are of the same height. And thus it must query all rows for their height each time it fetches cells to draw.
You should try to manage the cells contentView propertys frame, instead of the cells frame itself
heres a reference http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITableViewCell_Class/Reference/Reference.html#//apple_ref/occ/instp/UITableViewCell/contentView