I have a UITableView configured as plain style so I can have the header views stuck on the top of the table until another header pulls it away.
The problem is: If I have a header stuck on the top of the screen, and I programmatically scroll to another part of the table (where that header should not appear at all), that UIView will not be dismissed. I.e. if I scroll again to that part of the table, a ghost of that header will be visible on that part of the table.
I've implemented the method - (void)tableView:(UITableView *)tableView didEndDisplayingHeaderView:(nonnull UIView *)view forSection:(NSInteger)section to understand what is happening. I found that if I manually scroll until a header is pull away of the screen, this delegate is called. But if I scroll programmatically, the delegate is not called.
By the way, I tried scrolling programmatically using two different methods, and the problem is the same.
- (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated;
- (void)scrollToRowAtIndexPath:(NSIndexPath *)indexPath atScrollPosition:(UITableViewScrollPosition)scrollPosition animated:(BOOL)animated;
One workaround that I can imagine is implementing - (void)scrollViewDidScroll:(UIScrollView *)scrollView;, filtering all the header views that are outside the visible screen, and removing them from superview. I can probably make it work, but I would like to know if there is any other better solution.
[EDIT] If I call - (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated; with animated = YES, the bug does not happen. I can go with this solution, but I really would like in some cases to scroll without animation.
Not entirely sure I understand your issue entirely but it seems that your header view(s) (some UIView) is/are not rendered correctly once you programmatically scroll away from this area / section and then return.
I'm not sure how you are filling your header view content but I have several applications running UITableView's with multiple section headers that require updating for scrolling / content offset's with no problem, as long as you "draw" your headers with this delegate:
- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section {
// Per section, simply return the appropriate header view
...
NSString *someIdentifier = [NSString stringWithFormat:#"sectionHeaderView:<some #, letter, or tag>", <SOMETHING UNIQUE ADD HERE>];
UITableViewHeaderFooterView *myHeaderView = [self.tableView dequeueReusableHeaderFooterViewWithIdentifier:someIdentifier];
if (!myHeaderView) {
// No header view found with that ID. Make a new one
}
...
return myHeaderViewForSection;
}
This way whether you finger scroll or programmatically set the content offset which ever way you like, your table view will know what to draw, when to draw it, and where to put it.
Using their delegates is a bit of a drag as it's slightly tedious at start, but using the viewForHeaderInSection proved the only way I ever obtained the results I (you) wanted.
Hope this helps - happy coding!
TL;DR
Do NOT explicitly scroll the table view between beginUpdates and endUpdates.
Explanation
I'm using NSFetchedResultsController to populate the table. These are my implementations for some of the methods of NSFetchedResultsControllerDelegate.
- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller
{
[_conversationTableView beginUpdates];
}
- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller
{
[_conversationTableView endUpdates];
}
The problem is that endUpdates was making a chain of calls that ended calling my method [self scrollToBottom] (which was a very ugly code actually). This method, as the name says, calls - (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated; to scroll the table view to the bottom of the table.
The explicit scrolling of the table during a beginUpdates - endUpdates was the culprit of my whole problem.
Solution
Scrolling the table view only after finishing endUpdates.
- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller
{
[_conversationTableView beginUpdates];
}
- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller
{
[_conversationTableView endUpdates];
[self scrollToBottom];
}
Side Note
This also fixed a problem where the table view was sometimes flickering when scrolling.
Manually set the sectionHeader height to 0 when it should not appear
tableView.sectionHeaderHeight = 0;
Related
I've got a UITableView with one section and enough rows that the tableView needs to be scrolled to get to the bottom. I want to add a footer view which will stick to the bottom of the tableView and always be visible, so I have implemented viewForFooterInSection. Here's my code:
- (UIView*)tableView:(UITableView *)tableView viewForFooterInSection:(NSInteger)section {
NSLog(#"Get footer view");
if (tableView == [self tableView]) {
return [self footerRowRightView];
}
else if (tableView == [self fixedColumnTableView]) {
return [self footerRowLeftView];
}
return nil;
}
The problem I am having is that the footer view only shows after the tableView has been scrolled, but I want it to be visible from the outset (i.e. always floating whether the user scrolls or not).
As soon as the controller appears and the tableView loads its data, I see "Get footer view" in the log, so I know that viewForFooterInSection is being called straight away. What I can't work out is why it doesn't display immediately, and how to get it to do so.
Thanks in advance for any help!
It is probably your height for the footer not being returned correctly.
Check what you return from heightForFooterInSection
What you need is not a tableview's footer.
Simply add the view corresponding to this header in the superview of your tableview and put it at the bottom of it. Then simply reduce the height of the frame of your tableview to fit the remaining space. And it should do it !
You can no use footer view if you want to stick the footer. Or try with grouped tableview.
Quite a few options by the looks of the other answers. Just to add a hacky workaround I have just come up with, I created duplicates of the views I will be using as footers and added them as subviews of my main view, placed exactly over the position of where the real footer views. The views are retained in properties, so that in scrollviewDidScroll I can do the following:
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
if ([self preScrollFooterLeftView]) {
[[self preScrollFooterLeftView] removeFromSuperview];
}
if ([self preScrollFooterRightView]) {
[[self preScrollFooterRightView] removeFromSuperview];
}
}
This way the footer appears to be displayed immediately. The fake footer is removed as soon as the user scrolls the tableView, revealing the real footer beneath it. If the tableView is scrolled below the last row, the real header sticks to the bottom of the section and bounces back to the bottom of the tableView when the user lets go.
Consider an standard, vertically scrolling flow layout populated with enough cells to cause scrolling. When scrolled to the bottom, if you delete an item such that the content size of the collection view must shrink to accommodate the new number of items (i.e. delete the last item on the bottom row), the row of cells that scroll in from the top are hidden. At the end of the deletion animation, the top row appears without animation - it's a very unpleasant effect.
In slow motion:
It's really simple to reproduce:
Create a new single view project and change the default ViewController to be a subclass of UICollectionViewController
Add a UICollectionViewController to the storyboard that uses a standard flow layout, and change its class to ViewController. Give the cell prototype the identifier "Cell" and a size of 200x200.
Add the following code to ViewController.m:
#interface ViewController ()
#property(nonatomic, assign) NSInteger numberOfItems;
#end
#implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
self.numberOfItems = 19;
}
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
return self.numberOfItems;
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
return [collectionView dequeueReusableCellWithReuseIdentifier:#"Cell" forIndexPath:indexPath];
}
- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath
{
self.numberOfItems--;
[collectionView deleteItemsAtIndexPaths:#[indexPath]];
}
#end
Additional Info
I've seen other manifestations of this problem when dealing with collection views, it's just that the above example seems the simplest to demonstrate the issue. UICollectionView seems to go into some kind of paralysed state of panic during the default animations, and refuses to unhide certain cells until after the animation completes. It even prevents manual calls to cell.hidden = NO on hidden cells from having an effect (hidden is still YES afterwards). Dropping down to the underlying layer and setting hidden there works, provided you can get a reference to the cell you want to unhide, which is non-trivial when dealing with cells that haven't been displayed yet.
-initialLayoutAttributesForAppearingItemAtIndexPath is being called for every item visible at the time of the call to deleteItemsAtIndexPaths:, but not for the ones that are scrolled into view. It is possible work around the issue by calling reloadData inside a batch update block immediately afterwards, which appears to make the collection view realise that the top row is about to appear:
[collectionView deleteItemsAtIndexPaths:#[indexPath]];
[collectionView performBatchUpdates:^{
[collectionView reloadData];
} completion:nil];
But unfortunately this is not an option for me. I am trying to implement some custom animation timing by manipulating the cell layers & animations, and calling reloadData really throws things out of whack by causing unnecessary layout callbacks.
Update: A bit of investigation
I added log statements to a lot of layout methods and looked through some stack frames to try and find out what's going wrong. Crucially, I'm checking when layoutSubviews is called, when the collection view asks for layout attributes from the layout object (layoutAttributesForElementsInRect:) and when applyLayoutAttributes: is called on the cells.
I would expect to see a sequence of methods like this:
// user taps cell (to delete it)
-deleteItemsAtIndexPaths:
-layoutAttributesForElementsInRect:
-finalLayoutAttributes...: // Called for the item being deleted
-finalLayoutAttributes...: // \__ Called for each index path visible
-initialLayoutAttributes...: // / when deletion started
-applyLayoutAttributes: // Called for the item being deleted, to apply final layout attributes
// collection view begins scrolling up
-layoutSubviews: // Called multiple times as the
-layoutAttributesForElementsInRect: // collection view scrolls
// ... for any new set of
// ... attributes returned:
-collectionView:cellForItemAtIndexPath:
-applyLayoutAttributes: // Sets the standard attributes for the new cell
// collection view finishes scrolling
Most of this is happening; layout is correctly triggered as the view scrolls, and the collection view properly queries the layout for the attributes of cells to be displayed. However, collectionView:cellForItemAtIndexPath: and the corresponding applyLayoutAttributes: methods are not being called until after the deletion, when layout is invoked one last time causing the hidden cells to be assigned their layout attributes (sets hidden = NO).
So it seems that despite receiving all the correct responses from the layout object, the collection view has some kind of flag set to not update the cells during the update. There is a private method on UICollectionView called from within layoutSubviews that seems responsible for refreshing the cells' appearance: _updateVisibleCellsNow:. This is from where the data source eventually gets asked for a new cell before applying the cells starting attributes, and it seems this is the point of failure, as it is not being called when it should be.
Additionally, this does seem to be related to the update animation, or at least cells are not updated for the duration of the insertion/deletion. For example the following works without glitches:
- (void)addCell
{
NSIndexPath *indexPathToInsert = [NSIndexPath indexPathForItem:self.numberOfItems
inSection:0];
self.numberOfItems++;
[self.collectionView insertItemsAtIndexPaths:#[indexPathToInsert]];
[self.collectionView scrollToItemAtIndexPath:indexPathToInsert
atScrollPosition:UICollectionViewScrollPositionCenteredVertically
animated:YES];
}
If the above method is called to insert a cell while the inserted cell is outside the current visible bounds, the item is inserted without animation and the collection view scrolls to it, properly dequeuing and displaying cells on the way.
Problem occurs in iOS 7 & iOS 8 beta 5.
Adjust your content insets so that they go beyond the bounds of the device's screen size slightly.
collectionView.contentInsets = UIEdgeInsetsMake(-5,0,0,0); //Adjust this value until it looks ok
This question should not be mixed up with this here.. These are two different things.
There is a good example how to use a UITableView Header on SO.
This all works fine and the main header is fixed on top as long as the style is set to plain.
But if I use sections, the main header no longer sticks to top and moves away while scrolling to the bottom.
In this method, I am returning the header for each section.
- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
In this method I am setting the height for the header section above:
- (CGFloat) tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section
In this method, I am setting the real table header.
- (void)viewWillAppear:(BOOL)animated {
...
self.recordTableView.tableHeaderView = headerView;
}
Is it even possible having a fixed table header, while using sections?
What is an alternative solution to this please?
If you want a UITableViewController (static cells/keyboard handling) and have a fixed header then you should use Containment. You can do this from a Storyboard by setting up a UIViewController with your fixed header and then using a Container View to embed the UITableViewController.
Once you have your containing view setup, you right-click drag from the Container View to the View Controller you want to embed - the UITableViewController in this case.
You can access and get a reference to the contained View Controller (the UITableViewController) from the Container View Controller by implementing the prepareForSegue:sender: method.
There’s no way to maintain the header of a tableView fixed, but
an useful approach when you need a unique header, is to use a UIViewController rather than a UITableViewController, and set the header (UIView) out from the tableView.
Something like this:
If you want to keep the class as a UITableViewController you can add your header as a subview to the tableview's superview. You will have to also push the tableview top inset down so your headerview doesnt hide the table.
Here is a sample code to put inside your tableViewController subclass (This example assumes your tableview controller is inside a navigation controller, so it pushes the view to below the navigation bar):
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view.
self.automaticallyAdjustsScrollViewInsets = NO;
}
-(void)addHeaderView{
CGFloat yPosition = self.navigationController.navigationBar.frame.origin.y + self.navigationController.navigationBar.frame.size.height;
mainHeaderView = [[UIView alloc] init];
const CGFloat mainHeaderHeight = 44;
[mainHeaderView setFrame:CGRectMake(0, yPosition, self.view.frame.size.width, mainHeaderHeight)];
mainHeaderView.backgroundColor = [UIColor redColor];
[self.tableView.superview addSubview:mainHeaderView];
[self.tableView setContentInset:UIEdgeInsetsMake(yPosition + mainHeaderHeight, self.tableView.contentInset.left, self.tableView.contentInset.bottom, self.tableView.contentInset.right)];
}
I haven't done this, but the first thing I would think to try is to place my tableview in a UIView and make my own header there in that UIView. Seems a trivial matter to make that view appear to be the header of the table and it would certainly stay put.
I have a UITableView with a few different sections. One section contains cells that will resize as a user types text into a UITextView. Another section contains cells that render HTML content, for which calculating the height is relatively expensive.
Right now when the user types into the UITextView, in order to get the table view to update the height of the cell, I call
[self.tableView beginUpdates];
[self.tableView endUpdates];
However, this causes the table to recalculate the height of every cell in the table, when I really only need to update the single cell that was typed into. Not only that, but instead of recalculating the estimated height using tableView:estimatedHeightForRowAtIndexPath:, it calls tableView:heightForRowAtIndexPath: for every cell, even those not being displayed.
Is there any way to ask the table view to update just the height of a single cell, without doing all of this unnecessary work?
Update
I'm still looking for a solution to this. As suggested, I've tried using reloadRowsAtIndexPaths:, but it doesn't look like this will work. Calling reloadRowsAtIndexPaths: with even a single row will still cause heightForRowAtIndexPath: to be called for every row, even though cellForRowAtIndexPath: will only be called for the row you requested. In fact, it looks like any time a row is inserted, deleted, or reloaded, heightForRowAtIndexPath: is called for every row in the table cell.
I've also tried putting code in willDisplayCell:forRowAtIndexPath: to calculate the height just before a cell is going to appear. In order for this to work, I would need to force the table view to re-request the height for the row after I do the calculation. Unfortunately, calling [self.tableView beginUpdates]; [self.tableView endUpdates]; from willDisplayCell:forRowAtIndexPath: causes an index out of bounds exception deep in UITableView's internal code. I guess they don't expect us to do this.
I can't help but feel like it's a bug in the SDK that in response to [self.tableView endUpdates] it doesn't call estimatedHeightForRowAtIndexPath: for cells that aren't visible, but I'm still trying to find some kind of workaround. Any help is appreciated.
As noted, reloadRowsAtIndexPaths:withRowAnimation: will only cause the table view to ask its UITableViewDataSource for a new cell view but won't ask the UITableViewDelegate for an updated cell height.
Unfortunately the height will only be refreshed by calling:
[tableView beginUpdates];
[tableView endUpdates];
Even without any change between the two calls.
If your algorithm to calculate heights is too time consuming maybe you should cache those values.
Something like:
- (CGFloat)tableView:(UITableView *)tableView
heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
CGFloat height = [self cachedHeightForIndexPath:indexPath];
// Not cached ?
if (height < 0)
{
height = [self heightForIndexPath:indexPath];
[self setCachedHeight:height
forIndexPath:indexPath];
}
return height;
}
And making sure to reset those heights to -1 when the contents change or at init time.
Edit:
Also if you want to delay height calculation as much as possible (until they are scrolled to) you should try implementing this (iOS 7+ only):
#property (nonatomic) CGFloat estimatedRowHeight
Providing a nonnegative estimate of the height of rows can improve the
performance of loading the table view. If the table contains variable
height rows, it might be expensive to calculate all their heights when
the table loads. Using estimation allows you to defer some of the cost
of geometry calculation from load time to scrolling time.
The default value is 0, which means there is no estimate.
This bug has been fixed in iOS 7.1.
In iOS 7.0, there doesn't seem to be any way around this problem. Calling [self.tableView endUpdates] causes heightForRowAtIndexPath: to be called for every cell in the table.
However, in iOS 7.1, calling [self.tableView endUpdates] causes heightForRowAtIndexPath: to be called for visible cells, and estimatedHeightForRowAtIndexPath: to be called for non-visible cells.
Variable row heights have a very negative impact on your table view performance. You are talking about web content that is displayed in some of the cells. If we are not talking about thousands of rows, thinking about implementing your solution with a UIWebView instead of a UITableView might be worth considering. We had a similar situation and went with a UIWebView with custom generated HTML markup and it worked beautifully. As you probably know, you have a nasty asynchronous problem when you have a dynamic cell with web content:
After setting the content of the cell you have to
wait until the web view in the cell is done rendering the web content,
then you have to go into the UIWebView and - using JavaScript - ask the HTML document how high it is
and THEN update the height of the UITableViewCell.
No fun at all and lots of jumping and jittering for the user.
If you do have to go with a UITableView, definitely cache the calculated row heights. That way it will be cheap to return them in heightForRowAtIndexPath:. Instead of telling the UITableView what to do, just make your data source fast.
Is there a way?
The answer is no.
You can only use heightForRowAtIndexPath for this.
So all you can do is make this as inexpensive as possible by for example keeping an NSmutableArray of your cell heights in your data model.
I had a similar issue(jumping scroll of the tableview on any change) because I had
(CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 500; }
commenting the entire function helped.
Use the following UITableView method:
- (void)reloadRowsAtIndexPaths:(NSArray *)indexPaths withRowAnimation:(UITableViewRowAnimation)animation
You have to specify an NSArray of NSIndexPath which you want to reload. If you want to reload only one cell, then you can supply an NSArray that holds only one NSIndexPath.
NSIndexPath* rowTobeReloaded = [NSIndexPath indexPathForRow:1 inSection:0];
NSArray* rowsTobeReloaded = [NSArray arrayWithObjects:rowTobeReloaded, nil];
[UITableView reloadRowsAtIndexPaths:rowsTobeReloaded withRowAnimation:UITableViewRowAnimationNone];
The method heightForRowAtIndexPath: will always be called but here's a workaround that I would suggest.
Whenever the user is typing in the UITextView, save in a local variable the indexPath of the cell. Then, when heightForRowAtIndexPath: is called, verify the value of the saved indexPath. If the saved indexPath isn't nil, retrieve the cell that should be resized and do so. As for the other cells, use your cached values. If the saved indexPath is nil, execute your regular lines of code which in your case are demanding.
Here's how I would recommend doing it:
Use the property tag of UITextView to keep track of which row needs to be resized.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
...
[textView setDelegate:self];
[textView setTag:indexPath.row];
...
}
Then, in your UITextView delegate's method textViewDidChange:, retrieve the indexPath and store it. savedIndexPath is a local variable.
- (void)textViewDidChange:(UITextView *)textView
{
savedIndexPath = [NSIndexPath indexPathForRow:textView.tag inSection:0];
}
Finally, check the value of savedIndexPath and execute what it's needed.
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
if (savedIndexPath != nil) {
if (savedIndexPath == indexPath.row) {
savedIndexPath = nil;
// return the new height
}
else {
// return cached value
}
}
else {
// your normal calculating methods...
}
}
I hope this helps! Good luck.
I ended up figuring out a way to work around the problem. I was able to pre-calculate the height of the HTML content I need to render, and include the height along with the content in the database. That way, although I'm still forced to provide the height for all cells when I update the height of any cell, I don't have to do any expensive HTML rendering so it's pretty snappy.
Unfortunately, this solution only works if you've got all your HTML content up-front.
I have a UITableView with some sections, each has its own header view.
When user taps on the header view of a section, all rows of that section will collapse. What i do is, I set the number of row of that section to 0, and then call :
[self.tableView reloadSections:sections withRowAnimation:UITableViewRowAnimationBottom];
Everything works as expected, except one thing : the header view of the section becomes white blank. When i scroll the table, then the header becomes normal again.
So i guess there's some problem with the drawing of the table.
One funny thing is, if i use UITableViewRowAnimationFade instead, then even when i scroll the table, the header is still white blank.
When I update just ONE section there is also no problem - when I update more than one section the problem occurs.
If i use
[self.tableView reloadData]
instead, then everything works fine.
The reason i use
[self.tableView reloadSections:sections withRowAnimation:UITableViewRowAnimationBottom];
is because i want animation.
Wrapping with beginUpdates / endupdates does not work.
I realize that it's a LONG time since this question was posed but I think all of the answers given below are incorrect.
I had the same problem (with someone else's code) and was about to be fooled by this post when I realized that the code was not doing it's reuse of the table header correctly. The header disappearing was because the code was only supplying a UIView, not a UITableViewHeaderFooterView, registered correctly and set up for reuse.
Have a look at the answer here:
How to use UITableViewHeaderFooterView?
My blank headers went away when I set up a reusable header.
In Swift:
You need to create a class that's a subclass of UITableViewHeaderFooterView and register it to the table view. Then in viewForHeaderInSection, you do let header = tableView.dequeueReusableHeaderFooterView(withIdentifier: "HeaderView") as! YourHeaderView, similar to what you do for UITableViewCells. Then return that header.
The deceptive thing is the function calls for a return of UIView? when it really needs a dequeuedReusableHeaderFooterView or reloadData will cause it to disappear
I found a work-around - not very elegant, but it works.
Instead of providing a NSIndexSet with more than one section, I call the reloadSections within a for-loop with only one section in each call.
looks like:
for (Element *eleSection in self.gruppenKoepfe) {
if ( eleSection.type.integerValue == qmObjectTypeFormularSpalte || eleSection.type.integerValue == qmObjectTypeFormularZeile ) {
[self.tableView reloadSections:[NSIndexSet indexSetWithIndex:nCount] withRowAnimation:UITableViewRowAnimationFade];
}
nCount ++;
}
I was having a similar problem, except I was trying to delete/insert sections, and I found that keeping a strong property pointing to the entire header view (i.e. not just a subview) stopped it disappearing during section updates.
e.g. Property and instantiation
#property (nonatomic, strong) UIView *headerView;
-(UIView *)headerView {
if ( !_headerView ) {
_headerView = [[UIView alloc] initWithFrame:CGRectMake(0,0,self.view.bounds.size.width, 300)];
// add additional view setup, including subviews
}
return _headerView;
}
And in tableView:(UITableView *)viewForHeaderInSection:(NSInteger)section:
-(UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section {
if ( section == theCorrectSection ) {
return self.headerView;
}
return nil;
}
I had the same issue and it was none of the above. My problem was that i was hidding the first header and for some reason after more then 10 reloads the header at index 2 was set hidden. When i set headerView.hidden = false it was ok.