I am using an NSFetchedResultsController with a data source that is updated in the background. This is working really well - as new objects are saved to the managed context they appear in the UITableView. However, this leads to the problem I'm having.
When you swipe to delete a cell, putting the cell into edit mode, if at that point an object is created which pushes the cell down in the table view, the position which the cell occupied will be in edit mode, and not the cell you selected. Basically, the UITableView retains the edit mode on the original index path, without adjusting for the movement of cells.
Is there any way to get around this? Thus far everything I've tried has lead to a dead end.
reminds me of a problem i had when reordering uitableview cells.Look at 'Responding to changes' in NSFetchedResultsController reference. It shows a way to temporarily disable the change notification. I used it for reordering, maybe you can get inspiration from it to solve your problem too.
kind regards
y
Related
I am working on Accessibility. I am using XIB file and I enabled all the views which need to be read by voiceover.Now the issue is first cell in tableview is reading twice by the voiceover. That happens only first time. I have multiple cells in tableview. But Voiceover reading first cell that too first time. If I swipe to next cells and come to the first cell again it reads only once.
Its very Inconsistent behavior. I could not able to find out the problem. I tried by passing nil values to both accessibilityLabel and accessibilityValue of the cells. But no impact on the Issue.When I disable the accessibility from the XIB file and enable it by programmatically also, but no Use.
Any Suggestions on this would be helpful.
You positing the UIAccessbilitypostnotification for the table with (Screenchange notification), will leads to read twice.
Dont post screenchange notification for Table view. UIKit will handle that by default.
My tableview that used to smoothly reload the sections and rows is now slow when running on iOS 7. When I reload the whole tableview table is loaded instantaneously, but calling reloadRowsAtIndexPaths or reloadSections (with UITableViewRowAnimationNone) takes somewhere around a second to complete.
I'm not using AutoLayout for this section of the app yet. The cells are laid out in separate Xib files with the corresponding custom classes
Do you have auto layout enabled for your cell views? Are you reloading your table view when it is not visible (for instance, when a detail view controller is pushed)? This seems like a known bug. See this question/answer. Apple bug report: rdar://15175803
Basically, you have a multi tiered solution, which is not perfect but will give you satisfactory results. First, this is always true, optimize your constraints in the table view cell. If you have constraints modified dynamically, make sure you are not causing needless layouts and drawing. Second, do not update your table view if it is not visible. This feels like a hack, but there is no other option (well, there is one, but it involves disabling auto layout, which is not optimal at all, so let's ignore). You can test in your view controller if the tableView.window property is nil, which would indicate that the table view is hidden. If it is not hidden, update normally, but if it is, do not update. Just set a flag that the table was updated. On viewWillAppear: call reloadData to update the table. You can preserve selection by querying the table view for selected indexpaths and selecting them again after reloading the data.
I have 2 questions that I am having trouble answering.
I have a UITableView and when you touch a cell, it changes its height and inserts a sub view with some detail.
The problem is that when I select another cell, there is no obvious way to collapse the other cell. What I did as a temporary fix is run a loop whenever you select a cell, and on each cell, if its not the one you selected, it collapses it. This does not seem efficient, does anyone have an idea?
Second question is, whenever I collapse a cell, it animates. but it removes the detail subview kind of jarringly, is there a way to wait till the cell is done animating to remove it? I cannot find an appropriate delegate method.
Thanks in advance.
Perhaps the best way would be to have a variable that stores the index path (row) of the previously touched cell. Then, test to see if the current cell's index is not equal to the previous, collapse the previous cell and open the new one.
For your second issue, can you not animate the collapse before you remove the subview? I assume you're using [UIView beginAnimations] (or something similar). Set the duration of the animation [UIView setAnimationDuration:1.0], and then after you commit the animations, do [self performSelector:#selector(collapseCell) withObject:nil afterDelay:1.0].
I've not tested this, and I'm going off of memory, so sorry if it doesn't work as you'd hoped, but perhaps it can get you going in the right direction.
Edit: Apologies, I didn't see your "Core Animation" tag. The second solution may not be right for you.
I have a UITableView with around 10 cells, placed in a view controller in the middle of a program. When I run the program, the table view shows. But if I start quickly selecting random UITableViewCells, the program crashes. I don't know how this is possible because I can do it in another application with a UITableView and nothing interesting happens. How????
EDIT: Nevermind. I fixed it by removing some unnecessary statements.
Check with your coding.May be you have done some silly mistake at the time assigning text to the cells are some where else. Look into your coding.
For your reference you can refer this link.
http://iphonesdevsdk.blogspot.com/2011/04/uitableview.html
I have a UITableView Controller and a UITableView. I have everything set up using the delegates etc, and it populates fine. I notice a small bug however with the following method:
:cellForRowAtIndexPath
I am noticing that this method is continually called every time I scroll the table. Even after the table is populated, it continues to call. Basically, a cell moves out of view, when it comes back in view, it is calling it again. I had NSLog print out the cell contents within that method, which is how I know it continues to call.
Should that function not just call once per cell, to populate it, then be done?
Nope. That's called every time a cell is needed, and a cell is needed every time one is rendered.
UITableView is a very clever little critter. It literally keeps only the cells it's displaying, plus a cache of literally two or three more. When the time comes to scroll a cell on that wasn't on, it can be asked for a cell from the cache, and if there is one, it gets reused.
This way HUGE data sets can be displayed in a UITableView, because there really aren't a large number of cells in memory, only the ones on the screen and a small cache.
This is correct behavior. It has to do with the dequeueing of UITableViewCells. That is why cell reuse is important. This way there are ideally a finite, small amount built in memory that continually get reused.
Check out the docs for more info and code samples.