I have a few very long collectionViews, all nested inside a scrollView.
since the prefetching range is related to the scrollView, all the cells are "visible" on the scrollView, even though most of them are not visible on the screen at all.
Hence, when calling reloadData(), it reloads all the cells, instead of reloading only the visible cells. it ends up in a very long UI freeze.
Is there a way to load only the cells that are truly visible on the screen?
The "best" way to do this is to put everything inside a UITableView which has UICollectionViews as cells. It sounds horrible (and tbh, its not very nice) but it's really the only "clean" way to do this.
Let the UITableView act as the ScrollView and everything else should work just fine, it should, all in all, be much faster and shouldn't lock up the UI.
Related
This problem is driving me nuts.
I have a prototype UITableViewCell in my storyboard. It contains a bunch of subviews. One of the subviews, a UILabel, is misbehaving.
When the tableview loads and is displayed for the first time, all of the cells look fine. However, as the tableview scrolls down, eventually one of the cells shows up without the UILabel subview. It seems that it is always the first cell that is being recycled.
If I continue scrolling down the tableview, however, as soon as the misbehaving cell is clipped by the top of the tableview (when it begins to be scrolled off the top of the screen), the label appears just as it should.
So it seems that the label is there, and it receives the string that I assign to it in my cellForRowAtIndexPath method. It's just not getting drawn for some reason. I've tried inserting setNeedsDisplay messages in various places, but that hasn't helped.
What is also strange is that I'm using the very same UITableViewCell subclass with a duplicate view hierarchy in the storyboard in a different view controller, and there I don't have any trouble.
Anybody have some idea of how I can start to unravel this mystery?
Thanks!
It sounds like it's only a problem when you use a reusable cell, which means that the values on reusable cells may not be getting set until you're ready to scroll off.
I want to scrolltableview horizontally as well as vertically. How can I do it?
I'd suggest making a UIScrollView the same size as the screen and then making your UITableView bigger than the screen.Drop the TableView into the ScrollView. Set up the scrollview with a high contenSize.width and then tweak it to work as you desire.
The idea with embedding UITableView into UIScrollView seems to be great, however there is a serious gotcha. UITableView is optimized to display only visible viewpoirt area and limiting allocated UITableView cells. In the case it is embedded into UIScrollView, it allocates complete content area of scroll view, i.e. all rows for the UITableView. It goes out of the memory for approximatelly 2000 rows. Since the UITableView.reloadData creates callback in main thread, it blocks main thread to respond to didReceiveMemoryWarning and application is killed on system sole discretion for level 2 warning, which is never received.
It seems that the better way is in subclassing UITableView and extending rows to width which can be scrolled horizontally.
If you are looking for something similar to what is done in 'Pulse', then this tutorial might help you:
http://iosstuff.wordpress.com/2011/06/29/creating-pulse-style-scrolling-horizontally-scrolling-uitableview-as-a-subview-of-uitableviewcell/
It shows how to add a horizontally scrolling UITableView to a vertically scrolling UITableView
I have a UIScrollView with textviews as subviews. Now in my app there are multiple UIScrollViews like these. And depending on the selection I display the appropriate UIScrollView on top of the previous view. This works fine in all cases except when the previous view has been a UIScrollView as well. In this case the behavior I get is of two UIScrollViews stacked on top of each other and both the views capture the scrolling events. The textViews from previous scrollView is also visible (not editable though) and overlaps and causes all sorts of issues. The thing is a full screen UIScrollView placed as subview to a previous view causes problems when the previous view is a full screen UIScrollView as well.
Any pointers on how to overcome this would be great. Is there anyway to notify the parent scrollview of the child's scroll events and move it the exact same way so this mess is masked?
Thanks!
UIScrollView documentation says:
Important: You should not embed UIWebView or UITableView objects in UIScrollView objects. If you do so, unexpected behavior can result because touch events for the two objects can be mixed up and wrongly handled.
As far as I know, it is generally not recommended to embed a UIScrollView subclass instance in a UIScrollView. In one of my projects, which is an IM application, I have a UIScrollView that contains many UITableViews, it works when you try enough but it really takes a lot of effort to handle subtle bugs and make it work properly.
It is really hard to say something useful for your problem without diving in to code, but i can recommend you to not add UIScrollViews one on to another like a stack. I'd try doing it by allowing only one UIScrollView at top, and removing others. When you need to show another one, remove the top one from view hierarchy and add the new one. I wish this helps, good luck.
Found a crude solution by presenting an empty view before I present the next scrollView. Added the scrollView as subview to this empty view (with a BG image) and added the to-be presented scrollView as a subview to it and then presenting this on top of the previous scrollView.
So I have a UITableViewController. The cells in this tableview have the following UIControls:
2 UILabels, one of which has a shadow and a clearColor background color.
1 Custom Progress view resized to be larger and with a different color
3 UIButtons
Functionally, they do exactly what they are supposed to do. However, I've noticed when looking at it on device that scrolling performance quickly tanks and has dropped frames all over the place, even with other interactions like pushing one of the buttons.
So I was reading around today and found http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ this article by the Tweetie guy about how to achieve fast scrolling performance by subclassing UITableViewCell and doing the drawing yourself.
The example works extremely well, but when I tried to adapt it to work with my desired configuration I realized that he isn't using any predefined UI Controls, he's mapping out everything by hand.
While I can see how this would be an extremely efficient way to do things, it strikes me as problematic for things like the progress view and the buttons, and even one of my labels to a certain extent.
So my question is this: Do I need to completely write my controls from scratch if I want my scrolling performance to be good, or is there a way to use the standard UI Controls and get good scrolling performance?
If you're adding custom controls to your cell, you should still be subclassing UITableViewCell, adding your controls in the init function, laying them out in layoutSubviews, etc. - just like any other view. As VdesmedT says, make sure you're re-using cells via the dequeue mechanism, so that you aren't allocating new cells with each scrolling operation.
OK, I will propose something obvious but to achieve UIScrollView performance, you need to be sure that the dequeue mechanism works well. I often see developers not properly set the identifier in IB and therefore missing the UITableViewCell cache benefit
I've been working with a UIScrollView and have about 200 items to scroll through...so far. This doesn't work since it takes around 45 seconds to load all of the views. I've tried loading the first 20 (about 4 seconds) on the main thread then load in blocks of 50 on other threads. I get the first 20 to scroll through but the others don't appear.
It's taken lots of effort just to get the UIScrollView to work properly and there are still some issues. The UITableView will solve all of this for me since it reuses cells. It's similar to the UIScrollView except more efficient.
I'd like to have one cell take up the entire viewing area and have the user flick through each cell. Rather than freely scrolling through cells, scrolling will stop at each cell and the user must flick again for the next cell. The UITableView doesn't do this that I know of. Is there a way to get this behavior with a UITableView?
UITableView is a subclass of UIScrollView. Have you tried simply setting yourTableView.pagingEnabled = YES?
Short answer: no.
You can try to control UITableView's scrolling behavior using the delegate methods, or better yet, stick with UIScrollView and load the views one-by-one in the UIScrollViewDelegate methods.