I have a UITableView with rows of dynamic heights, many of which contain UITextViews. When the user starts typing in one of the textviews, I have the cells grow to accommodate the size of the textview content using the begin/endUpdates method. Using this method allows the cells to resize without losing keyboard focus on the textview, an important aspect of my app.
However, when I call begin/endUpdates, it reloads the heights for every cell that I have, and I was wondering if there was any way to only recompute the height of a cell at a particular indexPath while the user is typing. I want to do this because my heights for the other cells are expensive to compute as they have dynamic content. I know I could write some height caching code, but I was wondering if there was any method to only recompute the height of a specific cell or set of cells in a UITableView without losing keyboard focus / reloading the data content of that row?
I am using ios8, but will take an ios7/8 solutions.
Create of array of NSIndexPath's. If you have just one indexPath, add just this to the array, and use this method:
[self.tableView reloadRowsAtIndexPaths:[NSArray *array] withRowAnimation:UITableViewRowAnimationAutomatic];
but i think this method, will also hide the keyboard, never tried.
Doesn't seem like this is possible to do for only a single row. I ended up building a caching system for row heights so that at least it is faster to return heights for all cells.
Related
I am working on a quite complicated case
I have a nested UICollectionView
The outer UICollectionView A is for vertical scrolling,
and it's the first cell, is UICollectionView B, for horizontal scrolling.
It has been implemented perfectly, but now there is one more requirement
When scrolling the first cell to the second page, there is one more banner appeared on the bottom of the first cell.
Therefore I need to update the height of cell when scrolling.
If I try to call invalid layout when scrolling, it will be very low efficient. Are there any more methods to support it?
Solved.
First after received the data from the server, each cell height will be calculated and [collectionview reload] will be called.
Then after layouting the collectionview, the size for each cell is cached according to the indexpath.
To implement the 'realtime' resizing, the gesture will call a resizing function directing through a delegate, and directly modify the size cache and call [collectionview.layout invalidlayout].
It looks smooth.
The problem I am facing is that when I send a data to UITableView then I send a command to scroll the table to bottom. If cell heights are constant then my scrollToLastCell takes to last cell but with dynamic cell heights it doesn't always takes to last cell.
I want to know is there any way when I can be sure that all cells of my tableView is finished resizing and then I trigger scroll to bottom?
In the Docs Apple states
Important
If your table view includes self-sizing cells, headers, or footers,
you must provide estimated heights for those items.
https://developer.apple.com/documentation/uikit/views_and_controls/table_views/estimating_the_height_of_a_table_s_scrolling_area
Given that, I'd suggest you to go ahead and use tableView(_:estimatedHeightForRowAt:) method
I'm implementing a chat functionality in my app, and I'm rolling my own UIViewController to do so. I'm using a UITableView instead of a UICollectionView because it fits my needs better.
Some of my messages are text-based (which can be multi-line) and some of them are image-based. I also have some cells in place to show headers (timestamp information) and footers ("Sending...", "Delivered", etc.).
When I build my data source, I am calculating the height needed for each of these cells, and returning that data in my tableView:heightForRowAtIndexPath: method.
I am trying to take more control over this process because automatic sizing of cells using auto layout doesn't work all that well when I want the UITableView to spend most of its time at the bottom, rather than at the top.
So, I have the following needs:
When the view loads, it should start fully scrolled to the bottom
At that point, the UITableView's contentSize should be correctly calculated
Inserting new cells at the bottom of the UITableView should work well and also animate well.
The problem I'm finding is that only some of my cells have their height checked by heightForRowAtIndexPath:.
For instance, here's a particular case:
I have 100 messages + 32 header/footer cells (132 total cells)
In viewWillAppear: (or viewDidAppear:, it doesn't seem to matter), I call this:
int lastRow = (int)(self.dataSource.count - 1);
NSIndexPath *lastPath = [NSIndexPath indexPathForRow:lastRow inSection:0];
[self.tableView scrollToRowAtIndexPath:lastPath
atScrollPosition:UITableViewScrollPositionBottom
animated:animated];
It doesn't change much whether the animated variable is YES or NO. YES seems to call a few more times, but both of them only really call for values at the top and bottom (beginning/end) of my data source. This means that my calculated content height (which is correct) is not in line with self.tableView.contentSize.height.
If, however, I manually scroll up through all of the cells, everything gets sorted out and the UITableView is finally aligned with my calculated height.
In addition to the initial view needing to scroll to the bottom, I also want to be able to add new messages to new cells at the bottom of the UITableView and then animate them into view. That really doesn't work well if I let the UITableView manage its content size and its own animations.
Based on Apple's documentation, I expect it to call heightForRowAtIndexPath: for every cell. I'm getting that from here:
There are performance implications to using tableView:heightForRowAtIndexPath: instead of the rowHeight property. Every time a table view is displayed, it calls tableView:heightForRowAtIndexPath: on the delegate for each of its rows, which can result in a significant performance problem with table views having a large number of rows (approximately 1000 or more). See also tableView:estimatedHeightForRowAtIndexPath:.
So, my basic question is how I can force UITableView to let me set all of these values. I'm using auto layout within the UITableViewCell instances themselves, but I want to have control of cell sizing, rather than letting UITableView do it. Any suggestions?
Just adding tableView.estimatedRowHeight = 0 will solve the problem.
So, my problem is pretty simple. I have a UITableView in a UIViewController. The tableview has dynamic cells (custom cells with images , text, etc.. from a subclass I created) and these cells belong to a subclass I created. Everything is going fine since the content is different on each cell. The problem is that when I scroll the scrollview of the cell which is horizontal ( I have a UIScrollView in the subview of the cell. I created this scrollview on the cell subclass), on let's say, indexPath.row == 0, and scroll the tableview vertically, after about 8 cells, the ninth cell has the scrollview scrolled as well. This is because of dequeuereusablecells, so the ninth cell is actually the first one, only displaying different content but since it is the first cell, it has the same background operation (the scrollview scrolled).
I tried to unscroll in the cellForRowAtIndexPath: but although this solves the problem it creates another : The first cell that was scrolled is not anymore. So, to solve this new problem I am planning on adding a workaround here that is a dictionary of [Int:Bool], that is, the indexPath corresponding to a Boolean value. If I scrolled the first cell, then 0:true. If I reach the ninth cell (which is equal to the first cell, but with IndexPath = 8 ), I unscroll the cell's horizontal scrollview. If I come back to the beginning of the tableview and reach the first cell, I scroll the cell's horizontal scrollview back. What do you guys think?
The other workaround I can think of is just not use dequeue reusable cells since I don't think I will have more than 30-50 rows on my tableview.
In terms of performance, which operation is better?
Firstly, I would suggest you to carefully analyse whether removing scrolling offset from the first cell is such a bad idea. If I am a user and I scroll down to the very bottom, making the first cell invisible, are you sure that I want it to return to the scrolled position after I scroll back to top? The answer might be Yes, but you should think about this carefully because it might lead you to the simplest solution.
However, in case you really need to do it, I would have a variable which stores the state of the scrolling for each row. If you have an array of objects from which you pull necessary properties (title, image etc) you can add this as an extra property to these objects. Otherwise, you can create an array which will be storing this info (I would prefer an array over dictionary for this task).
Fundamentally it's an issue caused by table view cell reusability. You can have workarounds, but I'd say that, things that aren't supposed to be reused should not be reused.
If your cells are all similar (with minor differences), you could use just one cell identifier; If you have very different types of cells, say, one type has a horizontal scroll view inside, one type just has some labels and images, you might want to consider to have two identifiers, so cells that have UIScrollView won't be reused for normal cells.
And at the same time, you can still do necessary cleanup works in prepareForReuse: to make sure cells that just get dequeued have a fresh start.
If I have a UITableView with each cell having a different layout. For example, cell 1 has one text field, cell two has two text fields and so on, in this case height of tableview cell varies based on how many text fields it has one below the other. For this specific scenario, will I be able to make use of reuseIndetifier and reuse the cell.
Is tableView reuseIdentifier useful only when layout of each cell is same? Or can I still reuse cells by making use of single identifier but adding textfields in cellForRowAtIndexPath dynamically?
I experimented a bit. I can do some basic reuse of cells by having a cell with empty template/blank cell. But in the cellForRowAtIndexPath I can dynamically create text fields and add. This works perfectly fine, allowing me to add as many number of views required to be added to TableView cell. I am using blank cell, which will be reused on scroll. However I am not sure that will be the impact on performance when I create and add UI elements dynamically to the cell in cellForRowAtIndexPath. Any ideas there?