I am creating views at run time using heavy data, and adding these views to a UIScrollView.
The problem here is,it takes a lote of time to create the screen, which is not so good user experience.
I want to create initialy only for the part of screen that are visible, and add/create the others views when scrolling the UIScrollView.
Any tips about the best approuch?
Thanks in advance
You can use the UITableView, set cell separator to none and use variable height of row cell. Do as you always do with UITableViewCell i.e. deque cell using identifier.
This is the best approach to deal with the memory issue and for large amount of data.
Also you can do the same for UICollectionViewCell too.
Related
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 am implementing CollectionView with custom layout. It have vertical scrolling.
I want to make that some cells will be sticked to the top while scrolling like section header in tableView.
The idea is to create day collectionView with time. And while user will be scroll thought time the current hour will be sticked to the top(if it will be not visible and hidden by top). It will be only if the current hour hidden by top, not by bottom. And the other items should be scrollable like usual.
I think that I should not use supplementaryViews here
Is it possible and how can I do it?
You need to override shouldInvalidateLayoutForBoundsChange so it returns YES. This means layoutAttributesForSupplementaryViewOfKind and layoutAttributesForElementsInRect are called when the UICollectionView is scrolled, and in there you can then calculate proper frames for your views, including the sticky views. If you have a complicated UICollectionView, this may lead to bad performance, but as far as I know it's the easiest way to do this for now. Your other bet is looking at invalidation contexts, but they're quite badly documented. If you still want to experiment with those, you could take a look at Using Invalidation Contexts for UICollectionViewLayout
Take a look at UICollectionView's supplementaryView.
Apple's Collection View Programming Guide
I want to add a subview to a UICollectionView in order to make a left panel that scrolls with the collectionview.
Using
[self.collectionView addSubview:myView]
all touches become disabled and I can no longer scroll the view. I've read that adding a subview to a collectionView like this is bad practice.. is this true? Why does it disable touches from reaching the collectionView event when
userInteractionEnabled = NO
I'm trying to do this: imgur link by grabbing the frame position of the first cell in each section, and adding a dot with to myView with the same y value.
Thanks for any help!
Adding subviews using the addSubview: method to a UICollectionView is very bad practice. It can cause a lot of different problems in the normal behaviour of the CollectionView. It can obstruct the views underneath it, capture the touch events, preventing them from reaching the actual scrollView inside the CollectionView, etc. The subviews added using this method will also not scroll as the other elements in the CollectionView do.
The correct way to do what you want is to implement a new type of UICollectionViewCell for the dots, and compute their locations in the prepareForLayout and layoutAttributesForElementsInRect: methods. Basically you'll have either one or two cells in each row. Which ones will have two rows will be determined by you in the methods I've mentioned.
In fact, Apple's docs have a perfect example that's even more complex than what you're trying you achieve. You should check it out from this link.
May I know the purpose of that scroll view ? Because, if you're looking for a subview that displays only a label or image etc., You can use custom collectionview cell instead if I am not wrong... Hope it helps :) :)
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?
I have a slightly complicated system that I am having some reuse issues with, wanted to get some feedback. Basically it is a vertical tableview, and each cell contains another tableview that is rotated 90 degrees, so that each cell scrolls horizontally. Each horizontal cell is also set up to scroll infinitely with paginated responses from an API. I am having issues where cells are copying on top of each other when the vertical table is scrolled down. I have reuse identifiers set up correctly and in each of the horizontal tableviews I am running the following:
- (void)prepareForReuse
{
[_horizontalTableView reloadData];
}
If I turn off reusing cells the issue doesn't happen, but the vertical scrolling performance suffers. I am wondering if its possible that reusing cells in this type of a set up just isnt possible? Any experience with this is helpful. Thanks.
This is not a direct way to solve your issue, but I believe if you use a horizontal scroll view inside each vertical cell, you will have this done faster and with less weird behaviours. I also believe this is not a standard way, so weird stuff will happen.
All you do is set or extend the content size of the scroll off screen continuously to create an infinite scrolling behaviour. Create views within the scroll view pragmatically to simulate each cell. Hope this helps.