I have a UITableView where in some instances, certain sections have zero rows. My goal is that when this is true, I don\'t want any wasted space in the table view, it should
Actually, with me it is happening other way round. I have assigned section header to be 10 in xib, but for the first section, I want a header of size header. I am using this method in my UITableViewCotroller
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
if(indexPath.section==0)
return 125;
return tableView.rowHeight;
}
But the section header heights are not changed, even though the method is getting called.
I found that in my case 2 things were needed to slay the phantom footer:
1) setting the table view sectionFooterHeight
to 0
, i.e. in viewDidLoad
adding:
tableView.sectionFooterHeight = 0
2) adding the delegate method:
override func tableView(tableView: UITableView, viewForFooterInSection section: Int) -> UIView? {
return UIView(frame: CGRect.zero)
}
(using Swift 2.2)
In a "grouped" UITableView on the iPhone it will still render a minimum height for header and footer, effectively ignoring your code to set it to zero. It is not linked to the XIB default.
This is because a zero height section header or footer would look very odd. Therefore Apple has decreed that a header height cannot be set to 0. And therefore multiple "empty" sections will render oddly as per your screenshot.
I'm afraid it's all because you're going the wrong way about clearing the header size when there are no data rows; instead you should not be calling any methods for empty sections. It is a bad technique because essentially the iPhone is having to call more methods than it ought to, and also you render more headers than you want to (usually - sometimes people want to leave the blank headers there, for example for drag and drop).
So, for example, let's imagine that you have a number of sections, but only some of them have more than one row in (perhaps based on user settings/filters).
The wrong way of implementing it is:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return totalNumberOfPossibleSections;
}
and then for each section you have no result for:
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
if (![section hasRow]) return 0;
}
and
- (CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section {
if (![section hasRow]) return 0.0f;
}
The correct way of implementing it is:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return numberOfSectionsWhichHaveAtLeastOneRowInThem;
}
and then each section will have at least one result. That way, sections with no data aren't even rendered, methods aren't even called for them. Note: my two variable names are made up to convey what they'll contain! They're not special Apple variables...
Hope that helps!
My solution to this problem is on and off how h4xxr is describing however, I have a slightly different approach to constructing a dynamic number of sections.
Firstly, I define a method that will walk my data structure and flag wether or not the data should be shown in the table. This flag is stored in an array so that I can include as few or as many sections as I like. I can describe this implementation a little better if we focused on just the number of cells for each section:
Suppose my first section is to be contact details with first name, last name and age. I will define this section with an id of '1' (although technically as I explain later this could be any number). Now, if my method determines that this section should be visible, I push the value '1' onto an array.
The next section I wish to show is address and may have 3-4 rows/cells. As above, the logic in my method determines wether or not the address should be visible by pushing say '2' onto the array.
Now.. ..if we wanted both sections visible, we would have an array with a length of 2 and two items [1,2]. If we only wanted the contact details visible our array would have a length of 1 with items [1] and [2] for the address only.
Now we can return the length of our array to define the number of sections we want.
our switch statement would now look like something like this:
switch(ourArray[indexPath.section]){
case 1:
<Return the number of rows for the contact details which we said would be 3>
break;
case 2:
<Return the number of rows for the address details which we said would be 4>
break;
case 3:
<Return another number for some section that is referenced by the id '3'>
break;
}
Notice I've put case 3 in my switch. Because the array in our example only contains values '1' and '2', case 3 would never be matched and so ignored unless we decided to add / enable this case by pushing it to the array.
Note also that we can in our method that defines the logic of which sections are visible, change the order of the sections by inserting/pushing them at different locations in the array.
I use the above religiously as it allows me to decouple the indexing and construction of sections.
Finally, Before I update my table by using 'reloadData' I will call my method which will construct the array and provide the correct length and sequence of section id's to allow my tableview to know how to build itself. If my data changes or is filtered somehow, I will again call this method and reconstruct the array.
I use the following solution:
func tableView(_ tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
return section == 0 ? CGFloat.leastNormalMagnitude : 8
}
func tableView(_ tableView: UITableView, heightForFooterInSection section: Int) -> CGFloat {
return 0
}
Result:
It appears that the table respects tableView:heightForHeaderInSection:
only if tableView:viewForHeaderInSection:
is not nil
, or if tableView:titleForHeaderInSection:
is not nil
or @""
. The same is true respectively for footer heights.
So assuming you don't have any section header views or titles, just add this to your table delegate:
- (UIView*)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section {
return [[[UIView alloc] initWithFrame:CGRectZero] autorelease];
}