How many of you use freeform drawing in Xcode playgrounds? How many of you understand how drawing in playgrounds work? Xcode playgrounds can serve as great tools for prototyping your in-development apps, whether it be experimenting with algorithms or toying with ideas for app user interfaces. Granted that drawing in playgrounds is not that well documented. So the subject of this tutorial is how drawing in Xcode playgrounds works and a good number of pointers to help you start drawing in playgrounds. Here’s an example of what I’m talking about:
You’ve been working on your billion dollar app happily for days or weeks. It’s Monday morning, you open up Xcode 9 to get back to work and — dang, bummer — all your
IBAction connections look like they’ve been disconnected (see image below):
With this article, I’m starting a series about all the goodies — useful tools — that can be found in Xcode. Some of these tidbits are tools everyone knows about while others are barely documented to undocumented. For example, how many of you know that you can view, inspect, and debug all your Auto Layout constraints live during app execution using the “Debug View Hierarchy” Xcode feature? I discussed that feature in detail in this article, “Troubleshooting Auto Layout using Xcode’s Debug View Hierarchy.” Today, we’ll discover two editors that ship with Xcode, the “Open As > Hex” and “Open As > Source Code” editors, both only available by right-clicking on files in the “Project Navigator” to reveal a contextual menu.
- [Download Xcode 8.2.1 project with full Swift 3 source from GitHub.]
- [Download Xcode 8.2.1 playground with full Swift 3 source from GitHub.]
How would you enable or disable multiple user interface controls using one IBOutlet and one IBAction? For example, you might need to disable a UITextBox and UISegmentedControl because a user’s login has expired. Perhaps a user hasn’t filled in some required fields on a form, so you want to disable several buttons. Watch the following video to see how I built a Swift 3 app to use a UISwitch to enable or disable four controls all at one time — and I demonstrated the object-oriented programming (OOP) principle of polymorphism:
Today’s tutorial covers transitions — segues — from one source storyboard scene to another destination scene, and unwind segues leading back from destination to source… I created a project to help you follow along with this tutorial, written in Swift 3, against the iOS 10 SDK, and using the Xcode 8.2.1 IDE. Please download the project. The app produced by the project is shown in action in the following video. Please watch before continuing on:
Segues don’t exist in a vacuum. I’ve introduced a UINavigationController into the mix. Of course, you’ll see a few UIViewControllers. I’ve also used a UITableView and managed its complexity by breaking it into logical pieces by using Swift “extensions.” As you proceed, you’ll have to grasp concepts like Auto Layout and managing a table view’s data source.
I’m going to show you how you can create IBOutlets, find your existing ones, and delete them. There will be times when you need to delete outlets, for example, if you connected the wrong component, have to change your design, misspelled an outlet, etc. You can’t do iOS without doing IBOutlets. An outlet is a connection you must create to allow your user interface (UI) to communicate with your code. For example, if you have a UIView on a storyboard scene, like a UIViewController, you may want to change that view’s background color during app execution. You may also need the bounds or frame of the view. If you have a UIButton, you may want to dynamically enable or disable it depending on some runtime condition. Say you have two UITextFields, “username” and “password,” and a UIButton containing the text “Login.” With IBOutlets, you could write your code so that the login button’s isEnabled property becomes true only when the username and password fields are filled with data. You would also want the text contained in the username and password fields once the user taps “Login.” IBOutlets form a connection between UI components like UILabel, UITextField, and UIView and their backing view controller that manages their behavior and presentation.
What’s more important when troubleshooting software, 1) what you intended in design or 2) what was materialized by running your code in a production environment? Take Auto Layout for example. Interface Builder may be happy with your constraints, displaying no warnings or errors, but when you run your app, you see problems. I find it much more helpful to see my all my Auto Layout live, while my app is running. I’ve found that using Xcode’s Debug View Hierarchy button is an often over-looked but extremely powerful tool for solving app layout problems, especially when iOS developers have to write app user interfaces that run on differently-sized devices in multiple orientations. The Debug View Hierarchy feature helps you understand how Auto Layout works. You can see all of your app’s:
Today, I’m going answer all the questions I posed in this series of posts entitled “Basic animation, Auto Layout, and view geometry – Part X” (see parts 1, 2, 3, and 4). I’ll help you understand how how I created the following iPhone animation using Swift 3.0 — and/or how to get started with your first iOS app:
Today, I’m going to push you to understand how how I created the following iPhone animation using Swift 3.0:
I’ll give you everything you need to figure out what I did — but I won’t explain it for you. Explanation will come later (in the next post, I tie all posts in this series, 1, 2, 3, and 4 together). I want you to learn about my design and code, not just copy and paste it. There is a method to my seeming madness. Hang in there with me through this series of posts.
After providing you with diagrams, source code, references, definitions, inline commentary, etc., I want you to be able to answer some questions about building iOS animations, even if it requires you to do some research, before I put all the pieces together in the final chapter (post) in this series. Remember that I started this blog with the intention of helping new/aspiring iOS app developers get started in an exciting, creative, and potentially financially rewarding profession. I don’t want to just provide code for you to copy and paste into your own app projects, I want you to become the best of the best iOS designers and developers. So let me:
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.