iOS UITableViewCell with scrollView with dynamic content - ios

I am trying to create a table view, in which the table view cells contain a scroll view. The scroll view can contain one or two pages of one image view each. Note that the scroll view will only scroll horizontally, so it will not interfere with the Table View's scroll view that will scroll vertically. Depending on the content, I want the scroll view to be updated with these image views, and set the scroll view content size according to responses I receive from a server, instructing the application what images to display.
In order to do that, I initially thought of creating a custom UITableViewCell subclass, and do all my initialisation of the views inside that.
However, I am just thinking about performance and memory. I know that iOS automatically deallocates already seen views and cells, when it needs to, and that it reuses the old cells when it tries to display something new (by using a reuse identifier). However, each cell will contain a scroll view with content size and subviews that will change in each cell. I want to use a reuse identifier to ensure maximum performance.
Can anyone point me in a way in which I can set up the reuse of a cell like this, and change the contents of each scroll view successfully?
Thanks.

you can make the reuseIdentifier dynamic
e.g. "cell_with_1","cell_with_2","cell_with_x" where x is the number of images
that way equal cells can be reused when sensible (e.g. when the number of images in the view is the same): 'worst case' is no reusing and a tad overhead for trying but in general I'd deem it beneficial :)
*the allocation deallocation and the basic adding of the subviews is expensive.. changing frames or images seems reasonable to me

Related

Two vertical collection views and a label between them to scroll all at once as one element

I have two collection views with data loaded from an API. the data varies that means that the heights of each of the collection views should be varying. I have tried putting all of them ( 2 collection views and a label between them ) inside a scroll view but that doesn't work because I cannot tell the size of the contents before the data is loaded. How can I do this?
For many reasons, this is should not be the layout of choice for you in this situation. First, the collection views cannot determine their own size based on the size of their content, because they are in fact scroll views – and it would be weird for a scroll view to always scale to the size of its content, it would never scroll at all if it did. Second, as each of the collection views is a scroll view, you would have a hierarchy of scroll views which is hard to handle for the user, let alone the developer.
What I suggest instead is to use a single UICollectionView with multiple sections. You can also implement your own UICollectionViewLayout to suit your needs.

Two UIViews & one UICollectionView inside UIScrollView (or better approach)

I need to have iOS app with screen like this:
screen
The idea is when user start to scroll down the first UIView to move up until the second UIView reach the top where it will stick and only UICollectionView will continue to move up.
Currently I'm using this structure
UIScrollView (main scroll)
UIView (some banners)
UIView (UISegmentedControl)
UICollectionView (grid with items, scroll is disabled, main scroll is used)
I manage to do it, but I needed to set UICollectionView height constraint manually in the code (calculated based on all items in grid) in order to appear in UIScrollView (everything else is handled by AutoLayout in Storyboard). The problem with this is that UICollectionView think all cells are visible and load them, so the whole recycling & reusing thing does not work. It's even worst because I use willDisplayCell method on UICollectionView to load more data when last cell is displayed, but now it load all pages at once.
My question (actually they are 2)
How can I fix the issue above?
What is the right way to achieve this functionality? Maybe my whole approach is conceptually wrong?
Collection view is a scroll view itself. So maybe you could have same functionality only with Collection view with sections or even custom layout?

Choppy/Laggy scrolling of Collection View with Dynamic Content

I am having a problem where my collection view scrolling becomes very choppy/laggy as I get more and more cells. The screen contains a list of messages and comments for the messages, so every single view is dynamically sized. I have a bunch of custom layout attributes which I apply to handle laying and sizing everything.
I apply the custom attributes to the cells by overriding applyLayoutAttributes: and then calculate all the subviews frames from those.
I already cache the calculated sizes of cells but it is not enough.
I assume that there are some techniques people use to address this problem, like caching layout attributes, or somehow preventing the need to layout a cells subviews everytime cellForRow is called?
I assume this is a common problem since it is a problem I have faced with literally every table I make with dynamic content? I would appreciate any ideas :)
P.S. Rasterizing the cells doesn't help.

Can I load a UITableViewCell directly from a xib with a specific size class or trait collection?

I'm trying to do the following in my iOS app:
Embed a UITableView into a parent scroll view; the table view will have its frame expanded to show all its contents (I need to do this because the table view data is a small component of a much larger more complex screen, and I don't want nested scrolling behavior)
I have different layouts for iPhone and iPad, so the cells in this table view are using size classes defined in a table view cell xib.
Since I want the content size of the table view to be accurate, I don't think I can use UITableViewAutomaticDimenstion as the rowheight, so I implement tableView:heightForRowAtIndexPath: and load an instance of my tableview cell from the nib directly and store that view as a property with which I can figure out how tall the cell should be according to autolayout.
My problem stems here; when I load the cell directly from the nib, on iPad the cell uses the constraints and layout in the 'Any' size class as defined in the nib, which is incorrect because the iPad's layout uses the regular width class only in my nib. This causes my table view cell heights to be wrong and too large in my case.
What I need to know is if there's a way to force the trait collection on the cell I load, such that the proper constraints for my views are used on each device type. I can't seem to find anything in the docs that allows for this directly in UIViews, only in UIViewControllers and I'm not keen on holding an offscreen UITableViewCell in a random offscreen UIViewController if i can help it. Any ideas?
After writing this I found this question: Offscreen UITableViewCells (for size calculations) not respecting size class? which seems to ask a similar thing, and the answer in there worked for me (add the offscreen table view cell as a subview of the tableview, or some other view that provides a trait environment). It's not pretty but it seems to work out.

Keeping reuse capabilities of UITableView when it is nested in a UIScrollView

To implement a rather intricate design of a screen in an iOS app, I have a UITableView nested inside of a UIScrollView.
To keep the logic simple, I implemented a method on the UITableView that calculates its entire height, and i use the result of that method and set a constraint on the nested table view, so that the scrolling logic can be solely on the UIScrollView to deal with. (I forward methods such as scrollRectToVisible from the UITableView to the UIScrollView)
While this works great with small data sets, I have recently discovered the the reuse capabilities of the UITableView are not used, because the framework believes the entire UITableView to be visible when I set that height constraint. A simple log method in the cellForRowAtIndexPath method shows all cells get calculated at once.
My question is, is there anything I can do where I would be able to tell the nested UITableView how much of it is actually visible on screen, and to only compute those visible cells?
I basically need to override whatever part of UITableView that is responsible for calculating what cells should be visible on screen.
The table view will think of itself as filling its whole frame with cells. If you limit the height it will limit the cell count visible. Are you using the deque with reuse identifier method (if not see below)
How can I recycle UITableViewCell objects created from a XIB?

Resources