Basic animation, Auto Layout, and view geometry – Part 2

[Download the full Xcode project from GitHub.]

In this series of posts, “Basic animation, Auto Layout, and view geometry – Part X,” we’re learning about basic animation in several steps. In yesterday’s post, “Basic animation, Auto Layout, and view geometry – Part 1” we covered setting up a storyboard scene using Auto Layout. Today, we’ll be using some basic UIView geometry to play with shapes and sizes. Tomorrow, we’ll be writing the code to explore iOS animation capabilities. I’ll be writing code in Swift 3.0, then later providing Objective-C versions. I’ll make all the source code available to y’all on GitHub as we move forward.

NOTE: The iOS skill level required herein is “beginner” to “intermediate.” One of the purposes of this blog is to help aspiring new iOS developers get started on the right foot. For all you seasoned (or “advanced”) developers out there, I encourage you to stick with this blog as we’ll be covering very complex iOS scenarios too. Everyone can benefit from these articles, including myself, by getting your feedback.

So what’s this stuff I call “basic UIView geometry?” All user interface components, like UIView’s and UIButton’s, must be positioned on an Apple device’s screen. They’re also objects that occupy space, so they have width and height. In order to position user interface components properly on screen, you use Auto Layout, which boils down to a series of geometric equations called “constraints.” According to Apple, “The layout of your view hierarchy is defined as a series of linear equations. Each constraint represents a single equation. Your goal is to declare a series of equations that has one and only one possible solution.” Let’s make this all more concrete and define two terms you’ll always need to know.

You can read Apple’s long-winded explanation of “bounds” and “frames” in an article entitled “View Geometry,” but let me make it much simpler. Look at the following image (click to enlarge):

Figure 2. Frames versus bounds.

Does that make sense? The bounds of the blue UIView are its origin (x,y) and size (width, height) as they pertain to the UIView itself. Call them relative to the view itself coordinates or independent — in this particular scenario (it’s complicated). The frame of the blue UIView are its origin (x,y) and size (width, height) as they pertain to the UIView’s owner or “superview,” the whole device’s window that contains the UIView. Call them relative to the view’s owner coordinates or dependent — in this particular scenario. According to Apple:

… A view tracks its size and location using two rectangles: a frame rectangle and a bounds rectangle. The frame rectangle defines the view’s location and size in the superview using the superview’s coordinate system. The bounds rectangle defines the interior coordinate system that is used when drawing the contents of the view, including the origin and scaling. …

Enough theory. Let’s write some Swift code to programmatically draw a new red UIView inside the blue UIView. To draw the new red UIView inside the blue UIView, we’ll need to position the new view inside its superview, the blue UIView. So we’ll offset the new red UIView from its parent and give it some breathing space. We’ll also specify the size (width, height) of the new UIView. Before we go on, we need to create an IBOutlet (“mainSubView”) from the blue UIView in the “Animation Demo” project’s storyboard to its “ViewController.swift” file, into the ViewController class.

I’m purposely leaving out any explanations and inline commentary to make you think about what I’m doing. Let’s write a helper method to configure and display the new red UIView. Then we’ll call the helper method from the ViewController class’s viewDidLoad() method.

Here’s the code:

Put this code in your “Animation Demo” project’s “ViewController.swift” file and build/run in the Simulator. There’s your new red UIView (click to enlarge)…

Think about it and we’ll then flesh out the details in the next post in this series — and then we’ll start animating!


[Download the full Xcode project from GitHub.]

Author: Andrew Jaffee

Avid and well-published author, software engineer, designer, and developer, now specializing in iOS mobile app development in Objective-C and Swift, but with a strong background in C#, C++, .NET, JavaScript, HTML, CSS, jQuery, SQL Server, MySQL, Oracle, Agile, Test Driven Development, Git, Continuous Integration, Responsive Web Design, blah, blah, blah ... Did I miss any fad-based catch phrases? My brain avatar was kindly provided by under a Creative Commons Attribution-NoDerivs 3.0 Unported license.

Leave a Reply

Your email address will not be published. Required fields are marked *