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
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.
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 need to make a deep copy of a UIView containing several subviews. Please help me figure out how to do this? I've done some searching on google and SO and not found anything that does what I want.
Explanation for those who would like to know why: I have an infinitely scrolling UIScrollView where, of course, the contents repeat. Each 'set' of the contents (for example, say 26 UIButtons labeled A-Z) is contained inside one view. This is the view I need to make a deep copy of, so that I can display multiple instances of it onscreen within the scrollview.
I cannot simply recreate the structure of the view containing the buttons, because pressing the buttons calls a function of a class that my UIScrollView subclass does not have access to. Nor would I wish to recreate them, because it seems a waste to go through the logic to recreate and place all subviews in the container view when I could simply make a deep copy instead.
Can anyone help me?
(Posted from my comment on request)
Aha right I see now. I think the only way would be to create more copies at runtime and hide them; else you'd have to iterate through all subviews, re-create all frames, colors etc... but as you say you'd then likely run into issues copying button targets etc - but there might be something useful to help accomplish that here:
How to get UIButton Target, Action and Control events?
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
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.