I have a scroll view which works fine. Almost. I'm building in Any/Any. The problem is that the scroll view won't scroll past the view controller. I have a switch that is mostly in the view controller window, but the rest is off the box (not really sure how to describe it; it's in the view in the scroll view, but the view is longer than the view controller so part of it is hidden).
The scroll view will scroll down until it hits the part where the view controller would end if you were looking at it in Xcode. There is some more stuff under the switch (labels and another switch). To view these you have to forcefully scroll down. Xcode shows no constraint errors (little red circle with white arrow).
Hopefully this makes sense
A ScrollView needs to know the height and width of the content it is holding in order to know how much to scroll and which direction. Here is a quick read on how ScrollViews work in iOS: https://www.objc.io/issues/3-views/scroll-view/
You can set this programmatically using the contentSize property, but this requires you to know and or calculate the contentSize, which is pretty tedious in most cases.
The correct way of defining the contentSize in iOS is to define AutoLayout constraints in your View. Here is an excellent tutorial on doing just that:
https://www.natashatherobot.com/ios-autolayout-scrollview/
Related
I've just vertical scrolling a few times in the past, but now I'm trying to implement horizontal scrolling but when I run it it doesn't scroll.
What is the problem with it?
P.S. is it possible to design and layout views using a storyboard for scrolling? In this example the blue view is still visible within the screen representation, so its ok to deal with, but suppose I wanted to add another view which is further to the right and thus not visible within the screen representation? Is there anyway of visually designing a scroll view where you can see all the entirity within the storyboard what it will look like?
You don't have a trailing constraint on the scroll view's direct subview, so the scroll view cannot compute the correct contentSize.
Also, it's easier to understand the constraints in the document outline if you give each view a unique label. You have two views labelled “View” so it's difficult to be sure which constraints connect to which “View”.
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.
I am trying to recreate a UIView I have seen in multiple apps, mainly Shazam. The top half of the screen has some interactive buttons, and the bottom half looks like a tableView with custom cells. When the bottom half is panned/swiped up, the tableView scrolls over the top half with velocity, much like a scroll view.
I have been researching this and experimenting for a couple days now. I have gotten close, but not quite there.
My last approach was a view that had a tableView inside it. When the view was panned, the view would move to wherever the finger moved it to, but then would not have any velocity afterwards. Also when the tableView was panned/swiped down, it wouldn't move the whole view down.
Before that I tried a scrollView that took up the whole length of the screen. That gave the desired effect, but the button wasn’t tappable, and you could scroll the view in the button area, which is undesired.
Does it utilize ScrollViews or is it using a tableView that acts much like a ScrollView somehow.
Here is the Shazam UI/UX I am looking to recreate:
The top portion has interactive buttons, and doesn’t scroll. The bottom half shows content and when scrolled, covers up the top portion.
Below is what I have tried so far: This one is the panning view, which sort of works, but doesn’t have velocity and the tableView doesn’t scroll the view back down.
Any thoughts on a direction I can take from here is greatly appreciated. I am using Swift.
Cheers
This sort of thing is perhaps best done with a collection view and a custom layout — you can have some items for which you set layout attributes absolute to the view, and others relative to the scroll content offset.
There's a great (if wandering) discussion of this and other techniques in the Advanced User Interfaces with Collection Views talk from WWDC 2014.
This is actually simple than it seems at first. Here's how you can achieve this:
Create a UIViewController (not a UITableViewController).
Add some buttons to the top area of the screen.
Add a table view spanning the entire view controller's view. Make sure the table view is on top of the buttons added in the previous step.
Configure the top cell of the table view to be transparent (by setting its background color to Clear). Set the background color on the table view to Clear as well. This way it won't obscure the elements at the top of the screen, unless the table is scrolled up.
Because your table view is now transparent, you'll need to explicitly set the background color on the table cells other than the top one.
Profit!
I've created a Page-Based Application and hacked it a bit for some experiments; my simple aim is to have a UIPageViewController whose pages will contain a UIViewController holding a UITableView (after further inspection, the outcome of my experiment is the same if I use a UITableViewController instead).
To do this I've simply edited the project template, and added the UIPageViewController as an embedded view of the RootViewController using Storyboard's ContainerView object, as you can see in this screenshot:
Every controller is configured via storyboard to automatically adjust scroll view's content inset, and if I start the project with this configuration everything looks fine, and the DataViewController's tableview has its content insets properly adjusted right under the navigation bar as expected; however, as the user makes an interaction with the tableview, the content insets break and the tableview underlaps the navigation bar:
I have been able to fix this by manually setting the content insets in DataViewController's viewDidLayoutSubview method, and by disabling Adjusts Scroll View Insets on any controller, so I don't need this as an answer to solve my problem.
My question is why the content insets are properly set right after the first controller gets loaded from the storyboard the first time, and why they break after any kind of user interaction.
If you need to test it directly, here's a link to the project
I'm not 100% sure it's what you're running into, but here's some explanation regarding your setup:
By default, UIViewControllers tend to be configured to extend their content behind non-opaque bars, and to adjust scroll view insets. In your setup above this means that the container VC:
Extends its content so as to appear behind the navigation bar
Sets its scrollview's .contentInset and .scrollIndicatorInsets to be the same height as the navigation bar
"But, ah!" I hear you say, "that container view controller doesn't have a scroll view". Well this is the tricky bit:
It seems UIViewController's definition of "my scroll view" is rather simplistically, "the first scroll view I come to when searching down through my view hierarchy".
UIPageViewController happens to be implemented using a scroll view. So the container VC finds that scroll view, and adjusts its top insets. This is not really what you want; it confuses the page controller, and tends to upset layout at some point.
The simple solution there is simply to turn off .automaticallyAdjustsScrollViewInsets for the container view controller.
You then need to solve the next problem of your table view needing some kind of top insets to account for the navigation bar. So far it seems to me the best way to do this is manually either in the storyboard, or code.
Found an elegant solution:
From your storyboard, select your UIPageViewController
In the Attributes inspector, uncheck the option ViewController => Extend Edges => Under Top Bars
That's all, no weird UI hacks
Have you tried fixing the Auto Layout constraint in the container view of the Root view controller in the Storyboard (that is, the top space constraint should be set related to the Top Layout Guide and not the Superview, with constant = 0)?
You will only lose the effect of the Table View scrolling under the Navigation Bar
I have a .xib containing a view which itself containing top and bottom accessory views (navigation, a page control) and a UIScrollView. Its height varies depending on whether I'm running on an iPhone 4 or 5 (3.5" or 4"). At runtime I move the containing view offscreen, populate the scrollview with UIButtons to build a scrollable launchpad, and scroll this on to the screen from the bottom. Tapping a button shows another view.
On a smaller screen I'd like to show only three buttons in the scrollview, on the larger one I show four. So I need to know the height that the scrollview will be when it appears, before it actually appears. I'd hoped to have this information available at some point in the view lifecycle (viewWillAppear etc.) but the only place this seems to be correct is in viewDidAppear. At this point the view is already on screen and creating the buttons then means they appear suddenly, and are not scrolled nicely onscreen.
The top-level view in the .xib is set to Retina 4 FullScreen.
I'm happy to concede that viewWillAppear is the correct place to create the buttons and my navigation controller is perhaps instantiating the view incorrectly, but my iOS-fu isn't strong enough to say for certain.
My solution has been to detect screen size and hardwire the button height. Is there a better (more elegant, future-proof and canonical) way to do this?
Don't worry, you are in the right direction:
viewWillAppear is the correct method in a view's lifecycle, where the frames of that view and its subviews are completely calculated and nothing has been drawn yet. Here you can make corrections to the standard behavior of your view.
When viewDidAppear gets called, you get the same information about positions and sizes of view elements as in viewWillAppear. But at this time, the animations and the view itself already have been drawn.
That is, why you'll want to use viewWillApear.