Group Group Group Group Group Group Group Group Group

raywenderlich.com Forums

Video Tutorial: Swift Scroll View School Part 1: Frame and Bounds

In this video tutorial you'll learn about frame and bounds so you can gain an understanding of how scroll views work.


This is a companion discussion topic for the original entry at https://www.raywenderlich.com/3911-scroll-view-school/lessons/2

In the first part of the video, before 3:15, it is implied that the greenView.frame.origin is changed to (60, 80) and then the greenView.bounds.origin is changed to (60, 80), to reach the results of illustrated on screen. In fact, it should be whiteView.frame.origin and whiteView.bounds.origin changing to produce the illustrated results.

In the challenge solution, I’m confused about why the innerView’s coordinates are never manipulated in the ViewController code. In order to move the green square (innerView), why do we manipulate the containerView’s bounds instead of manipulating the innerView’s frame?

I have a very similar question. If I determine the answer, I will let you know.

@gregheo @vegetarianzombie @bdmoakley Can you please help with this when you get a chance? Thank you - much appreciated! :]

You can use the innerView object to get the same effect that the boundsXSliderChanged() method gets with using the containerView object by replacing containerView.bounds.origin.x = CGFloat(boundsXSlider.value) with innerView.frame.origin.x = CGFloat(boundsXSlider.value). The smaller view will shift its position.

By printing values for containerView.bounds.origin.x, containerView.frame.origin.x, innerView.bounds.origin.x and innerView.frame.origin.x inside the boundsXSliderChanged method, you can see how each view moves relative to the other.

I think it is because, effectively, the origin of the bounds of superview is the co-ordinate space origin for its subview’s frame. So subview’s frame is relatively laid out based on the bound’s origin of superview.