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.
Related
I want to customize my tableview. I want to add another tableview in cell. Can we add tableview in cell of another tableview?
Please give me some ideas.
You can embed a UITableView into another UITableView's cell, but due to potential issues with the embedded UIScrollViews it is not recommended.
If you feel like you need a table in a table, first consider if it is not possible to achieve the desired behavior by using sections and cells in the sections (a section in a table might represent the top tableView's cell, and cells in the given section would represent the embedded tableView's cells).
There is no problem with adding a UITableView into a a UITableViewCell, since both of them are UIViews its simply would be translated to adding a subview to a view...
However, keep in mind to consider the following issues:
1- From a user experience perspective, that would be a vertical scroll view inside another vertical scroll view (are you ok with that?).
2- For each cell -in the main container table view-, you would need to handle the table view delegates/datasources. For understanding the logic of how this could be done, you might want to check:
Is it possible to add UITableView within a UITableViewCell.
Putting a UICollectionView in a UITableViewCell in Swift: although it is about adding a UICollectionView inside the cell, it helps to gain the logic of how to achieve such a task.
I'm struggling with wired kind of problem. I have UITableView with one cell. This cell is only holding containerView with childViewController (second tableView). My problem is that, first tableView(parent) must have UITableViewAutomaticDimension row height but it doesn't work (It dosen't know correct size of that cell with second tableView).
How to get correct size of second tableView) ?
Second tableView (inside Cell) have scrollingEnabled turned off (tableView.scrollEnabled = false), first tableView must have correct size of second tableView in order to provide correct scrolling experience.
Since a UITableView inherits from UIScrollView you can use the contentSize property to get this information. This is how the scrollbar works on the side.
I have done a similar thing before (long ago), so the following is somewhat hazy/ irrelevant/ unessecary. There might be some gotchas with unknown/unrendered cell heights in the embedded tableview. I rememeber having to set the tableview height to a large number (forcing all cells to render) fetching the contentSize then resetting the tableview height to the contentSize.height.
Are you shure you really need second table view? If you have just one cell probably you don't need it. I recommend you to calculate table view height as the summ of it's cells heights. If cells of embedded table view have constant height it could be simple. In other case you also could calculate cells height.
I am trying to do something like loading up different type of cells with custom height in a uitableview. The tableview cells are subclassed and consists of labels with the respective constraints. Each cell is having a dynamic height.
Now even before my table reloads the data, I am calculating the height that is required for the resizing of the cells and caching it in my model class so that I dont have to calculate the height when the data is rendered on the device.
To calculate height i did use the tutorial from Ray Wenderlich and I am having the right set of heights applies to the objects.
Now the problem comes. Whenever I am dequeueing the cells there is a
kind of a small jerk that gives me an indication that my cell is
dequeued while scrolling.
How can i make these movement smooth so that there is no jerk while scrolling the view ?
The height is getting assigned in and does get the value as per the current type of data getting loaded.
estimatedRowForIndexPath
Also I am calling layoutIfNeeded from my cellForAtindexPath
Suggestions are most welcome.
It's very hard to say without seeing your code in cellForRowAtIndexPath, and without seeing your cells and their respective code. Here are some general questions I would investigate:
What is the content of the cells and how complex is the view hierarchy in the cell?
Even though you are supplying the correct estimated height, an autolayout pass still needs to happen, and a complex view hierarchy will take time to resolve
Does the cell contain images?
Images that need to be decompressed from a file (UIImage imageNamed:) can be intensive and cause scrolling issues, check images are not bigger than they need to be. If needed, bump this work onto a background thread.
Are you calling a complex method to configure the cell for display in cellForRowAtIndexPath?
Look at the work actually being done in cellForRowAtIndexPath, is there a complex method being triggered in you cell subclass or view model?
Are you adding and removing views to the cell view hierarchy in cellForRowAtIndexPath?
If views are being added, removed, created, inflated from a xib, constrained etc during the cell config, this could slow things down. Try to do only what is strictly needed. Check if there is any code being run internally in the cell subclass during cellForRowAtIndexPath that could be moved to cells initWith... or awakeFromNib methods (ie code that could just run once when the cell is created, rather than every time the cell is displayed)
Also run the Instruments time profiler, see if that offers any more clues
I have tried looking for an answer to this question but so far I haven't got any luck.
Context
I have a UITableView inside a standard UIViewController (NOT a UITableViewController..). I have subclassed UITableViewCell and all the cells in the tableview are from the same class.
Requirement
I would like to find an efficient way to resize the cells based on the scrolling of the tableview. For example, when the cell is at the bottom of the visible list, the height is X. When the cell moves up on the screen, its height should proportionally increase to 2X.
Additional Info
I am close to just ditch the UITableView way and start making my own control that would implement such a feat by subclassing a UIScrollView. However, I would like to see if it is possible before going this path. I did see some very interesting SO posts but nothing that would put me on the right path.
Any hint or help would be highly appreciated.
You would need to respond to the scroll view delegate method scrollViewDidScroll: and implement it to record the cell at the top of the table view and reload the table view. Then your table view delegate method tableView:heightForRowAtIndexPath: sets the cell height by the relationship between the index path and the top cell index path.
Your main issue is performance while reloading the table view all the time.
If you wanted to roll your own solution it would be along the lines of the above description anyway, but you would be able to be more efficient than the table view as the table view will call the tableView:heightForRowAtIndexPath: method once for every row for every reload in order to calculate the total height of the table content.
Context:
Building an app that populates a table that takes in data from a asyc json dump.
The cells are of a custom class (I defined). The main label in the cell can be very long.
It is "placed" in storyboard within a prototype cell but customized via code (pretty standard stuff).
Labels are resized in cellForRowAtIndexPath and rows are resized via heightForRowAtIndexPath -- rows are resized by forcing a call to cellForRowAtIndex like Massimo's answer here
So per the question at hand - I've noticed some interesting (bad) things that happen.
First issue: When the table loads, the rows and labels are dynamically resized correctly! Great! However, when I scroll down and then scroll back up, the label heights will be incorrect -- (for example) the first row was correct at loading. Then when I scroll down and then scroll back up to see it again, it will be truncated. Specifically, the row size will be fine but the label height will change and become truncated to 2 lines only. Wondering if this is because I did both storyboard and coding to customize the cell. Anybody see this before?
Second issue: When I scroll down, while the rows are sized correctly (large), the labels are short (truncated.) Wondering if it's some reverse of the above "potential answer".
"potential answer" is that the rows are all calculated and stored "up front" so that scrolling down/then back up doesn't affect it. However, when cells go "out of view" and are dequeued then when they re-viewed (scroll down/then back up) it will rely on the storyboard.(inappropriately?)
All three of your issues are symptomatic of returning the wrong height in heightForRowAtIndexPath. In my data model classes I have a calculateHeight method that I call in heightForRowAtIndexPath. The model also caches the answer so it doesn't have to recalculate it after the first call. The cell class uses the model's calculated height to layout its subviews.
"ANSWERED" by deleting the prototype cell from the storyboard and making them fully in code, the issue went away. The fundamental workings are still not understood (ie. the interactions between storyboard vs. code when cells are put queued and then viewed again)