Suppose your supervisor or customer gives you a new project to work on: “I want you to start helping out on my iOS project, ‘Blocks-in-Objective-C.’ Please get a copy of the code, make these changes, test, and then check your new code into the repo. By the way, we’re using Git for source control.” Have you used Git before? Do you know it well? (Does anyone truly understand Git?) Today, I’ll show you how to accomplish that task just assigned by your supervisor or customer.
Requirements
Since this is an iOS blog, I’m assuming you’ve installed Xcode and therefore Git is installed on your Mac. (If you need to install Git, click here.)
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.
Let’s talk about source/version control, why it’s so important, and how you can easily put all your iOS code under source/version control management (SCM). I’m going to show you the manual steps involved in putting your code into a Git SCM “repository” (repo) so you fully understand how source/version control works. Jump straight to the tutorial if you’re already familiar with the concept of source control. I can’t explain everything about SCM in one blog post, but I’ll get you started and provide many online resources for you to reference. Why am I using Git? Like it or not, Git has become the de facto standard in SCM systems, mainly because it “is a free and open source [and] distributed version control system.” I don’t buy into the “Git is easy to learn” argument. I find Git to be overly complicated, cryptic, and generally requiring more steps to accomplish source control tasks than say centralized SCM systems like TFS or Subversion/SVN. Git does have some advantages over other SCM products, and it even becomes quite efficacious once you pay your dues learning how to use it properly.
NOTE: This article was first published on Jan 18, 2017. Since that time, I realized I missed one aspect of the project renaming process. Re-read the article or jump straight to the new content.
Sometimes you need to rename your Xcode projects. Not too long ago, this would’ve been problematic. Apple has built a project renaming feature into Xcode, but it’s not good enough for my needs. I’ll show you how I have to go above and beyond the standard functionality to get what I really want. Let’s walk through a concrete example, renaming an Xcode project we’ve been talking about in the post entitled “The UICollectionView is much more than a grid or matrix”.
How many times have you been looking at Swift or Objective-C code in Xcode and can’t remember what a framework method, argument, constant, etc. means? Did you know that help — full documentation — is just a keystroke away? Did you also know that you can add the same type of pop-up, context-sensitive help to your own code? Here’s how. Let’s say you’re looking at the following NSString class method and can’t remember exactly what the call does, what parameters it takes, and what is its return value:
Highlight the method name, parameter, even the enum, and then press the following key combination on your keyboard:
[command] + [control] + [shift] + [?]
or, using key symbols:
⌘ ⌃ ⇧ ?
Here’s what you’ll see: a context-sensitive help/documentation popup. Note that I added the red lines to highlight content. The red highlighting is not what Xcode provides (click to enlarge):
Figure 1: Xcode framework context sensitive help and documentation.
So you immediately get information about the method, parameter, enum, even constant’s:
Declaration (formal language signature);
Description (textual explanation of the entity’s purpose);
Parameters (a full list of names and definitions);
Returns (the value returned by a method/function, if applicable);
Availability (what version of iOS that the entity became available in — and sometimes in what version it was deprecated);
Declared In (the framework which contains the entity); and,
More (generally, the formal definition of the entity with explanations and other links).
Check out what I get if I click on the “More Type Method Reference” link as shown in Figure 1 (click to enlarge):
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’sDebug 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:
NOTE: This article was first published on Jan 18, 2017. Since that time, I realized I missed one aspect of the project renaming process. Re-read the article or jump straight to the new content.
Sometimes you need to rename your Xcode projects. Not too long ago, this would’ve been problematic. Apple has built a project renaming feature into Xcode, but it’s not good enough for my needs. I’ll show you how I have to go above and beyond the standard functionality to get what I really want. Let’s walk through a concrete example, renaming an Xcode project we’ve been talking about in the post entitled “The UICollectionView is much more than a grid or matrix”.
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.
We’re going to learn about basic animation in the next few series of posts, “Basic animation, Auto Layout, and view geometry – Part X.” In order to perform animations, we need to lay the foundation for a simple app. We’ll be 1) setting up a storyboard scene using Auto Layout (this post), 2) using some basic UIView geometry to play with shapes and sizes (Part 2), and 3) writing the code in Swift and Objective-C to explore iOS animation capabilities (Part 3). After Part 3, we’ll start solidifying all the concepts you’ve learned in this series, tie all these concepts together, and come to the realization that these concepts will be indispensable in almost all your iOS development efforts. 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.
Create a new Xcode 8.x project, selecting a Single View Application, naming the project “Animation Demo,” filing out all the required new project fields, selecting “Swift” as the Language, and setting “iPhone” for Devices.
As an iOS developer — or any type of software developer — you’re eventually going to run into linker errors. Sometimes they’re easy to fix (i.e., you’re missing an #include for a header file). Sometimes they’re crazy complex, subtle, and very difficult to solve. Today we’ll talk about some tools (file, otool) and techniques (setting library target hardware architectures) you can use for solving difficult Xcode linker errors.
