I'm trying to create a UITableView that can scroll both vertically and horizontally. The way I went about implementing this is putting a UITableView (scrolls up and down) inside of a UICollectionViewCell that I set to scroll horizontally (left and right) only. Code-wise, the solution looks pretty darn clean (and elegant in my book because of it), however, I'm experiencing some issues with vertical scrolling on the table view.
Normally, when you vertically scroll on a UITableView, it will keep track and remain where you left off in the scrolling -- as in the table view will not reset or move its scrolling position to a good bit above of where it left off. As you might've guessed, this is what I'm experiencing with my implementation where if I scroll to the very bottom of my table view, its scroll position gets moved to a bit above where I left off and I cannot naturally see the last entry in my table view without having to force a scroll to the bottom in order to reveal it.
Any ideas what might be causing this? I configured all of the settings for the UITableView, UICollectionView and UICollectionViewCell within the Interface Builder -- most important thing being I set the UICollectionView and its UICollectionViewFlowLayout scroll directions to Horizontal. I'm not sure if that's somehow being overwritten somewhere…
This is what you are looking for I believe.
Related
I have the following autolayout-driven setup:
Main viewController, with a scrollview inside it. Scrollview pinned to superview edges. This one scrolls up and down.
A few normal, fixed size views at the top of the scrollview
Another scrollview. This one scrolls left and right. The second scrollview contains a couple of tableviews, side by side. The idea is that the user can switch between them. They both contain a handful of cells, all the same width as the screen and 72pts tall.
The problem I'm trying to solve is that the tableview contents are not the same size. The left one has say, 6 cells, and the right one has 3.
My first approach was to dynamically change the second scrollview height to match which ever tableview was currently visible. What ended up happening was that switching between the two tableviews (by doing setContentOffset:animated:) went extremely wrong if animated was set to true - it would adjust the content offset so everything was offscreen. In fact it would set the content offset to and then as I switched, about a dozen times, then it'd reset. It was weird, I gave up.
Now I'm trying to just adjust the content inset of the main scrollview to offset the gap in the content of the current tableview, and it's also being weird. When I set the bottom content inset in viewDidLoad, it works fine. When I set it at the time the tableview becomes current, it does nothing.
What gives? What scenarios would lead to these view interactions not behaving properly?
Use different tableViewController for each table.
Embed them in pageViewController.
Add those few normal, fixed size views at the top of the pageViewControllers view.
Conform scrollViewDelegate in pageViewController.
Pass scrollViewDidScroll from tableViews to pageViewController.
Set tableViews inset to match those fixed size views at top.
Change height according to the scroll.
This is the way you can achieve the functionality you want.
I hope it helps.
I am intersted in a layout very similar to the App Store app, the "Featured" tab. I think I can achieve this by having a UITableView whose cells are horizontal CollectionViews. So that part is not really my question. The part that I have a question is that the top row of this UITableView scrolls out of the view if you pan (drag) up on the screen but it stick to the top when you pan down. I would like to know how I can achieve that stickiness in one direction.
I've been trying to replicate this effect for a couple days which was inspired by Tumblr.
I've previously asked questions on here with different approaches of the same problem but to no avail. I'm just curious as to how the engineers at Tumblr created a horizontal collection view, with two vertical collection views, and is able to scroll down without affecting the view above (without resetting the position of the view when you scroll vertically in a different tab).
Header Views
I tried this, but the header view was isolated and I had to scroll to the right to see the collectionView cells. This did not work.
Changing the topLayoutConstraint constant of my UIView (not cv header) with respect to the contentOffSet of the vertical collectionView.
This almost got the effect I wanted, except that when I scrolled horizontally, there was a huge gap between my collection view and if I scrolled in that new tab, the UIView would appear again because, again, topLayoutConstraint gets scrolled up depending on the contentOffSet of my vertical collectionView contentOffset.
Changing the position of the UICollectionView frame, and scrolling the super view up simultaneously with NSNotificationCenter.
Alas, this method did the same as method #2, except that the vertical collection view cells scrolled faster than the super view.
I ran out of options to make this work so I will show you in detail what's attempted to be replicated (also note the scroll bar on the right):
Note when I scroll down the first tab. I switch, and then scroll down further. Originally, as I've said, there would be a gap between the second main CV, and when I scrolled, the view would reposition as if were scrolling up again. On here, the view on top keeps going up. So I'm curious as to what method Tumblr engineers used to do this. UICollectionView inside UIScrollView? Other suggestions?
I believe there is no UICollectionView involved. It looks like UIPageViewController and each its page is a UITableView.
Perhaps the UIPageViewController sits in a UITableView as well - the header also moves up when you scroll. This main table has only one cell (and a header) which is occupied by the UIPageViewController.
Hope it helps.
If you look at the Featured tab of the Apple App Store app on an iPhone 6, there is a unique UI layout that I can't figure out how to replicate.
At the very top there is a navigationBar. Below this there is a UIScrollView that animates through a number of featured items. Below this is what appears to be a UITableView with a number of custom programmed cells.
My first guess was that the UIScrollView at the top was added to a custom cell at the top of a UITableView. If you swipe up the UIScrollView moves with the objects below like it is a cell. You can see that the vertical scroll indicator starts at the top of the UIScrollView.
The part that is unique is that if you swipe down, the objects below the UIScrollView move down like a UITableView and the UIScrollView stays in place. This means that the UIScrollView is not a custom cell at the top of a UITableView.
I tried making this work a number of different ways but I can replicate this. Does anyone know how this can be done?
You can use a tableview header,the header is a scrollview
If you scroll tableview up,just use tableview default behavior,the header will scroll up.
If you scroll down,use UIScrollViewDelegate to calculate the tableview header new frame,and adjust it.So it remain at top
Not sure if I got you correctly, you may use UICollectionView as vertical scroll. Then, you create a custom UICollectionViewCell, each with horizontal scroll.
I haven't tried it though but done something similar to this. Hope you find a way!
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.