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.
Related
I am facing a weird issue, UICollectionView reuses cells even if there are enough space in screen and not scrolled also.
I have only two cells in the iPad screen, still every time with reload data, cells getting reused alternatively like below
First time reload - First and Second Cells appear with address 0x00007ff3f2c1a8b0 and 0x00007ff3f2830040 respectively
on the same screen - Second time reload - cells appear with address 0x00007ff3f2830040 and 0x00007ff3f2c1a8b0 respectively.
Can any one help me understand for this behaviour of collection view.
Thanks in advance.
When you call dequeueReusableCell(withIdentifier:) method, you should always expect it to be reused. You cannot predict the order of the cell dequeue.
If you want to be prepared for it, use prepareForReuse() method.
I am using Xamarin iOS and my table view contains multiple types of cells.
All the cells have dynamic height and different contents with multiple sections.
Here suppose I have total 10 cells out of which few are visible and others are hidden. Based on user action, It depends on whether to show or hide the cell.
In this scenario, If the number of cells is less, It's somehow working fine. But flickering and blank space are showing when the number of cells increases.
You need to reload only appropriate section or even rows instead of reload whole tableview.
Please checkout this solutions.
Reload sections in UITableView
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've implemented a pull down to refresh that sits above my UITableView.
However, UITableView also has a default setting where if you push up (to reveal rows at the bottom of the table), it also reloads the table data. Since I already have pull down to refresh, I want to disable this. How do I do that?
Thanks!
EDIT: I want to load all the rows of the UITableView at once, not just the visible rows, because I'm not loading too many rows anyway.
It's not that it's "reloading" the cells. If they have been dequeued, then they are being loaded. If you don't want those cells there, then why do you have them in the first place? If you scroll them off the screen they normally get dequeued to improve performance of the tableview. If you don't want this behaviour, then you may not want to dequeue your cells, but tableview performance could be drastically affected.
I have 3 uitableviews in a single uiscrollview. Each uitableview is full length and not scrollable so that the outer uiscrollview scrolls them together. This works fine except the uitableviews believe all cells are visible so that all are created up front. Even this is acceptable except each call has an image view (a thumbnail) that is loaded asynchronously from a url. I am trying to figure out how to limit the image loading to only visible cells but still allow the user to scroll the outer uiscrollview (thus mimicking the uitableview behavior).
The alternative design of a single table with cells that show 3 cells each doesn't work (based on other design requirements) so I am stuck with some way to limit the image downloads. The largest number of cells will be 125 or so. The uiscrollview delegate doesn't seem to have enough calls to allow updating cells on the fly but I could be wrong. Any ideas?
Maybe just do a custom check : if the tableView is not visible (because not in the bounds of your scrollView), then do not load the images (or the cells) of the tableView in "cellForRowAtIndexPath".
If the tableView is visible, then call reloadData and display the images.
You can check all this with the scrollViewDelegate methods.
TableViewDatasource Protocol implements:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
for a full table that is not in bounds you can limit update simply by comparing the tableview pointer parameter to your actively showing tableviews and skip your non-visible tableviews.
For Cells: This is a more difficult one considering that you are implementing 3 on the same scrollview. This would be a bit easier if you implemented 3 separate tableviews each that are standardly implemented. The reason for this statements is, that the routine if implemented above by Apple's protocol really does only get called for the cells that are currently needing to be on screen. In this way you could implement your image background loader inside of the above defined routine, and you would indeed get what you wish. I have done this and it does work.
Another answer:
perhaps you should look into a custom tableview where you define your own custom look and feel for a single tableview that incorporates all the information you wish into this single table thus allowing you to implement the other half stated just above.
To give a better answer, I think I would have to dig deeper into what you are attempting to ultimately accomplish.
Appears I can simply use the UIScrollViewDelegate scrollViewDidScroll call and then use the scrollview's contentOffset.y to trigger the thumbnail for any cells which are visible (or about to be) using tableView indexPathsForRowsInRect for each tableview. My cell subclass has a method to trigger the thumbnail download.
The scrollViewDidScroll delegate method seems to be called for every pixel as you scroll which is perfect. I thought it might be too slow but so far it's not a big deal. The only issue to make sure I always check the visible cells if I sort them or something.