So I nearly have this thing figured out, but I am stumbling over the NSFetchedResultsChangeUpdate when I update my managedObjectContext from a detail view that was entered after searching the table.
I have a tableview generated from a core data set. I can enter a detail view from this table and make changes without any issue. I can also search the table and make changes MOST of the time without any issues. However, on certain objects, I get an "Exception was caught during Core Data change processing".
I tracked this down to the NSFetchedResultsChangeUpdate. I'm using the following code:
case NSFetchedResultsChangeUpdate:
if (searchTermForSegue)
{
NSLog(#"index info:%#.....",theIndexPath);
NSLog(#"crashing at the next line");
[self fetchedResultsController:self.searchFetchedResultsController configureCell:[tableView cellForRowAtIndexPath:theIndexPath] atIndexPath:theIndexPath];
break;
} else {
[self fetchedResultsController:controller configureCell:[tableView cellForRowAtIndexPath:theIndexPath] atIndexPath:theIndexPath]; }
break;
When the table is not being searched, it runs the else method and that works 100% of the time. When the table is being searched, it runs the if (searchTermForSegue) and that works most of the time, but not always. I logged theIndexPath and discovered the following:
When it works, theIndexPath is correctly reporting the objects indexPat, when it fails, the wrong theIndexPath has been called. For example, if I do a search that narrows the tableView to 3 sections, 2 items in first, 1 in second, 1 in third, I get the following nslog:
On first object: index info:<NSIndexPath 0xb0634d0> 2 indexes [0, 0].....
on second object: index info:<NSIndexPath 0xb063e70> 2 indexes [0, 1].....
on third object: index info:<NSIndexPath 0xb042880> 2 indexes [1, 0].....
but on the last object: index info:<NSIndexPath 0x9665790> 2 indexes [2, 17].....
it should be calling [2, 0]
Note that I am simply updating these objects, not deleting them or adding new ones.
Any thoughts would be appreciated!
Okay, I have figured out a hack that seems to fix the issue, but it doesn't seem like the best way to solve the problem! Any thoughts?
I discovered when NSFetchedResultsChangeUpdate was called from a base table, it was only called once, but when it was called from a searched/filtered table it was called twice (seemingly 100% of the time - I suppose this is to refresh both the searched table and non-searched table?). In addition, the first call always seemed to have the incorrect indexPath while the second call had the correct information. The first call would crash the app if the incorrect indexPath was out of bounds.
My "fix" was to ignore the first call if NSFetchedResultsChangeUpdate from a searched table by doing the following
adding to the interface of the tableview.h file:
int changeCall;
then, in the tableview.m file, in loadView:
changeCall = 0;
Then I updated the NSFetchedResultsChangeUpdate to this:
case NSFetchedResultsChangeUpdate:
if (searchTermForSegue)
{
if (changeCall == 0) {
changeCall++;
break;
} else if (changeCall == 1){
NSLog(#"index infocalledtwice:%#.....",theIndexPath);
[self fetchedResultsController:self.searchFetchedResultsController configureCell:[tableView cellForRowAtIndexPath:theIndexPath] atIndexPath:theIndexPath];
changeCall = 0;
break;
} else { break; }
} else {
[self fetchedResultsController:controller configureCell:[tableView cellForRowAtIndexPath:theIndexPath] atIndexPath:theIndexPath];
}
break;
Essentially, using the changeCall int to skip the first call in a searched table update but use the second call to actually update the content. This CAN'T be the best way to fix this problem, but the bandaid seems to work. I would certainly appreciate if someone has a better answer.
In addition, by skipping the first NSFetchedResultsChangeUpdate, the non-searched table is not updated to reflect the new values. I've fixed this by adding a call to reload the table in the searchDisplayControllerWillEndSearch method:
- (void)searchDisplayControllerWillEndSearch:(UISearchDisplayController *)controller
{
[self setSearchTermForSegue:nil];
[self.tableView reloadData];
}
Thanks!
Related
I have a collection view with three different cells. Each of the cells contains a table view. So, there are three table views. I've set tags for each of them (from 1 to 3).
Now, on my view controller (I set it as the table view's data source when I dequeue collection view's cells) I call table view's data source method for the number of rows. To distinguish table views I check each one's tag. Here is the code for that:
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
switch tableView.tag {
case 1:
if unitItems1 != nil {
return unitItems1!.count
} else {
return 0
}
case 2:
if unitItems2 != nil {
return unitItems2!.count
} else {
return 4
}
case 3:
if unitItems3 != nil {
return unitItems3!.count
} else {
return 4
}
default:
return 0
}
}
The problem is, when the first cell of the collection view is shown (with the first table view) it works fine. But when I scroll to the second cell, BOTH case 2 and case 3 get executed. After that, the second table view shows data as expected, but when I scroll to the third one, the method doesn't get called.
I can't figure out why two case statements get called one after another, while everything works fine for the first cell. If you have any ideas why this happens (or maybe, you could suggested a better way of checking table view's), I would appreciate your help.
Actually, the solution is quite simple. The reason of the problem was that collectionView's data source method was dequeueing all the cells one after another, even when they weren't on the screen. Consequently, tableView's inside of each cell were getting set, too. So, their data source method was getting called, hence the problem.
UICollectionView has a property called isPrefetchingEnabled. According to the documentation it denotes whether cells and data prefetching is enabled.
The documentation says:
When true, the collection view requests cells in advance of when they will be displayed, spreading the rendering over multiple layout passes. When false, the cells are requested as they are needed for display, often with multiple cells being requested in the same render loop. Setting this property to false also disables data prefetching. The default value of this property is true.
So, to solve the problem, described in the question, I set it to false as soon as my collectionView gets set.
I have a tableView inside a collectionViewCell and I get an error when I try to reload the data.
*** Assertion failure in -[UITableView _endCellAnimationsWithContext:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3600.6.21/UITableView.m:1610
I tried using Dispatch.main.async and it seems to get rid of the problem. The only thing is that it doesn't reload the data and nothing changes in the tableView
func cleanItems(completion: #escaping (Bool) -> Void) {
Dispatch.main.async {
cell.tableView.beginUpdates()
// Make changes in the Data Source
cell.tableView.deleteRows(at: selectedItems, with: .fade)
cell.tableView.endUpdates()
// Reloading sections accordingly depending on what the user has deleted
// Do I need to reload data here again? It used to work without Dispatch, but it wasn't stable
cell.tableView.reloadData()
// Updating items with if statements to reload data in Firebase
completion(true)
}
}
This doesn't reload the data at all and nothing seems to change. The good thing is that I don't get a random crash, which was the case before implementing Dispatch.main.async
I've retrieved the numberOfRows in each section to see how many rows there are after ending updates.
print(cell.tableView.numberOfRows(inSection: 1))
and I get the same number of rows that are in the current view.
This is crucial, because if the tableView sections are all zero, the collectionViewCell should disappear. And we never get here in the completion block as it says that the numberOfRows has never changed. Leaving us with a non updated tableView.
I solved this by moving Dispatch.main.async outside the function call.
Dispatch.main.async {
cleanItems(completion: { (success) in
etc.
})
}
I have a test for a collection view that works like this:
func testDeleteItem() {
app.collectionViews.staticTexts["Item"].tap()
app.buttons["Delete"].tap()
XCTAssertEqual(app.collectionViews.cells.count, 2)
XCTAssertFalse(app.collectionViews.cells.staticTexts["Item"].exists)
}
After the tap, there is a new screen with the delete button. When the button is tapped, the screen dismisses itself and reloads the collection view. Everything goes as expected in the UI, but I get both asserts failing. In the first count it is still 3 and in the second item it still exists.
I have found the solution, but it's a workaround for wrong API behavior. Collection view is caching cells, that's probably why I have 3 cells, even if I have removed one. Deleted cell is offscreen, so you can test if it is hittable:
XCTAssertFalse(app.cells.staticTexts["Item"].hittable)
To find a count, I have created extension:
extension XCUIElementQuery {
var countForHittables: UInt {
return UInt(allElementsBoundByIndex.filter { $0.hittable }.count)
}
}
and my test looks like this:
func testDeleteItem() {
app.collectionViews.staticTexts["Item"].tap()
app.buttons["Delete"].tap()
XCTAssertEqual(app.collectionViews.cells.countForHittables, 2)
XCTAssertFalse(app.collectionViews.cells.staticTexts["Item"].hittable)
}
I also came across this issue, but in my case, .cells query wasn't evaluating correctly. Instead of .cells, using
XCUIApplication().collectionViews.element.childrenMatchingType(.Cell).count
worked for me and returned the correct count.
Update:
I also found that scrolling the view so that all the cells are dequeued before getting the count fixed the issue. It seems the accessibility framework does not find the other cells until they have been dequeued (I guess that makes sense).
XCUIApplication().collectionViews.element.swipeUp()
I think cells query returns all cells from all the tables currently in view hierarchy. Try to do this app.tables.firstMatch.cells.count, it worked for me.
I ran into this question when I was looking for the same answer, but in Objective-C. For those like me, I adapted #Tomasz's method to count Collection View cells in UI tests:
-(NSInteger)countForHittables:(NSArray<XCUIElement*>*)collectionView{
__block int hittables = 0;
[collectionView enumerateObjectsUsingBlock:^(XCUIElement * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
if (obj.hittable){
hittables++;
}
}];
return hittables;
}
To call it: [self countForHittables:app.collectionViews.cells.allElementsBoundByIndex];.
I had the same issue. Even if the collection hasn't been populated because it was waiting for the response of an API, cells.count >= 1 was always true.
What I did, based on Tomasz Bąk's answer I created an extension to wait for the collection to be populated:
extension XCTestCase {
func waitForCollectionToBePopulated(_ element: XCUIElement, timeout: TimeInterval) {
let query = element.cells
let p = NSPredicate(format: "countForHittables >= 1")
let e = expectation(for: p, evaluatedWith: query, handler: nil)
wait(for: [e], timeout: timeout)
}
}
And on the caller site will look:
waitForCollectionToBePopulated(collection, timeout: {timeOut})
I'm receiving an error indicating that I need to update the number of rows in my UITableView after I have deleted a row. I realise that It's because I've not updated the amount of rows in the UITableView, I'm just not sure how to make this change in the code I have below.
Any assistance is really appreciated.
!-- code
NSIndexPath[] rowsToReload = new NSIndexPath[] {
NSIndexPath.FromRowSection(1, 1)
};
dv.TableView.BeginUpdates ();
dv.TableView.DeleteRows(rowsToReload,UITableViewRowAnimation.Automatic);
dv.TableView.EndUpdates ();
!-- error
Name: NSInternalInconsistencyException Reason: Invalid update: invalid number of rows in section 1. The number of rows contained in an existing section after the update (3) must be equal to the number of rows contained in that section before the update (3)
Your code above is OK. However, you need to call it after you have removed the corresponding items from your data source.
For example, if you are filling your table view from a List<string> (myList) and you wanted to remove the first row:
myList.RemoveAt(0); // remove the item from the list first
NSIndexPath[] rowsToDelete = new NSIndexPath[] {
NSIndexPath.FromRowSection(0, 0)
};
dv.TableView.DeleteRows(rowsToDelete, UITableViewRowAnimation.Automatic);
No need to wrap the DeleteRows call in a Begin/EndUpdates, as you only have one delete action to perform. That is used when you have multiple different actions (eg. DeleteRows + InsertRows) so that the animations are performed smoothly.
#Dimitris thanks for answering my question. I ended up solving the problem by:
calling the reload method on my UITableView
NSIndexPath[] rowsToReload = new NSIndexPath[] {
NSIndexPath.FromRowSection(1, 1)
};
dv.TableView.ReloadRows (rowsToReload,UITableViewRowAnimation.None);
in my UITableViewCell GetCell method
I removed the label, field and button that were included on the first load of the table. Since this screen in my app will be seen only once, when the user loads it for the first time.
First off, as a disclaimer, I am new to objective-c, xcode, and cocos2d. I have found a way in my app to refresh a screen conveniently, but I don't know if it is bad practice. Here's what I am doing. I have a class called Player with a variable NSString *name. I am displaying this and several other variables on the screen using this code in a function:
label = [CCLabelTTF labelWithString:string fontName:GLOBAL_FONT fontSize:font_size ];
label.color = color_back;
label.position = ccp(x+1, y-1);
[self addChild:label];
When a button is pressed, I am modifying player->name along with several other variables. Because several variable are changing (on this screen and eventually others) when the button is pressed I also set a flag to indicate that the screen needs to be refreshed. I then check this code with a scheduler:
if(panelPrev != currentPanel || refreshScreen) //do we need to initialize the panel?
{
[self removeAllChildrenWithCleanup:true]; //clear all objects from display
//Decide which objects to display
switch (G_display_panel) {
case P_Main:
[Display_Main init_Panel:self];
break;
case P_NewGame:
[Display_New init_Panel:self];
break;
default:
break;
}
refreshScreen = false;
}
My first question: Is this an acceptable way to display things to the screen and refresh them? It seemed much more convenient than updating every variable that is being displayed. The buttons are not being pressed very often so I am not concerned about performance.
Second: If it is ok to do it this way, why is it that when I press a button and change the value of player->name I am getting this: "Thread 1: EXC_BAD_ACCESS (code=1, address=...)"? If I step through with the debugger the value gets assigned to player->name correctly and the screen refresh works. But if I just let it run it gets the EXC_BAD_ACCESS when I try to access player->name and the data looks corrupted (e.g. (NSString *) name = 0x15927f80 when I am expecting (NSString *) name = #"Bob").
Some additional details.
I am not setting refreshScreen to 'true' until after changing the value of player->name
To prevent refreshing before the value was truly changed, I set a delay on the refresh. After the button was pressed I would modify player->name and wait about 10 seconds but I would still see the same problem.
Any ideas? Thanks.
try this:
[self addChild:label];
I figured out the problem. It was a memory management issue. I added a getter and setter for the variable using the example specified here: developer.apple.com/library/mac/documentation/Cocoa/Conceptual/… –