After using [UITableView deleteSections:withRowAnimation:] on a section which is out of view - the section header remains visible.
On this image, we see the visible part of the tableview
On the next image, we see the whole tableview - AISLE 2 is hidden until the user scrolls down, it contains only one row:
When I scroll down and delete the last row, AISLE 2 section header remains visible, even though I used deleteSections. if I delete a row from AISLE 1, the section header remains on the same place, and by scrolling down I can still see it.
Furthermore, when trying to scroll down so that AISLE 2 header is in the view, the UI acts as AISLE2 is NOT part of the tableview, and immediately scrolls me back up. Which means - this is a garbage view that is obviously not part of the table, since I removed it. for some reason, iOS doesn't remove this view, but de-associates it from the table.
Any ideas?
Try [tableview reload] with making numberofsections as 1.
Where is your data coming from and how do you know how many sections there are at the start? I think your problem can easily be resolved by explaining this.
It looks like you may have a multidimentional nsmutablearray where each index is an aisle and each object contains the products for that isle? Or you may have a different array for each aisle?
When you delete a cell, simply check how many cells are left, and call [self.tableView reloadData];
For (hypothetical) example;
if you have arrays of your Aisles:
NSMutableArray *aisleOne = [[NSMutableArray alloc] initWithObjects:#"Product1", #"Product2", nil];
NSMutableArray *aisleTwo = [[NSMutableArray alloc] initWithObjects:#"Product1", #"Product2", nil];
NSMutableArray *aisleThree = [[NSMutableArray alloc] initWithObjects:#"Product1", #"Product2", nil];
NSMutableArray *aisleFour = [[NSMutableArray alloc] initWithObjects:#"Product1", #"Product2", nil];
and you add them to one array:
NSMutableArray *aisleArray = [[NSMutableArray alloc] initWithObjects:aisleOne, aisleTwo, aisleThree, aisleFour, nil];
then, call this code when you delete a cell. It will remove all empty Aisles from the aisleArray (which needs to be globally defined):
NSMutableArray *tempArray = [[NSMutableArray alloc] initWithArray:aisleArray];
for (int i=0; i<[tempArray count]; i++) {
if ([[tempArray objectAtIndex:i] count] == 0) {
[aisleArray removeObjectAtIndex:i];
}
}
[self.tableView reloadData];
For this to work, these two methods should be:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
return [aisleArray count];
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return [[aisleArray objectAtIndex:section] count];
}
(untested)
Just get the table haderview for that section and remove it from it's superview and tableView is not managing it.
UIView *mysteriousView = [tableView headerViewForSection:indexPath.section];
[tableView deleteSections:[NSIndexSet indexSetWithIndex:indexPath.section] withRowAnimation:UITableViewRowAnimationAutomatic];
[mysteriousView removeFromSuperview];
Hope this helps!
Few yers later I'm facing same issue... Deleting last section doesn't remove last section header from table view.
I noticed however that the remaining header has frame exactly just below normal table view content.
So the workaround (in swift but you can easily translate it to Objective C) that worked for me is something like this:
DispatchQueue.main.async {
let unwantedViews = self.tableView.subviews.filter{ $0.frame.minY >= self.tableView.contentSize.height}
unwantedViews.forEach{ $0.isHidden = true }
}
Related
I have 3 or 2 sections (depending on datasource), in my grouped UITableView. I am trying to reload the last section via:
dispatch_async(dispatch_get_main_queue(), ^{
[UIView performWithoutAnimation:^{
[feedDetailTB reloadSections:[NSIndexSet indexSetWithIndex:feedDetailTB.numberOfSections-1] withRowAnimation:UITableViewRowAnimationNone];
}];
});
First of all, the footer never disappears. The data source basically keeps track of whether there are more comments or not (a simple load more functionality). In the viewForFooterInSection I simply return nil, when all the comments have been loaded.
But, as you see in the GIF, at first the loading button stays there. It is even accessible and works. When I scroll up, it vanishes and one can see it in the bottom, which is correct. But after all the comments have been reloaded, it should vanish, but sadly it stays there.
If I use reloadData it works fine. But I can't used it, since I have other sections, which I don't need to reload.
Second, there is a weird animation/flickering of the row items, even when I have used UITableViewRowAnimationNone. Not visible in the GIF
You should implement "isTheLastSection" according to your logic
- (CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section {
if (isTheLastSection) {
return 40;
}
return 0;
}
In order to add new rows to a section, you must use the insertRowsAtIndexPaths rather than just adding new objects to data source and reloading a section.
Here's the code:
NSMutableArray *newCommentsIndexPath = [[NSMutableArray alloc] init];
for (NSInteger i = currentCount; i < (_postDetailDatasource.commentsFeedInfo.allCommentsArray.count + serverComments.count); i ++)
{
NSIndexPath *idxPath = [NSIndexPath indexPathForRow:i inSection:sectionNumber];
[newCommentsIndexPath addObject:idxPath];
}
[_postDetailDatasource.commentsFeedInfo.allCommentsArray addObjectsFromArray:serverComments];
[feedDetailTB beginUpdates];
[feedDetailTB insertRowsAtIndexPaths:newCommentsIndexPath withRowAnimation:UITableViewRowAnimationFade];
[feedDetailTB endUpdates];
I am trying to delete rows in an array without having to use the edit function that Apple provide (Something along the lines of -(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath). So the user selects some of the rows, presses a button not in the table view, then those rows fade away. Apple provide something of sorts here.
The code I am using calls an array of rows to be deleted, which is defined elsewhere, removes the array population objects at those particular rows, and is supposed to remove all of the rows using the fade stuff.
- (void) deleteTableRow {
NSIndexPath *current;
NSLog(#"to be deleted: %#", toBeDeleted); //toBeDeleted is the array with the NSIndexPath items
for(int i=0; i < [toBeDeleted count]; i++) {
current = [toBeDeleted objectAtIndex: i];
[tableData removeObjectAtIndex:current.row]; //Remove the necessary array stuff
}
tv = [UITableView alloc];
[tv beginUpdates];
[tv deleteRowsAtIndexPaths:toBeDeleted withRowAnimation:UITableViewRowAnimationFade];
[tv endUpdates];
// Do whatever data deletion you need to do...
}
tv is defined in my header file and is a referencing outlet of my UITableView.
So here are my main questions:
Because my UITableView is not a UITableViewController (it is part of the view instead), is this even possible?
If it is possible, why is this not working?
I have a UICollectionView and it works fine, but I want to add a few UICollectionViewCells items programmatically into the collection view.
So how can I achieve this?
To further clarify: when I say programmatically I mean inserting a cell during runtime, when an action is fired, not when the app is loaded (using the viewDidLoad method). I know when the model is updated and the call is made to UICollectionView in the insertItemsAtIndexPaths: method. It should create a new cells, but it's not doing that, it's throwing an error.
...By referring to UICollectionView documentation
You can accomplish:
Inserting, Deleting, and Moving Sections and Items To insert, delete,
or move a single section or item, follow these steps:
Update the data in your data source object.
Call the appropriate method of the collection view to insert or delete the section or item.
It is critical that you update your data source before notifying the
collection view of any changes. The collection view methods assume
that your data source contains the currently correct data. If it does
not, the collection view might receive the wrong set of items from
your data source or ask for items that are not there and crash your
app. When you add, delete, or move a single item programmatically, the
collection view’s methods automatically create animations to reflect
the changes. If you want to animate multiple changes together, though,
you must perform all insert, delete, or move calls inside a block and
pass that block to the performBatchUpdates:completion: method. The
batch update process then animates all of your changes at the same
time and you can freely mix calls to insert, delete, or move items
within the same block.
From your Question: you can for example register A gesture Recognizer, and Insert a NEW cell by
doing the following:
in
// in .h
#property (nonatomic, strong) NSMutableArray *data;
// in .m
#synthesize data
//
- (void)ViewDidLoad{
//....
myCollectonView.dataSource = self;
myCollectionView.delegate = self;
data = [[NSMutableArray alloc] initWithObjects:#"0",#"1", #"2" #"3", #"4",
#"5",#"6", #"7", #"8", #"9",
#"10", #"11", #"12", #"13",
#"14", #"15", nil];
UISwipeGestureRecognizer *swipeDown =
[[UISwipeGestureRecognizer alloc]
initWithTarget:self action:#selector(addNewCell:)];
swipeDown.direction = UISwipeGestureRecognizerDirectionDown;
[self.view addGestureRecognizer:swipeDown];
//..
}
-(void)addNewCell:(UISwipeGestureRecognizer *)downGesture {
NSArray *newData = [[NSArray alloc] initWithObjects:#"otherData", nil];
[self.myCollectionView performBatchUpdates:^{
int resultsSize = [self.data count]; //data is the previous array of data
[self.data addObjectsFromArray:newData];
NSMutableArray *arrayWithIndexPaths = [NSMutableArray array];
for (int i = resultsSize; i < resultsSize + newData.count; i++) {
[arrayWithIndexPaths addObject:[NSIndexPath indexPathForRow:i
inSection:0]];
}
[self.myCollectionView insertItemsAtIndexPaths:arrayWithIndexPaths];
} completion:nil];
}
If you are inserting multiple items into UICollectionView, you can use performBatchUpdates:
[self.collectionView performBatchUpdates:^{
// Insert the cut/copy items into data source as well as collection view
for (id item in self.selectedItems) {
// update your data source array
[self.images insertObject:item atIndex:indexPath.row];
[self.collectionView insertItemsAtIndexPaths:
[NSArray arrayWithObject:indexPath]];
}
} completion:nil];
– insertItemsAtIndexPaths: does the job
Here is how to insert an item in Swift 3 :
let indexPath = IndexPath(row:index, section: 0) //at some index
self.collectionView.insertItems(at: [indexPath])
You must first update your data.
I've created a UITableview with sections that are clickable. When you click on them,
they "expand" to reveal cells within them
the clicked section scrolls to the top of the view.
I calculate all of the indexpaths to insert/delete the necessary cells and then insert them with the following code:
[self.tableView beginUpdates];
[self.tableView insertRowsAtIndexPaths:pathsToOpen withRowAnimation:insertAnimation];
[self.tableView deleteRowsAtIndexPaths:pathsToClose withRowAnimation:deleteAnimation];
[self.tableView endUpdates];
[self.tableView scrollToRowAtIndexPath:[pathsToOpen objectAtIndex:0] atScrollPosition:UITableViewScrollPositionTop animated:YES];
There's only one problem- the sections below the selected section are hidden. The first screen-shot shows how the tableview should look. The second screen-shot shows how it actually looks.
If you scroll up (so the hidden sections are offscreen) and then scroll back down, the hidden sections are brought back (once again visible). My guess as to why this is happening is the following:
The insert/delete animations are happening at the same time as the scrollToRowAtIndexPath and it is confusing the TableView. If I hadn't done scrollToRowAtIndexPath sections 3 & 4 would have been offscreen - and so the tableView somehow still thinks they are offscreen. UITableview hides cells/sections that are offscreen as an optimization. If I call scrollToRowAtIndexPath with a dispatch_after with 2 seconds, then sections 3 & 4 are displayed correctly.
So I think I know why this is happening, but I don't know how to fix/override this UITableview optimization. Actually, if I implement scrollViewDidEndScrollingAnimation and then add a breakpoint in this function, the app displays sections 3 & 4 correctly (that's how I got the first screen-shot). But once continuing from this function, the cells disappear.
The full project can be downloaded here
Additional implementation details: Sections are legitimate UITableView sections. I've added a tapGestureRecognizer that triggers a delegate callback to the tableview. Included below is the entire method that opens the sections.
- (void)sectionHeaderView:(SectionHeaderView *)sectionHeaderView sectionOpened:(NSInteger)sectionOpened
{
// Open
sectionHeaderView.numRows = DefaultNumRows;
sectionHeaderView.selected = YES;
NSMutableArray *pathsToOpen = [[NSMutableArray alloc] init];
for (int i = 0; i < sectionHeaderView.numRows; i++)
{
NSIndexPath *pathToOpen = [NSIndexPath indexPathForRow:i inSection:sectionOpened];
[pathsToOpen addObject:pathToOpen];
}
// Close
NSMutableArray *pathsToClose = [[NSMutableArray alloc] init];
if (openSectionHeader)
{
for (int i = 0; i < openSectionHeader.numRows; i++)
{
NSIndexPath *pathToClose = [NSIndexPath indexPathForRow:i inSection:openSectionHeader.section];
[pathsToClose addObject:pathToClose];
}
}
// Set Correct Animation if section's already open
UITableViewRowAnimation insertAnimation = UITableViewRowAnimationBottom;
UITableViewRowAnimation deleteAnimation = UITableViewRowAnimationTop;
if (!openSectionHeader || sectionOpened < openSectionHeader.section)
{
insertAnimation = UITableViewRowAnimationTop;
deleteAnimation = UITableViewRowAnimationBottom;
}
openSectionHeader.numRows = 0;
openSectionHeader.selected = NO;
openSectionHeader = sectionHeaderView;
[self.tableView beginUpdates];
[self.tableView insertRowsAtIndexPaths:pathsToOpen withRowAnimation:insertAnimation];
[self.tableView deleteRowsAtIndexPaths:pathsToClose withRowAnimation:deleteAnimation];
[self.tableView endUpdates];
[self.tableView scrollToRowAtIndexPath:[pathsToOpen objectAtIndex:0] atScrollPosition:UITableViewScrollPositionTop animated:YES];
}
From what I can tell, the problem is occurring when returning a section view that's already been used. Instead of:
- (UIView *)tableView:(UITableView*)tableView viewForHeaderInSection:(NSInteger)section
{
return [self.sectionHeaderViews objectAtIndex:section];
}
I get no problem if I create a new view each time:
- (UIView *)tableView:(UITableView*)tableView viewForHeaderInSection:(NSInteger)section{
SectionHeaderView *sectionHeaderView = [self.tableView dequeueReusableCellWithIdentifier:SectionHeaderView_NibName];
sectionHeaderView.textLabel.text = [NSString stringWithFormat:#"Section %d", section];
UITapGestureRecognizer *tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:sectionHeaderView action:#selector(handleTap:)];
[sectionHeaderView addGestureRecognizer:tapRecognizer];
sectionHeaderView.section = section;
sectionHeaderView.delegate = self;
return sectionHeaderView;
}
It's possible this is occurring because you're using [self.tableView dequeueReusableCellWithIdentifier:SectionHeaderView_NibName]; to create section headers and hold on to them in an array, which I don't think UITableViewCell was created for, but I'm not certain. You may want to consider foregoing UITableViewCell for section views and instead use something else (perhaps a UIImageView with a UILabel). Or you can just not store the Section Views in an array...the way you currently have your code set up, you don't need the array and creating a new view is trivial enough you don't need to worry about it.
#AaronHayman's answer works (and IMO the accept and bounty should go to him, as it stands - this just didn't fit in a comment!), but I would go further - you shouldn't be using a cell at all for section header, and you shouldn't be using the dequeue mechanism to essentially load a nib.
Section header view's aren't supposed to be cells, and you may get unforseen effects by using them in place of regular views, particularly if they are deqeueued - the table is keeping a list of these reusable cells when you do that, and recycles them when they go off screen, but your section headers aren't reusable, you have one per section.
In your sample project, I changed the superclass of SectionHeaderView to be a plain UIView, and changed your createSectionHeaderViews method to load directly from the nibs there:
NSMutableArray *sectionHeaderViews = [[NSMutableArray alloc] init];
UINib *headerNib = [UINib nibWithNibName:SectionHeaderView_NibName bundle:nil];
for (int i = 0; i < 5; i++)
{
SectionHeaderView *sectionHeaderView = [[headerNib instantiateWithOwner:nil options:nil] objectAtIndex:0];
sectionHeaderView.textLabel.text = [NSString stringWithFormat:#"Section %d", i];
UITapGestureRecognizer *tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:sectionHeaderView action:#selector(handleTap:)];
[sectionHeaderView addGestureRecognizer:tapRecognizer];
sectionHeaderView.section = i;
sectionHeaderView.delegate = self;
[sectionHeaderViews addObject:sectionHeaderView];
}
self.sectionHeaderViews = sectionHeaderViews;
I also commented out the register for reuse line from your viewDidLoad. This prevents the section headers from disappearing.
I want to use iOS 5's nifty row-movement calls to animate a tableview to match some model state changes, instead of the older-style delete-and-insert.
Changes may include both reordering and in-place updates, and I want to animate both, so some rows will need reloadRowsAtIndexPaths.
But! UITableView appears to be just plain wrong in its handling of row reloads in the presence of moves, if the updated cell shifts position because of the moves. Using the older delete+insert calls, in a way that should be equivalent, works fine.
Here's some code; I apologize for the verbosity but it does compile and run. The meat is in the doMoves: method. Exposition below.
#define THISWORKS
#implementation ScrambledList // extends UITableViewController
{
NSMutableArray *model;
}
- (void)viewDidLoad
{
[super viewDidLoad];
model = [NSMutableArray arrayWithObjects:
#"zero",
#"one",
#"two",
#"three",
#"four",
nil];
[self.navigationItem setRightBarButtonItem:[[UIBarButtonItem alloc] initWithTitle:
#ifdef THISWORKS
#"\U0001F603"
#else
#"\U0001F4A9"
#endif
style:UIBarButtonItemStylePlain
target:self
action:#selector(doMoves:)]];
}
-(IBAction)doMoves:(id)sender
{
int fromrow = 4, torow = 0, changedrow = 2; // 2 = its "before" position, just like the docs say.
// some model changes happen...
[model replaceObjectAtIndex:changedrow
withObject:[[model objectAtIndex:changedrow] stringByAppendingString:#"\u2032"]];
id tmp = [model objectAtIndex:fromrow];
[model removeObjectAtIndex:fromrow];
[model insertObject:tmp atIndex:torow];
// then we tell the table view what they were
[self.tableView beginUpdates];
[self.tableView reloadRowsAtIndexPaths:[NSArray arrayWithObject:[NSIndexPath indexPathForRow:changedrow inSection:0]]
withRowAnimation:UITableViewRowAnimationRight]; // again, index for the "before" state; the tableview should figure out it really wants row 3 when the time comes
#ifdef THISWORKS
[self.tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:[NSIndexPath indexPathForRow:fromrow inSection:0]]
withRowAnimation:UITableViewRowAnimationAutomatic];
[self.tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:[NSIndexPath indexPathForRow:torow inSection:0]]
withRowAnimation:UITableViewRowAnimationAutomatic];
#else // but this doesn't
[self.tableView moveRowAtIndexPath:[NSIndexPath indexPathForRow:fromrow inSection:0]
toIndexPath:[NSIndexPath indexPathForRow:torow inSection:0]];
#endif
[self.tableView endUpdates];
}
#pragma mark - Table view data source boilerplate, not very interesting
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return model.count;
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:#""];
if (cell == nil)
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:#""];
[cell.textLabel setText:[[model objectAtIndex:indexPath.row] description]];
[cell.detailTextLabel setText:[NSString stringWithFormat:#"this cell was provided for row %d", indexPath.row]];
return cell;
}
What the code does: sets up a tiny model (small mutable array); when a button is pushed, it makes a small change to the middle element of the list, and moves the last element to be the first. Then it updates the table view to reflect these changes: reloads the middle row, removes the last row and inserts a new row zero.
This works. In fact, adding logging to cellForRowAtIndexPath shows that although I ask for row 2 to be reloaded, the tableview correctly asks for row 3 because of the insert once it's time to actually do the update. Huzzah!
Now comment out the top #ifdef to use the moveRowAtIndexPath call instead.
Now the tableview removes row 2, asks for a fresh row 2 (wrong!), and inserts it in the final row-2 position (also wrong!). Net result is that row 1 moved down two slots instead of one, and scrolling it offscreen to force a reload shows how it's gone out of sync with the model. I could understand if moveRowAtIndexPath changed the tableview's private model in a different order, requiring the use of the "new" instead of "old" index paths in reloads or model fetches, but that's not what's going on. Note that in the second "after" pic, the third and fourth rows are in the opposite order, which should't happen no matter which cell I'm reloading.
My vocabulary has grown colorful cursing Apple. Should I be cursing myself instead? Are row moves just plain incompatible with row reloads in the same updates block (as well as, I suspect, inserts and deletes)? Can anyone enlighten me before I go file the bug report?
I just spent some time playing with your code, and I agree; looks like it just doesn't work.
This whole area is a bit under-documented, but they don't actually say that you can mix moveRowAtIndexPath:toIndexPath: with reload methods. It does say in the that it can be mixed with row-insertion and row-deletion methods. Those seems to work if I modify your code to exercise those instead. So, you might be asking for an enhancement, not filing a bug. Either way, I'd definitely send it to radar.