I'd like to do something after deleteRowsAtIndexPaths has finished it's animation.
I can achieve this by wrapping it in animateWithDuration but it doesn't feel like the right way of doing it.
Another way is using didEndDisplayingCell but I can't update the section here or else it will get in an infinite loop.
What I'm trying to do is:
Delete a cell by swiping it
Remove it from my data model
Delete the row with deleteRowsAtIndexPaths
After the row has been deleted and animation has ended:
Reload sections by calling reloadSections
The code I'm using:
func deleteObject(ojbectName: String) {
let indexPath = // create indexPath
// Delete the item in data model and table
myData.removeAtIndex(index)
tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Left)
// Reload section after row animation has ended
let indexSet = NSIndexSet(indexesInRange: NSMakeRange(myData[indexPath.section].startIndex, myData[indexPath.section].endIndex))
tableView.reloadSections(indexSet, withRowAnimation: .None)
}
I tried creating an extension for UITableView that didn't go well. Is there someone who can tell me how to create one or how to use didEndDisplayingCell so I can reload the section after the animation has ended?
Try implementing didTransitionToState in your subclassed UITableViewCell. Check out the Apple docs on this.
`
Related
I am attempting to update a data object that holds the data for my collectionView (simply just filtering the data model), and the wishing to reload the collectionView with the filtered data. The issue is upon reloading the collectionView I am getting and error indexPath out of range when the reload happens. Seems when debugging that the collectionView is attempting to reload the original dataObject, not the filtered one. What am I doing wrong:
func handleFilterAction(sender: FilterButton){
guard let type = sender.buttonFilterType else {return}
switch type {
case .FilterAll:
return
case .FilterDay:
return
case .FillterWeek:
return
case .FilterMonth:
collectionView?.performBatchUpdates({
let objects = FilterDataManager.filterDataWith(currentLocalData: &self.eventObjects, filterOption: .ThisMonth)
self.eventObjects.removeAll()
self.eventObjects = objects
}, completion: { (completion) in
self.navigationItem.title = "This Month"
self.collectionView?.reloadData()
})
}
self.handleShowFilterView()
}
The eventObjects is what the collectionView should be reading for the data:
override func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
return eventObjects[section].sectionObjects.count
}
You call performBatchUpdates when you want to animate the changes to the collectionView. iOS expects you to make calls to methods such as collectionView?.insertItems(at: [IndexPath]) and
collectionView?.deleteItems(at: [IndexPath]) to let it know what you are inserting and deleting so that it can animate it. For both of these calls, you pass in an array of all of the IndexPaths being inserted or deleted.
When you do this, iOS has expectations for the number of items that are now in the collectionView. The formula is:
newItemCount = previousItemCount - deletedItemCount + insertedItemCount
In your case, you modified your model, but you never called the insertItems and deleteItems methods, so iOS still thinks all of the items are there. It is this disconnect between your model and the collectionView that is causing your problem.
To fix this, you need to do one of the following:
Call deleteItems and insertItems with the array of IndexPaths that you are deleting and inserting (call delete first).
Or, forget about performBatchUpdates and just update your model data and call reloadData.
Also, make sure numberOfSections is returning eventObjects.count.
I have a custom table view cell with two buttons. If either one is pressed, I want the table view to delete the row. I already know the code for that:
myArray.removeAtIndex(indexPath.row)
tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
I just would like to call this from my custom cell. I have it set up like so:
#IBAction func handleDecline(sender: AnyObject)
{
// Remove table view row
}
#IBAction func handleApprove(sender: AnyObject)
{
// Remove table view row
}
How would I go about doing that?
You should not handle deletion of a cell from the cell itself. It violates MVC pattern. Events should be delegated to the view controller and handled there with deleteRows method like this:
tableView.deleteRows(at: [indexPath], with: .fade)
Also tableView's dataSource must be updated accordingly, otherwise app will crash.
Here you can find an example of how you can delegate an event from cell to view controller
My TableView is doing some kind of auto-scrolling after any kind of updates are applied to it. If I were to append a new element to the array that contains the items which are presented in the UITableView, for some reason my Table View scrolls up somewhat randomly up around 50% up the middle of the contents of the TableView.
Here's the function that deals with updating, not inserting an item into the Table View:
func updateLastMessage() {
var section = msgSections.count - 1
var row = msgSections[section].msg.count - 1
let indexPath = NSIndexPath(forRow: row, inSection: section)
self.tableView.beginUpdates()
self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
self.tableView.endUpdates()
}
This function above works perfectly, but after I call reloadRowsAtIndexPaths on self.tableView, the table view automatically scrolls up 50% of the contents of the Table View. I get exactly the same result if I were to insert an item instead:
self.tableView.beginUpdates()
self.tableView.insertRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
self.tableView.endUpdates()
Also, if I were to comment out both beginUpdates() and endUpdates(), there seems to be no effect to the scrolling.
I only know of one hack to somewhat get around this issue by using setContentOffset to return the scroll position back to where it was before a message was updated, or a new message is inserted:
func updateLastMessage() {
let currentContentOffset = self.tableView.contentOffset
var section = msgSections.count - 1
var row = msgSections[section].msg.count - 1
let indexPath = NSIndexPath(forRow: row, inSection: section)
self.tableView.beginUpdates()
self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
self.tableView.endUpdates()
self.tableView.setContentOffset(currentContentOffset, animated: false)
}
This hack doesn't work in my favor, because it scrolls slowly to the top and then jolts back to where it was which looks kind of bad.
Does anyone know exactly what could be the mechanism that's causing the TableView to scroll up so much after any appended item or updated item??
It seems to work perfectly and the animation looks very nice as but only when there aren't any items in the table view.
Never call reloadRowsAtIndexPaths: withRowAnimation: inside beginUpdates() and endUpdates().
The tableView will automatically call the necessary reloading of rows at the end of endUpdates().
Just call beginUpdates() and endUpdates() without any code inside. It'll work.
I am developing news feed and I am using uitableview to display data. I am loading each cell data synchronically in other thread and use protocol method to display loaded data:
func nodeLoaded(node: NSMutableDictionary) {
for var i = 0; i < nodesArray.count; ++i {
if ((nodesArray[i]["id"] as! Int) == (node["id"] as! Int)) {
nodesArray[i] = node
CATransaction.setDisableActions(true)
self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
CATransaction.setDisableActions(false)
}
}
}
The problem is that when I scrolling down (while tableview updating), tableview push me on the top. I was searching answer on this problem, but nothing helps me. I already tried to disable animation:
CATransaction.setDisableActions(true)
self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
CATransaction.setDisableActions(false)
2)
UIView.setAnimationsEnabled(false)
self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
UIView.setAnimationsEnabled(true)
But the story always the same.
I have the desired effect when I simply don't use self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.None)
, but in this case data reload only if I scroll down and then return back to cell.
Maybe the problem is that I use auto layout and tableview recalculate its height every time? But I don't know how to fix it
You can build the reload mechanism yourself.
Iterate over all visible cells (tableView.visibleCells) and apply the same logic to them as you would in -tableView:cellForRowAtIndexPath:.
If you need the index path to perform this update, you can ask the table view for it (-indexPathForCell:).
Background: In a tableView, each cell contains a button shown as an image. The effect I wanna show is that when I click the image(button actually), the button's image change to another one.
Bug: Say there are many data (over one page), and if I click one cell's button, the button's image will change BUT with a side effect that the whole tableView will first scroll up a little bit(like a bounce effect) then scroll down to the former place.
What I've done:
in ViewDidLoad method:inboxListTableView.estimatedRowHeight = 60
inboxListTableView.rowHeight = UITableViewAutomaticDimension
When I clicked the button (true and false represent different image and the definition in tableView(cellForRowAtIndex:) method):
let cell = sender.superview?.superview as InboxListCellTableViewCell
if let indexPath = inboxListTableView.indexPathForCell(cell) {
let actionToUpdate = actions[indexPath.row]
actionToUpdate.imageButton = !actionToUpdate.imageButton.boolValue
var e: NSError?
if !MOContext.save(&e) {
println(e?.description)
}
}
Then in Fetch Result Controller Delegate method:
func controllerWillChangeContent(controller: NSFetchedResultsController) {
inboxListTableView.beginUpdates()
}
func controller(controller: NSFetchedResultsController, didChangeObject anObject: AnyObject, atIndexPath indexPath: NSIndexPath!, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath!) {
switch type {
case .Insert:
inboxListTableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)
case .Delete:
inboxListTableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
case .Update:
inboxListTableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)
default:
inboxListTableView.reloadData()
}
actions = controller.fetchedObjects as [Action]
}
func controllerDidChangeContent(controller: NSFetchedResultsController) {
inboxListTableView.endUpdates()
}
I think the bug may caused by two aspects: CoreData and Self sizing cells (dynamic cell height). Because I didn't hit the bug when I use array to hold actions ([Action]) instead of CoreData. However, when I comment inboxListTableView.rowHeight = UITableViewAutomaticDimension this code, it didn't "bounce back/ scroll up" but the height of the cell is fixed.
Any ideas? Anything can help! Thank you:)
I had the exact same problem: a little bounce when using dynamic cell heights. The difference in my case is that I didn't use NSFetchedResultsController and I also changed the heights of the cells (expand and collapse them).
After a lot of experimenting I've found a simple solution. Just call scrollToRowAtIndexPath after reloadRowsAtIndexPaths. It worked for me.
tableView.reloadRows(at: [indexPath], with: .none)
tableView.scrollToRow(at: indexPath, at: .none, animated: true)
I call this code when I expand and collapse the cells.
I hope you can use this in your project.
I think the pragmatic solution to your problem is to simply not use the NSFetchedResultsControllerDelegate method for this particular update.
You can change the image of the button directly in the button handler. You have to check for this situation in the .Update case of the fetched results controller delegate and make sure you don't call the reloadRowsAtIndexPaths method.
Now you are avoiding the automatic UI-update mechanism and the issue should not occur.
BTW, it is very bad practice to rely on the table view cell's view hierarchy for accessing the index path (superview.superview...). A few years ago, Apple changed the way cells work and code that relied on similar paradigms broke. The same with collection view cells.
Instead, do something like this:
func buttonHandler(sender: UIButton) {
let point = sender.convertPoint(CGPointZero, toView:self.tableView)
let indexPath = self.tableView.indexPathForRowAtPoint(point)
}