I have a UICollectionView that is filled with images, videos, and sound bytes. Everything is working great! I am however, concerned about bandwidth usage.
I am uncertain exactly how UICollectionView with dequeued-reusable cells work, in regards to when these items will be downloaded from storage.
Let's say I have this simple cell.
selfieCell.imageView.sd_setImage(with: URL(string: message.stringOrKey), completed: nil)
return selfieCell
For purposes of answering my question, lets say I have 100 of them in a collection view cell, and only 3 cells are shown at a time.
Do all 100 images load when UICollectionView is loaded?
Or does the UICollection view wait until the cell is about to be shown to set the image (and thus download the file?)
Thank you for your help.
Only 3 cells are shown at a time
The loaded cells are only the visible ones when you scroll cellForItemAt is called and other cell is deququed from the ones who will hide at top same when you scroll up again
Also caching image like sdwebimage won't load it again from server when the relevant cell is shown again
Related
This video demonstrates the issue I am having
UITableView screen lag
I am loading a xib file with a fair bit of stackView and UIViews into my tableview cell. Each cell takes up about 80% of the screen so you would see two cells at max.
I am experiencing a small lag when I am scrolling to the third cell. If I scroll back up again and scroll down like what I did, the lag does not appear to be there anymore and the tableView scrolls smoothly for the remaining cell. If I reload the table and repeat the above step, I will get that lag again when third cell is just about to appear.
It "feels" like the program takes longer to load the xib file in cellForRowAtIndexPath for the very first time. And once it is loaded, it could be loaded nice and fast for any other cell. (That is just a feel though)
All my views have static data. I am finding that this small lag decrease as I removed more view from the xib file.
Is this pattern normal?
Note. In the video when I pull to refresh, the table is reloaded. I have reloaded the table just before the video starts. You will see that at the beginning and whenever third cell is just about to appear (or half way through scrolling second cell) there is a small jump in the table. And after that, everything scrolls butter smooth.
Xib file
XibFile screen shot
I was wondering if it is possible to increase the number of preloaded UITableView cells.
The problem is, I have webviews in table cells and when you scroll down, they first show empty screen then load the page. Which doesn't look good.
I thought maybe I can solve this by loading more cells off the screen, so they appear more smoothly.
What do you think about this, is it possible?
You don't need to preload more cells. Instead create a data source implementation that fetches more data.
I am using svgkit, I am able to show svg image in the cell of UICollectionView via adding the svg image to SubView, but it gives me a buggy output, when I scroll up or down the images are getting added to cell making it plastered in the cells, and it also shows the wrong svg in every cell whenever I scroll up or down the UICollectionView, is there a way I could fix that bug? Thanks!
It takes some time for SVGKit to draw your desired image.
If you scroll quickly the image drawn may no longer correspond as the cell may got reused for a different indexPath.
The solution is the same as when you load remote images (https://stackoverflow.com/a/37784212/1049134) which is also isn't instantaneous.
I have a UITableView that reads information from CoreData via the proper mechanisms (using a FetchedResultsController, etc). This information is either textual, or a URL to a local image to load into the tableview.
Data needs to be populated in the table in a bottom-up fashion (similar to a messaging app). I am targeting iOS 8+, but if I use estimatedHeightForRowAtIndexPath, I get terrible jerkiness on 3+ multi line labels and images. The estimate seems way too far off unless it's a one line UILabel. My hunch is that the cell height is being estimated in a top down manner, such that cell heights are growing from top of cell to bottom of cell. This means that scrolling top to bottom is fine, but bottom to top is not, since the cell is being resized "downward" dynamically as I scroll upward.
I am currently using heightForRowAtIndexPath to calculate cell heights. The problem with this is that it takes a very long time for the view to initially load because cell heights are all calculated at once. I am using cell height caching to store cell height so that once the view has loaded, scrolling is buttery smooth.
So my question is this: how do you use heightForRowAtIndexPath without taking the 3-5 second initial load hit?
And follow up bonus question, is there any way to reliably use estimatedHeightForRowAtIndexPath when you have cells that are vastly different in height? We're talking anywhere from 44px to 300px. From what I've read, I can't use the estimatedHeight calculation at all in this situation.
I've exhausted all of the stackoverflow posts concerning estimatedHeight/heightForRowAtIndexPath and I'm now starting to look at the same posts more than once. So I'm stuck.
why woncha stuff a few rows in the table to populate the visible area and after
the viewDidAppear start stuffing older messages on top of the table one or two
at the time with animation none, automatic or whatever.
this way with the postponement of the uitableview population
me thinks you'd get a passable performance.
or you could do it the skype way, postponing population of the table
with older messages until after table bounces off the top edge.
I'm trying to set up a particularly large UICollectionView, and I'm embedding it within a UIScrollView (as per this answer to another question on SO) in order to support scrolling in both directions. I've got it up and running, everything is working perfectly, except that performance takes a HUGE hit as the size of the CollectionView grows.
After some hunting around, I was able to figure out the problem: because that SO answer calls for the CollectionView to be resized so that all the cells are visible at once, "dequeuing" isn't a thing anymore. The CollectionView within the ScrollView has dimensions of 2000x2000 (or whatever), so even though the ScrollView is just the size of the screen and only shows 20 cells or so at a time, the CollectionView thinks all cells are visible and needed right now. Thus, every cell in the CollectionView is generated at once, meaning the page takes a ludicrously long time to appear.
Is there a way to communicate to the CollectionView which cells are currently visible through the ScrollView, so it doesn't generate unnecessary cells and dequeues them as normal? Or if not, is there a way to make a CollectionView that scrolls diagonally, but that doesn't have this problem?