I have a UITableView which I need to update about 2-3 times a second via NSTimer. The cells in this table have UIButtons which respond to touchupinside. The problem is that this created extreme sensitivity. I could not press the button for too long otherwise it wouldn't register.
That issue was solved in
UIButton oversensitive
How can I solve the problem of regularly updating the table, while at the same time keeping the buttons responding naturally?
Update only the visible UITableViewCells instead of calling reloadData on the table. reloadData recreates the table cells each time it is called resulting in your touch events getting "lost" because they would go to the old deallocated table cells.
Instead of reloading the contents in tableview, try to reload them in a table cell. Subclass the cell and reload the necessary data in a cell. By doing like this, your button will not be created again and again. Only the data will be refreshed.
Related
I have a UITableView that contain about 20 rows in the iPad's viewport. I have a interval timer that will call UITableView's reloadData regularly(post it to UI thread).
Now when I scroll through the UITableView with medium speed (not so fast), that UITableView will refresh with flickering effect.
I have to write a function to manually update the UITableViewCell label by looping through all the items in the array (this array keep all the items that show on UITableView). I will execute this function when timer is running instead of calling reloadData (as I mentioned above). Then the flickering issue is gone.
I believe that reloadData should be better than looping through all the data because reloadData will only refresh the current showing Cells instead of all the rows, but I couldn't figure out why the flickering happens. Anyone know why?
One thing I have to mention is I did use the CellIdentifier correctly to reuse the cell and only create the cell when the retrieved cell is null.
Moreover, I do not have this issue in iPhone and I believe that it is because iPhone has lesser row compare to iPad.
Anyone can give some explanation about this issue?
I had the same problem with flickering when using reloadData. I solved it by using indexPathsForVisibleRows and cellForRowAtIndexPath: to only update the visible cells. Performance is good since I don't have to iterate over the whole data set, but only a limited number of visible cells.
reloadData causes the tableview to recreate the visible cells on screen which can result in a flickering since the cells get destroyed. There are better ways to reload the tableview. Are you using Core Data? If so the NSFetchedResultsController and it's delegate are a great way to update a tableview since it listens to changes in the underlying datasource and only updates the appropriate cells.
I have a UITableViewController with custom cells for static and editable text. Standard stuff, nothing fancy.
The cell data is stored so that when cells are reused, the data is placed back inside them.
The problem is this: when the user has the cursor in a UITextField cell and the keyboard's up, the keyboard is covering three rows in the table view. There's a cancel button at the top of the view controller which is supposed to dismiss the view controller. When I call dismissModalViewController, the keyboard hides, but the UITableViewController wants to refresh the rows that were under the keyboard while the view's going away. However, the view's already in its death throes and I get a crash because the table view's trying to call cellForRowAtIndexPath to update rows that are in the process of being removed.
I tried waiting for the keyboard to hide. No good.
I tried resigning the first responder so the keyboard goes away and updates the rows first before dismissing the view controller, but there's nothing I can find that tells me the data's finished updating.
What I need is some event that tells me that the table is finished updating, or tell the table view to not ask for data from the delegate, or tell the table view to not update when the keyboard is going away.
Or there's something simple I'm missing.
Any help?
If you have not more cells, i advice you to make a different Reusable Identifier for each cell.That very better to save the state of cells after being dequeued
I solved my own problem. Inside cellForRowAtIndexPath, I was setting text inside a UITextField for pointers that may no longer exist. What I did to fix the problem was still create the cell, but before setting the text inside it, I checked if the Cancel button was pressed and if it was, return the empty cell.
I was hoping there'd be a better solution such as waiting for the cells to finish updating, but that doesn't seem to be happening.
I have a tableview with imageviews and textviews in each cell. When my view is loaded one of the textviews is invisible. But when I start scrolling the textview appears, so that my view looks as it is supposed to look. Does anyone know why this is happening?
P.S. I have read about reusing cells when scrolling so I have been very careful to construct my cells correctly.
Without code, no one can give you a exact answer. But for a guess....
Is your data is getting populated after your table call cellForRowAtIndexPath? When the cell populates the first time, no data, so the cell is in it's unformatted state. By the time you can interact with the table and scroll it off and on screen (which calls cellForRowAtIndexPath again), the data has been populated and so the cell looks as expected.
You can test this by putting a breakpoint in your cellForRowAtIndexPath method and check to see if your data objects are initialized or still set to nil.
I have a custom cell that contains a button in a table view. The button is used as a toggle to essentially serve as a "checkbox" for a user to check off certain items in the list. I was having the issue in which the buttons in these table cells seemed to be sharing memory locations as a result of the dequeuereusablecellwithidentifier. When a button was pressed, it would also press every 4th or 5th button in the list.
I changed it to create my cells in a method into an array which then populates the tableview. This works fine for what I am trying to achieve, however it poses an issue when dealing with large row counts. The tableview itself runs quickly, but the initial load can be 3-4 seconds at times when there are over 100 rows. The iteration to create the cells and then populate it to the tableview is quite cumbersome.
What other methods can you populate a tableview with custom cells and buttons while still retaining unique memory for the buttons within?
Any help would be appreciated!
Thanks :)
You definitely don't want to change the way the creation of cells work- dequeuereusablecellwithidentifier is a very good thing for the reasons your seeing.
The solution is that you should store the result of the button/checkbox press in a separate data structure, like an NSArray full of NSNumber. As your table scrolls and cells are reused, you reset the state of the checkbox to whatever state it should be based on your NSArray.
Good luck!
I have a functionality in my table view i.e. when you tap in on cell it loads more cells in below the tapped cell and when you tap again on same cell those added cells gets deleted.
But I have got a strange behavior that when i call below method to delete added cells from table view, the dealloc method of cell isn't being called..(I have placed a NSLog in dealloc method)
[tableView deleteRowsAtIndexPaths:indexPathArray withRowAnimation:UITableViewRowAnimationTop]
and when I call insertRowsAtIndexPaths then new instance of cells are being created, in the instruments I checked that the previous instances remain in memory and new instances are being created again and again.
so please tell me that why is deleteRowsAtIndexPaths not calling release for deleted cell? and some solution for this problem. I am worried because application's real and virtual both memory consumption is keep increasing on continuous taps...
Do you use UITableView's dequeuereusablecellwithidentifier: method in cellForRowAtIndexPath: in order to create new cells?
If not, this is normal. UITableViews keep cells in memory in order to reuse them and avoid having to alloc/dealloc all the time.
You should take a look at this tutorial for example: http://www.mobisoftinfotech.com/blog/iphone/introduction-to-table-view/