Swift on Andrew Bancroft

SwiftUI Fundamentals

Mon, 08 Apr 2024 00:00:00 +0000

Developing for iOS is a valuable and in-demand skill, but if you haven’t developed in the Apple world before, it can be surprisingly different.

In this course, SwiftUI Fundamentals, you’ll quickly get up and running using Xcode 15, Swift, and SwiftUI to establish the foundational skills you need to build great user interfaces for iOS.

Resources

SwiftUI Fundamentals

Course Outline

First, you’ll see the tools and learn how to use SwiftUI to create single-screen applications with adaptive user interfaces that work on multiple devices.

Next, you’ll learn how to bring your own style to a SwiftUI user interface by customizing its appearance.

Finally, you’ll explore working with data-driven controls and understand navigation options for multi-screen applications.

When you’re finished with this course, you’ll know current best practices, iOS architecture, and the most important ideas you need to feel comfortable bringing your developer skills into the iOS and Apple developer world.

1 - Building Single-view Applications

Topics in this module include…

Version Check: What You Need to Get Started
The Night Watch Scenario
Creating a Single-view App
Understanding the SwiftUI Framework
Creating Xcode Previews
Understanding Views
Combining and Laying out Views
Understanding the SwiftUI Layout System
Aligning and Positioning Views

2 - Customizing UI Appearance

Topics in this module include…

Applying View Modifiers
Developing a SwiftUI Mindset
Using Icons and Symbols
Implementing Custom View Modifiers

3 - Creating Data-driven Lists

Topics in this module include…

Preparing to Work with Lists
Understanding Lists
Creating a List
Controlling a List with Data
Using Loops to Supply Content for Lists
Adding Sections and Headings
Creating Grid Layouts

4 - Building iOS Apps with Multiple Screens

Topics in this module include…

Defining Apps with Multiple Screens
Implementing Navigation Stacks
Adding Navigation to an Existing Project
Extracting Reusable Subviews
Creating a Tabbed Application
Recapping Multi-view Applications

5 - Adding Behavior and Working With Data

Topics in this module include…

Preparing to Add Basic Behavior
Extending the Data Model
Understanding the View Update Cycle in SwiftUI
Adding Basic Behavior
Connecting a Subview to a Parent View’s Data
Using Classes as Data Models
Sharing a Data Model through the SwiftUI Environment
Bringing the Data Model and Behavior to the Night Watch App

6 - Putting It All Together

Topics in this module include…

Applying What You’ve Learned
Integrating the Extended Data Model
Adding the Mark Complete Behavior
Adding a Toolbar and Toggle Control
Implementing Swipe and Move Actions for a List
Resetting the List
Showing an Alert
Adding Images to a SwiftUI Application
Continuing your iOS Developer Journey

iOS 17 Fundamentals

Sun, 10 Dec 2023 00:00:00 +0000

Developing for iOS is a valuable and in-demand skill, but it can be surprisingly different if you haven’t developed for Apple platforms before.

In this course, iOS 17 Fundamentals, you’ll quickly get up and running using Xcode 15, Swift 5, and SwiftUI to build great iOS apps and tap into the latest features of iOS 17.

Resources

iOS 17 Fundamentals

Course Outline

First, you’ll see the tools and learn the core principles for designing iOS apps with adaptive, accessible, and localized user interfaces that work on multiple devices.

Next, you’ll explore how to tackle some of the most common scenarios you’ll run into when you’re building an app for iOS 17, like performing common networking tasks, managing data, adding push notifications to your application, and implementing widgets.

Finally, you’ll learn how to take your app and publish it on the App Store. When you’re finished with this course, you’ll know current best practices, iOS architecture, and the most important ideas you need to feel comfortable bringing your app ideas to iOS 17.

1 - Preparing to Build iOS 17 Applications

Topics in this module include…

Version Check: What You Need to Get Started
How to Learn iOS Development
Introducing “Improvado” - An App for Continuous Improvement
Transitioning an App to iOS 17
Supporting Older Versions of iOS
What Every iOS 17 App Needs

2 - Designing Applications for iOS 17

Topics in this module include…

Introducing Apple’s Human Interface Guidelines
Making an Adaptive User Interface
Adding and Customizing Layout Variations
Supporting Dynamic Type
Implementing Dark Mode
Working with SFSymbols 5
Making Apps Accessible
Localizing an iOS Application

3 - Performing Common Networking Tasks

Topics in this module include…

Understanding URL Sessions
Checking Network Connectivity
Sending HTTP Requests
Requesting Data from REST APIs
Inspecting HTTP Responses
Handling Networking Errors
Organizing Networking Code
Integrating Networking Tasks with SwiftUI

4 - Managing Data

Topics in this module include…

Understanding Data Management Scenarios
Encoding and Decoding Data
Managing Preferences with UserDefaults
Synchronizing Settings with iCloud Key-value Store
Configuring Apps with Property Lists
Performing File Management Tasks

5 - Adding Push Notification Support

Topics in this module include…

Understanding Notification Scenarios
Requesting Permission to Deliver Notifications
Sending Local Notifications
Sidebar: Understanding the Delegation Design Pattern
Responding to Local Notifications
Configuring an Xcode Project for Remote Notifications
Testing Remote Notifications
Making Notifications Actionable
Sending Silent Background Notifications
Setting Up a Remote Notification Server

6 - Implementing Widgets

Topics in this module include…

Adding a Widget to an Xcode Project
Configuring a Widget
Sharing Data between an App and a Widget
Making Widgets Configurable
Creating Interactive Widgets

7 - Publishing to the App Store

Topics in this module include…

Preparing to Publish Your App
Adding an App Icon
Creating an iOS App Launch Screen
Building a Release Version of Your App
Configuring an App in App Store Connect
Submitting an App for Review

Building iOS User Interfaces with SwiftUI

Sun, 22 Aug 2021 00:00:00 +0000

Designing efficient and dynamic apps is essential for taking your iOS developer skills to the next level.

In this course, Building iOS User Interfaces with SwiftUI, you’ll build upon the basic knowledge of iOS development you’ve already gained in order to build compelling iOS apps that engage your users.

Resources

Building iOS User Interfaces with SwiftUI

Course Outline

First, you’ll see the tools and learn how to create iOS apps with adaptive user interfaces that work on multiple devices.

Next, you’ll learn how to manage iOS projects and define the building blocks of your own iOS applications.

Finally, you’ll explore working with data-driven controls and understand navigation options.

1 - Designing Interfaces with SwiftUI

In this introductory module, we begin where the iOS Getting Started course left off and prepare you to handle next-level interface building with SwiftUI.

Topics in this module include…

Preparing to Design User Interfaces with SwiftUI
The Snowhaven Renovation Scenario
Defining SwiftUI Views
Creating Basic Designs and Layouts
Representing Data in User Interfaces
Customizing the Appearance of Views
Changing the Size and Scale of Views
Adding Effects to Views
Layering Views with ZStacks
Implementing Navigation and Displaying a Modal View

2 - Handling User Input

There’s no such thing as an app without data. In this module, I set you up for building dynamic, interactive applications by unpacking questions like:

How do we model real-world objects and concepts as data that SwiftUI can work with?
How do we integrate data into an app, so it’s usable in the right views at the right time?
And how do we load data that’s been saved… display it… and, most importantly, for this module…change it using different editing controls with SwiftUI…

Topics in this module include…

Working with Data in SwiftUI
Establishing an App’s Data Flow
Loading and Displaying Data
Editing Text Data with Text Fields
Persisting (or Cancelling) Data Changes
Working with Picker Views
Switching Between Binary Options with Toggles
Editing Numeric Data with Text Fields
Displaying Editing Controls in a Form

3 - Bringing Apps to Life with Drawing, Animation, and Gestures

SwiftUI provides you with all the tools necessary to make your apps even more dynamic by responding to user gestures like taps and swipes… The framework also gives you everything you need to express your creativity by drawing your own graphics, and adding animations throughout your apps to bring things to life.

Topics in this module include…

Understanding the SwiftUI Drawing System
Drawing with Paths
Using GeometryReader
Applying Transformations to Paths
Building Reusable Shapes
Understanding Animations
Adding Basic Animation
Animating View Hierarchy Changes with Transitions
Combining Multiple Animations and Transitions
Responding to Gestures

4 - Integrating SwiftUI and UIKit

By now, you know that SwiftUI is wonderful, but… it’s not the only Apple UI framework used in today’s Apple Developer world. UIKit is still very widely used and even includes some UI components that are not currently available in the SwiftUI framework.

As we wrap up the course, I explore the answer to this question: How can we, as developers, mix SwiftUI and UIKit to leverage the power of both frameworks?

Topics in this module include…

Preparing to Integrate SwiftUI and UIKit
Representing UIKit ViewControllers in SwiftUI
Making SwiftUI Views Compatible with UIKit
Representing UIKit Views in SwiftUI
Sharing State Between SwiftUI and UIKit
Coordinating User Interaction Between UIViewControllers and SwiftUI
Coordinating User Interaction Between UIViews and SwiftUI
Applying the Finishing Touches

Feedback Welcome!

From the beginning my unwavering goal is to help you filter the noise and learn as efficiently as possible. My hope is that this course benefits you in your iOS development career!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

iOS 14 Getting Started

Fri, 04 Dec 2020 00:00:00 +0000

Developing for iOS is a valuable and in-demand skill, but if you haven’t developed in the Apple world before, it can be surprisingly different.

In this course, iOS 14: Getting Started, you’ll quickly get up and running using Xcode 12, Swift 5, and SwiftUI to build great iOS apps and tap into the latest features in iOS 14.

Resources

iOS 14 Getting Started

Course Outline

First, you’ll see the tools and learn how to create iOS apps with adaptive user interfaces that work on multiple devices.

Next, you’ll learn how to manage iOS projects and define the building blocks of your own iOS applications.

Finally, you’ll explore working with data-driven controls and understand navigation options.

1 – Preparing to Build iOS Applications

Prepare to implement iOS apps by understanding what’s involved from a big picture standpoint.

We begin at the beginning to bring you up to speed and set the foundation for the remainder of the course.

Topics in this module include…

What You Need for Building iOS Apps
Creating an iOS Project with Xcode
Exploring an iOS Project
How to Learn iOS
The Night Watch Scenario
Working with Xcode Projects
Grasping the Basics of the Xcode Development Environment
Summary

2 - Building Single View Applications

Building single view applications is the starting point for most of us who are learning to build iOS apps because they allow us a simplified architecture that focuses on a single screen performing a single responsibility.

Topics in this module include…

Preparing to Build Single View Apps
Understanding the SwiftUI Framework
Understanding Views
Combining and Laying out Views
Understanding the SwiftUI Layout System
Aligning and Positioning Views
Customizing UI Appearance
Developing a SwiftUI Mindset
Using Icons and Symbols
Managing Views with Groups

3 - Creating Data-driven Lists

Just about any day in which you use an iPhone or iPad for more than a few minutes, you’ll almost certainly end up in an app that uses a List View.

It’s the most common way to show a structured, scrollable series of items, and List Views are a core competency for an iOS developer working in SwiftUI, so it’s the first complex control we dive into.

Topics in this module include…

Preparing to Work with Lists
Understanding Lists
Creating a List
Controlling a List with Data
Using ForEach to Supply List Content
Adding Sections and Headings

4 - Building iOS Apps with Multiple Screens

Here I cover how to create apps multiple screens and how to think about and enable navigation between them.

Topics in this module include…

Defining Apps with Multiple Screens
Implementing Navigation Views
Adding Navigation to an Existing Project
Extracting Reusable Subviews
Creating a Tabbed Application
Recapping Multi-view Applications

5 - Adding Behavior and Working With Data

The thing that makes an app come alive is the behavior we add, and the dynamic responses to that behavior that get reflected in the user interface.

In any application, a user interface has one critical job: to accurately represent the data of our application in what it displays on the screen.

In SwiftUI, data and behavior go hand-in-hand, and I cover how to respond to user interaction in this module.

Topics in this module include…

Preparing to Add Basic Behavior
Extending the Data Model
Understanding the View Update Cycle in SwiftUI
Adding Basic Behavior
Connecting a Subview to a Parent View’s Data
Using Classes as Data Models
Sharing a Data Model through the SwiftUI Environment
Bringing the Data Model and Behavior to the Night Watch App

6 - Putting It All Together

There’s nothing like practicing your skills in new contexts to refine them and solidify what you’ve learned.

We go into some additional controls and techniques for building apps with SwiftUI before concluding the course.

Topics in this module include…

Applying What You’ve Learned
Integrating the Extended Data Model
Adding the Mark Complete Behavior
Adding a Toolbar and Toggle Control
Implementing Swipe and Move Actions for a List
Resetting the List
Showing an Alert
Creating an Adaptive UI
Adding and Customizing Layout Variations
Getting Ready for the App Store

7 - Publishing to the App Store

Finishing an app and getting it out the door to your users is one of the best feelings in the world.

Beyond the emotional aspect of publishing an app though, more and more employers want to see job candidates who have published at least one app to the App Store.

So in this final module, I complete the journey by setting you up to get an app into the App Store and bolster your resume!

Topics in this module include…

Preparing to Publish Your App
Adding Images and App Icons
Responding to Dark Mode
Creating an iOS App Launch Screen
Submitting an App for Review
Continuing Your iOS Developer Journey

Feedback Welcome!

From the beginning my unwavering goal is to help you filter the noise and learn as efficiently as possible. My hope is that this course benefits you in your iOS development career!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Implementing In-App Purchases on iOS

Tue, 09 Jun 2020 10:03:33 +0000

Monetizing apps is challenging. In this course, Implementing In-App Purchases on iOS, you’ll learn to offer digital products and services directly within your app as in-app purchases.

Resources

Implementing In-App Purchases on iOS

Course Outline

First, you’ll explore how to translate business requirements into digital products and configure them in App Store Connect and Xcode.

Next, you’ll discover how to build and test a store within your app using StoreKit.

Finally, you’ll learn how to make sure purchases made within your app are authentic, and unlock content that’s been purchased by your users.

When you’re finished with this course, you’ll have the skills and knowledge needed to implement in-app purchases on iOS!

1 – Preparing to Implement In-App Purchases

Prepare to implement in-app purchases by understanding what’s involved from a big picture standpoint.

You will learn to configure digital products in App Store Connect and Xcode to kick off your in-app purchase learning adventure.

Topics in this module include…

The Perks (And the Work) Ahead of You
First Things First - Checking off the Prerequisites
Matching Product Types to Business Requirements
Setting Up Products in App Store Connect
Setting Up an Auto-Renewable Subscription
Configuring an Xcode Project for In-App Purchases

2 – Building In-App Purchase Functionality with StoreKit

The focus of this module is on the StoreKit APIs for working with digital products and App Store Connect.

You will learn to build and test a fully-working store view that will support in-app purchases.

Topics in this module include…

Using StoreKit to Build In-App Purchase Functionality: A Roadmap
Retrieving a Set of Products for Purchase from the App Store
Displaying Products in a User Interface
Implementing a “Buy” Button
Preparing to Test Purchases by Setting up a Sandbox Tester Account
Making Test Purchases
Implementing a “Restore Purchases” Button

3 – Protecting Your Revenue by Verifying Purchase Authenticity

After all your hard work to implement in-app purchases, how awful would it be if malicious users stole the content you’ve labored to create?

In this module, you will learn to implement measures to protect revenue generated through in-app purchases by validating App Store receipts.

Receipt validation is a notoriously burdensome hassle. But it doesn’t have to be!

I will teach you how to implement server-side receipt validation from end-to-end with no third-party libraries, no complicated server setup, and no platform-specific proprietary tools.

Here’s the roadmap of topics incluced:

Verifying Purchase Authenticity by Validating App Store Receipts
Weighing Strategies for Receipt Validation
Charting the Course for Server-side Receipt Validation
Sending the Receipt from Your App to Your Server
Writing Server-side Code to Forward the Receipt to the App Store for Validation
Handling the Response from the App Store on Your Server
Accounting for the Sandbox Environment on Your Server
Handling the Response from Your Server in Your App
The Case of the Missing Receipt: Requesting a Refresh

4 – Unlocking Purchased Content

After a user makes a valid purchase, you’ve got to unlock the content they legitimately bought!

Each product type has its own nuances for how to unlock and provide the associated content though.

What do you need to think about, and what code do you need to write to make it happen?

To find out, you will explore these topics:

Analyzing Content-providing Logic by Product Type
Persisting Purchased Products Securely
Using the iOS Keychain
Keeping Track of Consumable Product Inventory
Managing Non-Renewing Subscriptions
Synchronizing Purchases Across Devices
Handling Auto-Renewable Subscriptions
Saving Non-Consumable Transactions
Preparing for App Store Review

Feedback Welcome!

From the beginning I set out to make the course I wish I had when I started learning to implement in-app purchases for my apps. My unwavering goal is to help you filter the noise and learn as efficiently as possible. My hope is that this course benefits you in your iOS development career!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

iOS Debugging Fundamentals

Thu, 26 Dec 2019 10:03:33 +0000

Bugs are bound to happen. Getting rid of them is an essential skill if you want to keep your sanity when building apps.

In this course, you will learn a set of thinking skills to couple with the fundamental tools that Xcode provides you for finding and fixing flaws in your apps.

🐞1.5 hours 🦟To the point 🐛Engaging storyline 🐜Relevant demos

Resources

iOS Debugging Fundamentals

Course Outline

First, you will learn to approach debugging situations with a set of principles for strategic problem solving.

Next, you will discover how to configure breakpoints and inspect view hierarchies effectively.

Finally, you will explore how to interpret a backtrace, glean valuable information from the Xcode debug area and console, locate changes in your codebase and simulate conditions that happen in the wild.

When you are finished with this course, you will have the skills and knowledge to strategically and methodically reason about probable causes of defects that you experience at runtime.

1 – Debugging as Strategic Problem Solving

Debugging means a lot of things to a lot of people.

In this module, I will define the scope of debugging for you so that you’re clear on the skills you’ll walk away from this course with.

You will begin to develop a problem solving mentality and learn a useful mnemonic for R.E.P.A.I.R.-ing broken apps.

Learn how to categorize bugs into buckets for strategic resolution.

Explore some of the most common sources of bugs to complete this module.

2 – Correcting Unmet Expectations

Probabilistic thinking is the key component of a debugging mindset.

Topics in this module include…

Pausing an App to Gather Clues With Breakpoints
Combining Problem Solving with Xcode Tools
Managing Your Project’s Breakpoints
Controlling Breakpoints by Defining Trigger Conditions
Executing Actions When Breakpoints Are Triggered
Inspecting User Interface Issues

3 – Addressing App Crashes

When an app crashes, it’s because of a critical problem that can’t be recovered from.

In this module you will work on the following:

Understanding Exceptional Issues
Inspecting the Crash Scene with the Backtrace and Console Output
Pausing before Errors and Exceptions Cause Crashes
Avoiding Errors that Cause Crashes

4 – Alleviating Anomalies

Have you ever found yourself saying, “Something weird is going on” or “It used to work - what’s going on now??”

Have you ever experienced one of those “intermittent” bugs that seem to present themselves rarely or inconsistently and are hard to even reproduce?

Anomalous bugs can feel like they occur “out of nowhere”… but do they?

To find out, you will explore these topics:

Reasoning About Anomalous Bugs
Inspecting App Changes
Simulating Real-World Conditions With Xcode

Feedback Welcome!

My unwavering goal is to help you filter the noise and learn as efficiently as possible.

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

iOS Data Persistence: The Big Picture

Tue, 30 Apr 2019 10:03:33 +0000

We’ve all been there. Do a search on the topic of “saving data in iOS” and you’ll get dozens of search results mentioning at least six different frameworks and platforms, and a month’s worth of reading.

Wouldn’t it be nice to distill the possibilities down into just what you need in order to start down a path for persisting data in your app?

“iOS Data Persistence: The Big Picture” will be worth the hour of your time.

Resources

iOS Data Persistence: The Big Picture

Course Outline

During this one hour course, you will learn the reasons for saving data to help ground you as you begin to traverse the data persistence landscape.

You will discover how to use technologies like User Defaults and Property Lists, and I will guide you on how to work with Swift’s Encodable and Decodable protocols.

You will understand what you’re getting into if you choose to work with SQLite, Core Data, or Realm Database for local data persistence.

You will know how it feels to reach for a remote data storage option like CloudKit, Realm Platform, or Firebase.

Finally, you will see a clear picture of what it’s like to design a document-based application and integrate your app’s data with the iOS Files app.

When you’re finished with this course, you will have the skills and knowledge you need to make an informed decision about putting a reliable data storage plan for your iOS app into action.

1 – Establishing the Data Persistence Landscape

During the course, you will have the opportunity to experience a variety of data persistence scenarios and technologies.

You’ll get general feel for setup requirements and a taste of what it’s like to work with each solution in code.

To start you off on the right footing, this module will establish the data persistence possibilities and focus in on the reasons for saving data so that you’re persisting with a purpose.
You will be introduced to a player profile matrix to help you analyze your data persistence options from a number of angles.
Finally, you will get the feel for working with the Swift Encodable and Decodable protocols.

2 – Saving Settings and Configuration

Users are picky, aren’t they? Everybody has preferences though, so it’s no wonder that you as a developer are often tasked with letting your users to customize their experience within your app.

You will learn how to manage user preferences with the UserDefaults system that’s built in to iOS
Next, you will explore synchronizing settings with iCloud Key-Value Store
Finally, you will understand how to ship configuration for your app with Property Lists that are included in your application bundle

4 – Saving Objects and Object Graphs

What if you only wanted to load a subset of the data into memory instead of being locked in to an all-or-nothing situation with UserDefaults or Property Lists?

What if you needed to save a more complex data model that includes relationships?

For that, you’ll need to know about saving and sharing objects and object graphs…

Six Technologies/Frameworks will be featured in this module:

SQLite
Core Data
Realm Database
CloudKit
Realm Platform
Firebase

The goal is to help you answer two questions:

“What am I getting myself into if I pick one persistence technology over another?”
“How does it feel to work with this persistence technology in code?”

You will answer these questions by…

Scanning the arena of persistence options and explore what sets these technologies apart from UserDefaults and Property Lists.
Surveying the setup process to see what it takes to get up and running with each technology in the list
Exploring the data modeling process to wrap your head around what the data structure design process is like for each technology in the list
Getting the feel for working with data so that you understand what it’s like to create objects, update them, delete them, query and filter them, and watch for data changes so that you can update your user interface appropriately

5 – Saving Data as Documents and Files

What if you need to encapsulate chunks of content together and save it all as a packaged up file…as a single unit with a custom file extension?

For that, you need to know about saving data as documents and files.

You will explore the use-case for building a “document-based application”
Next you will walk through designing a document as a subclass of UIDocument
You will learn to create and load documents from a Document Browser
Customizing your app’s file extension is a key step that you will work through
You will spend some time understanding how to interact with document data in code as users interact with the user interface
Finally, you will answer the question, “How do I get my app’s files to show up in the iOS Files app?”

Feedback Welcome!

My goal is to help you filter the noise… to help you distill an overwhelming amount of information down into the big picture possibilities so that you’re on a trajectory for being able to make an informed decision about putting a reliable data storage plan for your iOS app into action.

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

CloudKit Fundamentals

Mon, 24 Sep 2018 17:58:49 +0000

At the core of developing a seamless and collaborative data sharing experience for Apple’s platforms is a thorough knowledge of CloudKit.

In this course, you’ll learn to leverage Apple’s flagship framework to achieve your app’s remote data storage and data sharing requirements.

First, you’ll learn how to configure CloudKit in your Xcode project and how to save, query, update, and delete data that your users store in iCloud.

Next, you’ll explore how to synchronize data across a user’s devices.

Finally, you’ll discover how to handle CloudKit errors, test your app on physical devices, and deploy to production.

When you’re finished with this course, you’ll have a foundational knowledge of CloudKit that will help you provide a fluid, interactive data sharing experience.

Course Trailer

You can check out a trailer of the course over at Pluralsight completely free.

Resources

CloudKit Fundamentals

Course Outline

1 – Setting up CloudKit

Module 1 is the introduction to the course with discussion of the motivating factors for using CloudKit, course prerequisites, storyline overview, and a demo of the end product of the course.

The demo app for this course is a fun one! I put you in the scenario where we team up to build a hazard reporting app for our company’s Safety Department.

The final product will come complete with the ability to save, query, update, and delete text, images, and location information into iCloud using the CloudKit framework.

2 – Modeling and Saving Data

Working with CloudKit begins with an understanding of the framework Types that are used to model and save data.

You'll learn about CKRecords and CKAssets, and save your first bits of data up to iCloud in this module.

3 – Querying, Displaying, Updating, and Deleting Data

Once data has been saved into an iCloud database, the next logical step is to query it and display it within the app.

I will teach about the CKQuery class for querying the CloudKit database for records and/or assets, so that data can be retrieved and displayed in the UI.

And of course, once data is retrieved and displayed, it's fair game for updating and deleting.

4 – Synchronizing Data Across Devices

The whole point of CloudKit is to make sure that data is accessible from more than one device.

One of the primary features still glaringly missing from our Hazard Reporter app at this point in the course is the fact that it doesn’t automatically update when data changes in the CloudKit database.

In this module, I'll teach you about how CloudKit uses subscriptions and push notifications to alert other users’ devices to changes that have occurred in the CloudKit database, so that appropriate action can be taken in code to respond to those changes.

I'll also simulate hazard reports coming in from another user by adding data through the CloudKit Dashboard and watching the screen update with the new data in the iOS app.

5 – Modeling Relationships Between Record Types

Modeling relationships between Record Types is important for many scenarios. In this module I will teach how to work with CKReferences in order to represent hierarchical relationships or to represent ownership between model objects.

6 – Planning for Production

Apple engineers repeatedly warn that CloudKit error handling isn’t the difference between a good app and a bad app… it’s the difference between a functional app and a non-functional app. To that end, I cover some of the most common CloudKit errors and how to handle them.

And alas, once a version of the app is ready enough to put into users’ hands, it’s crucial to test it and then put it into Production. I will discuss creating an Ad-Hoc deployment of the app so that it can be installed on other users’ devices via iTunes. I will also discuss deploying the CloudKit database schema to Production in preparation for deployment to the App Store.

Course Resources

Demos of technology in action are super important to me. That being the case, I tried to pack as much demo content into the course as possible. You'll get to see the full array of dev-time experiences, not just the final "it works perfectly” outcomes.

The course also comes complete with working Xcode projects that gradually build you up to the final version of the app, one step at a time through each module.

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Do Core Data Entities Need Primary Keys?

Fri, 10 Aug 2018 22:31:47 +0000

In this video I pop the hood on Core Data’s SQLite persistent store to discover the details about whether or not you need to add a property representing a “primary key” for your Core Data Entities. Take a look and be sure to subscribe for to stay connected to future screen casts!

Transcript

I had a question asked to me recently to the effect of… “Do I need to create a Primary Key property when I model my Core Data Entities?”

I’m going to tackle answering this one with an Xcode sample project I built a while back and put out on GitHub…

If you go to https://github.com/andrewcbancroft/Zootastic, you’ll be able to clone the repository and follow along with me if you’d like.

This repo is Zoo-themed … don’t judge -haha My kids love animals so I couldn’t help myself…

The Core Data model for this project looks like this. I’m going to focus in on just one of those entities in this video…namely, the Zoo entity.

With that context in mind, let’s think about primary keys… Do you need them when you’re modeling Entities in a Core Data project?

Let’s consider what primary keys are for, first of all. Essentially what you’re after when you specify a Primary Key in a relational database is a guarantee of the uniqueness of a row in a table…

You want to make sure that a given representation…a given instance…one row of an Entity can be uniquely identified, and that’s typically done by adding an ID column with a sequential, unrepeated integer value called a Primary Key.

That way even though two rows may have similar information, such as these two zoos with the same name, you can always represent the City Zoo in Denver Colorado with the unique ID of 1, and the City Zoo in Oklahoma City, OK with the ID of 3.

Suppose our data model has this Zoo entity with two properties: Location and Name…

The question at hand is… Do you add this ZooID property? Or not?

By far the most common use-case with apps using Core Data is to use the NSSQLiteStoreType as the underlying persistent store.

What this means is that Core Data acts as an abstraction layer over the underlying persistent store, which happens to be a SQLite relational database under the hood.

When you create Entities with Attributes in your core data model, those turn into Tables with Columns in the SQLite database.

What I want to do right now is show you what happens when your data model is initialized in an app using Core Data with a SQLite persistent store, and what you’re going to discover is that Core Data’s got your back when it comes to Primary Keys.

Watch this…

I’m going to edit the scheme of the Zootastic app to show you how to get a little bit of extra debug information related to the SQL queries that are being run under the hood as Core Data interacts with your persistent store.

Under Run, you can add an argument that’s passed when the app is launched to get this extra debug information. Use the -com.apple.CoreData.SQLDebug switch and pass 1 as the argument.

Running the app loads a ton of text into the debug console’s output, but what I’m interested in showing you is right up here at the top.

Do you see this right here? Core Data sends a CREATE TABLE statement to the SQLite database engine, and within the columns it creates is this Z_PK integer column as a… Primary Key.

But I haven’t listed a PK property in my Entity!

Seeing the fact that even though I don’t put in a special primary key property, Core Data still creates that column in the SQLite database, I think you can answer the question on your own.

My answer would be, “No… you don’t need to specify a special ID property to serve as your entity’s Primary Key because Core Data knows this internally and creates one automatically.”

Now just in case you’re skeptical and don’t believe that the column is actually IN the database, I want to show you explicitly.

At the top of this debug output, do you see this? it’s a path to the sqlite database file that the app is using. I’m going to copy it and jump over to a terminal session.

cd to that directory and list its contents.

Zootastic.sqlite is what I want to peek into, so I’ll run sqlite3 with that file specified.

If you run .table, sqlite will list out all the tables in this database file.

Running .schema on ZZOO shows you that yes indeed the primary key column is present in the database table that holds the Zoos for the app.

Selecting all columns from the ZZOO table shows that it’s populated with integer values as you’d expect.

Bottom line? You don’t need to explicitly create an ID column to serve as a primary key. Core Data takes care of that for you.

If you’re learning Core Data, you might enjoy my Core Data Fundamentals with Swift course on Pluralsight. I cover the essentials to get you up and running with Core Data in your apps developed for Apple’s platforms.

Thank you for watching!

The Case for CloudKit

Mon, 06 Aug 2018 11:58:32 +0000

When it comes to remote backend services for mobile apps, you’ve got options. What’s the case for CloudKit? Where does Apple’s remote data storage and sharing solution fit into the Apple Developer’s toolbox?

I recently put out a survey on Twitter, just to get a feel for what folks are using.

#iosdev folks: When your app needs a backend (ie, a remote server / remote database), what do you use?

I’m also interested in the “why” - reply with a tweet if you care to share! Thanks! 🙌🏻
— Andrew Bancroft (@andrewcbancroft) July 20, 2018

The clear winer was Firebase, followed by folks implementing their own backend server architecture. Dead last? A tie between Realm and CloudKit.

”Hmm…”, I thought, “What’s up? Why no love for CloudKit?"

Of the options on my own survey, I’ve had experience building apps using three of the four: CloudKit, Firebase, and “rolling my own backend” with an app built for my employer.

So I asked myself, “When would you use CloudKit, Andrew?”

Here’s how I tend break it down. The more of these that apply to you and your app development experience, the stronger the case for using CloudKit (in my opinion):

Apple Platforms Only? CloudKit.

If you’re developing solely for Apple’s platforms, CloudKit is the natural choice.

One of the other CloudKit alternatives mentioned in the survey might have the upper hand if you’re developing for Android as well, but if you’re sticking to the Apple ecosystem, it makes sense to use their remote data storage and sharing service (ie, CloudKit).

Expand Beyond Apple Platforms with CloudKit JS

Even if you’re not developing solely for Apple’s platforms, CloudKit might still be a viable choice for you!

Apple designed CloudKit JS to create companion web apps to your iOS and macOS apps. You must have an existing CloudKit app and enable web services to use CloudKit JS, but once you’ve got an Apple app configured, you can leverage CloudKit in the web version of your app if you have one.

As I engaged with folks on Twitter about this, I learned that some were even leveraging CloudKit in an Android app using CloudKit JS as a bridge into the Apple ecosystem.

This opens up the audience for your app tremendously!

Built-in Authentication: CloudKit.

If you’re tired of creating sign up and login screens, look no further than CloudKit.

This is especially true if you’re only worrying with developing for Apple’s Platforms.

Users signed in with an Apple ID are automatically authenticated when your app uses CloudKit.

Kiss the sign up/login screens goodbye!

CloudKit is Free for Longer

All of the backend as a service providers offer a free tier or a free trial, and while I don’t have personal experience with these services’ payment threshholds, it’s my observation that CloudKit’s free tier might “last longer”. What do I mean by that?

Data of any kind stored in a user’s private database doesn’t count against your app’s storage alotment… it counts against the user’s iCloud storage plan. This extends the mileage of your app’s storage alotment.
CloudKit distinguishes between storage for non-binary data and storage for media (binary data like images, videos, audio, etc). You start off with 100 MB of non-binary data storage, but 10 GB of image/video/audio/etc. storage. In contrast… * Firebase starts to charge you $25/mo after 5 GB of media storage * Realm Platform offers a 30 day free trial, but is $30/month after that, and acts primarily as a remote data store for non-binary data.
As the number of users for your app grows, your storage and transfer limits scale with your app’s user base. I don’t have personal experience here, but I wonder… by the time your app grows to 100,000 users (the tipping point for Apple to scale your app’s alotments up), how probable is it that you’d already be paying to use Firebase?

Rolling Your Own Backend? Consider CloudKit.

Folks already invested in Realm or Firebase are already leveraging a backend as a service platform. It’s those that are maintaining backend server infrastructure themselves that I might suggest consider CloudKit.

I’ve been in the shoes of those who have to roll their own backend server and maintain those VMs, databases, web servers… the works.

Many times this is because there’s a need to connect a mobile app to an organization’s on-premise/public cloud ecosystem, and for that, I can totally empathize.

CloudKit offers a reliable alternative that organizations developing for Apple’s platforms should consider. It’s a huge weight off the shoulders to abstract the backend and let Apple maintain those servers and storage components. Data stored in the public cloud database is accessible programmatically, so your organization can get at data stored there for incorporation into its internal ecosystem.

Company Requirement: 1st Party Frameworks and Services Only? CloudKit.

This requirement is most likely to be seen within companies and organizations that have an aversion to bringing in a lot of 3rd party dependencies.

Those of us who have an employer or who work for clients that have a say in what our app development toolkit can consist of may need to consider options within the Apple ecosystem.

CloudKit is a dependable choice for risk-averse companies.

Speaking of risk aversion…

Personal 3rd Party Risk Aversion… CloudKit.

This one hits close to home for me, because I’ve experienced the pain of having a 3rd party service I depended on for multiple apps be discontinued. *Cough* Parse *Cough*

I’m usually okay with 3rd party libraries, but 3rd party services are another story altogether for me.

When you’re using a library that ends up fading away, it may take a little reworking to get your code to compile with an alternative.

But when you’ve got data that your app depends on living on a remote server hosted by a 3rd party, and that service goes away… Oy! Talk about the pain, frustration, and hassle of having to do a migration on top of rewriting code.

Only Need a Remote Data Store? Keep it Simple. CloudKit.

There is a ton that can be done on-device these days. If all you’re in the market for is a remote data store to facilitate data sharing across devices or with other users and have no need of remote cloud functions or analytics or remote machine learning services, etc., you might opt to keep it simple and leverage CloudKit.

Depend On What Apple Depends On: CloudKit.

What does Apple depend on for their own apps’ remote data storage and sharing needs?

Answer: CloudKit.

Clearly, Apple is in a unique situation: Apple neither needs nor cares to develop any of its apps for Android. Naturally, they’d depend on the very framework they created. Otherwise, we could argue, “What a bunch of hypocrites!”, right?

CloudKit serves the needs of apps like Photos, iCloud Drive, Notes, News, and more.

It’s almost as if Apple developed CloudKit for Apple, and decided, “Hey, let’s open this up to our developers and let them tap in to what works awesome for us!”

I like that. I like the security of knowing that Apple depends on the framework they’re delivering to us.

Tradeoffs

In fairness, I would point out a few trade-offs if you were to go with CloudKit.

No Native Android support

This tradeoff is qualified with the words “no native Android support” for a reason. CloudKit JS may actually open the door for folks developing cross platform apps, though it may take some hacking.

Expect some challenges on the Android side of things, but don’t completely count CloudKit out.

With CloudKit, you get a fully-functional remote data storage and sharing service. If you’re wanting to leverage some advanced functionality like “cloud functions”, analytics for your app, non-Apple ID authentication, remote machine learning services, and the like, you won’t find those features in CloudKit.

This doesn’t mean that Apple leaves you nanging when it comes to authentication, analytics, machine learning, etc.

Don’t forget that you’ll have built-in Apple ID authentication as I mentioned above, and analytics are provided through iTunes Connect.

On-device machine learning with CoreML might also alleviate the need to seek remote ML services.

If, after considering Apple’s component solutions, you’re looking for alternatives, Firebase offers all of the above as sort of an all-in-one package.

As I mentioned above though… if all you really need is a remote data store for cross-device data syncing, don’t over-complicate things. CloudKit can still serve you well.

Another alternative is to use a public cloud provider like Azure or AWS for “cloud functions” or remote machine learning. If you prefer to component-ize these kinds of services, this is a viable alternative to Firebase, or Apple’s own solutions to these kinds of problems.

What do you use? Why?

I’m a pragmatist. I don’t always use CloudKit. But I do like CloudKit when I can use it.

What do you use? Why? What’s your experience with backend as a service providers? What else would you consider in the case for CloudKit? What other tradeoffs do you recognize?

Swift Cheat Sheet for iPhone Location Services Access and Usage

Tue, 17 Jul 2018 00:43:03 +0000

This is a cheat sheet of the code and workflow for iPhone location access and usage, from requesting permission to using the location of the user’s device.

Framework Import

import CoreLocation

Set Location Usage Description in Info.plist

This is a required first step

If you don’t set this, your app simply won’t present the user with the system alert to request access to the location (and, of course, you won’t be getting any location data for your app either).

When you request permission to use the device’s location, a short message will appear in the default iOS system dialog. You customize this message by adding one of the following keys to your Info.plist file:

Privacy – Location Always and When In Use Usage Description
Privacy – Location Always Usage Description
Privacy – Location When In Use Usage Description

For the value of this plist property, type a short string describing what you’re using the location for.

Initialize CLLocationManager and Implement CLLocationManagerDelegate

CLLocationManager is the name of the class that gives you a way to request location services permission. It is also responsible for starting the location tracking process.

It needs a corresponding CLLocationManagerDelegate to be assigned. The location manager instance you initialize will alert you to location services authorization changes (ie, if the user turns off location services permissions for your app) through the one of the methods that your delegate class implements.

The location manager instance will also send you the user’s current location through one of the methods your delegate class implements.

Here is an example of initializing the CLLocationManager instance, and setting its delegate.

There’s also a currentLocation variable that will get continually updated…

 1class NameOfViewController: UIViewController, CLLocationManagerDelegate {
 2    private let locationManager = CLLocationManager()
 3
 4    // This will get updated via the location manager delegate's didUpdateLocations method
 5    var currentLocation: CLLocation? = nil 
 6
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9        
10        // Do any additional setup after loading the view.
11
12        locationManager.delegate = self
13
14        self.startLocationServices() // This function is implemented below...
15    }
16}

Here is an example of how to implement the two CLLocationManagerDelegate methods:

 1// Monitor location services authorization changes
 2func locationManager(_ manager: CLLocationManager,
 3                        didChangeAuthorization status: CLAuthorizationStatus) {
 4    switch status {
 5    case .notDetermined: 
 6        break
 7    case .authorizedWhenInUse, .authorizedAlways:
 8        if CLLocationManager.locationServicesEnabled() {
 9            self.locationManager.startUpdatingLocation()
10        }
11    case .restricted, .denied: 
12        self.alertLocationAccessNeeded()
13    }
14
15// Get the device's current location and assign the latest CLLocation value to your tracking variable
16func locationManager(_ manager: CLLocationManager,
17                        didUpdateLocations locations: [CLLocation]) {
18    self.currentLocation = locations.last
19    }
20}

Start Location Services, Check Location Authorization Status, Request Permission

When you first start location services in your app, you will want to immediately check your app’s current authorization status for location services, just in case the user has gone in and disabled location services permission for your app since the last time he/she used it.

If it’s the first time the user has launched your app, the .notDetermined case will get hit. This is where you request permission for the first time.

If the user grants permission, you can use the CLLocationManager instance that your class is using to start updating the user’s location.

If, however, the user denies permission, you can alert them to the fact that your app needs access to his/her location for [insert some good reason here].

Here’s a code snippet showing this in action:

 1func startLocationServices() {
 2    locationManager.desiredAccuracy = kCLLocationAccuracyBest
 3    
 4    let locationAuthorizationStatus = CLLocationManager.authorizationStatus()
 5    
 6    switch locationAuthorizationStatus {
 7    case .notDetermined: 
 8        self.locationManager.requestWhenInUseAuthorization() // This is where you request permission to use location services
 9    case .authorizedWhenInUse, .authorizedAlways:
10        if CLLocationManager.locationServicesEnabled() {
11            self.locationManager.startUpdatingLocation()
12        }
13    case .restricted, .denied: 
14        self.alertLocationAccessNeeded()
15    }
16}

Note: You can test for the .notDetermined case by deleting the app on the device, if it’s already been installed or run on a device from the debugger.

Alert Location Services Access Needed

If location services access has been denied or restricted, you can alert the user and direct them to the Settings app to make the appropriate permissions adjustment:

 1func alertLocationAccessNeeded() {
 2    let settingsAppURL = URL(string: UIApplicationOpenSettingsURLString)!
 3    
 4    let alert = UIAlertController(
 5        title: "Need Location Access",
 6        message: "Location access is required for including the location of the hazard.",
 7        preferredStyle: UIAlertControllerStyle.alert
 8    )
 9    
10    alert.addAction(UIAlertAction(title: "Cancel", style: .default, handler: nil))
11    alert.addAction(UIAlertAction(title: "Allow Location Access",
12                                    style: .cancel,
13                                    handler: { (alert) -> Void in
14                                    UIApplication.shared.open(settingsAppURL,
15                                                                options: [:],
16                                                                completionHandler: nil)
17    }))
18    
19    present(alert, animated: true, completion: nil)
20}

Note: You can test for this case (.restricted and .denied) by going to the Settings app and turning off location services access for your app, if it’s been previously granted.

Swift Cheat Sheet for iPhone Camera Access and Usage

Sat, 24 Feb 2018 12:23:02 +0000

This is a cheat sheet of the code and workflow for iPhone camera access and usage, from requesting permission to using the photo taken with a user’s device.

Framework Import

import AVFoundation

Set Camera Usage Description in Info.plist

When you request permission to use the device’s camera, a short message will appear in the default iOS system dialog. You customize this message by adding the Privacy - Camera Usage Description key to your Info.plist file.

For the value of this plist property, type a short string describing what you’re using the camera for.

If you don’t set this, your app will crash when you request access to the camera.

Check and Respond to Camera Authorization Status

1let cameraAuthorizationStatus = AVCaptureDevice.authorizationStatus(for: .video)
2
3switch cameraAuthorizationStatus {
4case .notDetermined: requestCameraPermission()
5case .authorized: presentCamera()
6case .restricted, .denied: alertCameraAccessNeeded()
7}

Request Camera Permission

If the user has never responded to a request to access his/her camera, you need to prompt with the iOS system alert to request permission:

1func requestCameraPermission() {
2    AVCaptureDevice.requestAccess(for: .video, completionHandler: {accessGranted in
3        guard accessGranted == true else { return }
4        self.presentCamera()
5    })
6}

Note: You can test for this case by deleting the app on the device, if it’s already been installed or run on a device from the debugger.

Present Camera

1func presentCamera() {
2    let photoPicker = UIImagePickerController()
3    photoPicker.sourceType = .camera
4    photoPicker.delegate = self as? UIImagePickerControllerDelegate & UINavigationControllerDelegate
5    
6    self.present(photoPicker, animated: true, completion: nil)
7}

Alert Camera Access Needed

If camera access has been denied or restricted, you can alert the user and direct them to the Settings app to make the appropriate permissions adjustment:

 1func alertCameraAccessNeeded() {
 2    let settingsAppURL = URL(string: UIApplicationOpenSettingsURLString)!
 3    
 4    let alert = UIAlertController(
 5        title: "Need Camera Access",
 6        message: "Camera access is required to make full use of this app.",
 7        preferredStyle: UIAlertControllerStyle.alert
 8    )
 9
10    alert.addAction(UIAlertAction(title: "Cancel", style: .default, handler: nil))
11    alert.addAction(UIAlertAction(title: "Allow Camera", style: .cancel, handler: { (alert) -> Void in
12        UIApplication.shared.open(settingsAppURL, options: [:], completionHandler: nil)
13    }))
14
15    present(alert, animated: true, completion: nil)
16}

Note: You can test for this case by going to the Settings app and turning off camera access for your app, if it’s been previously granted.

Use the Captured Image

To use the image that the camera captured, you need to set up your view controller to adhere to and implement couple of delegate protocols:

1class NameOfViewController: UIViewController, UINavigationControllerDelegate, UIImagePickerControllerDelegate {
2// ...
3}

UIImagePickerControllerDelegate

1func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String : Any]) {
2    let photo = info[UIImagePickerControllerOriginalImage] as! UIImage
3    // do something with the photo... set to UIImageView, save it, etc.
4
5    dismiss(animated: true, completion: nil)
6}

Swift 4 Upgrade Error: ‘init(colorLiteralRed:green:blue:alpha:)’ is unavailable

Wed, 24 Jan 2018 12:35:04 +0000

I upgraded a project to Swift 4 today and hit a compiler error:

‘init(colorLiteralRed:green:blue:alpha:)’ is unavailable: This initializer is only meant to be used by color literals.

The fix is pretty simple: Don’t use that initializer! (thank you, Captain Obvious!)

The correct initializer to use for specifying a red, green, blue, and alpha to get a UIColor instance in Swift 4 is:

UIColor(red:green:blue:alpha:)

So essentially, just replace colorLiteralRed:, and replace it with just red:, and the compiler error will go away. Here’s an example of how to call it:

let color = UIColor(red: 204/255, green: 204/255, blue: 204/255, alpha: 1.0)

Using an Existing SQLite Store with NSPersistentContainer

Mon, 10 Jul 2017 18:02:05 +0000

If you’ve been creating the Core Data Stack without NSPersistentContainer and you’re thinking about switching things up to use NSPersistentContainer, you need to think about your existing SQLite persistent store.

Creating the stack with NSPersistentContainer handles the creation of SQLite stores internally, so brand new setups using NSPersistentContainer are pretty easy.

But how do you go about telling NSPersistentContainer about your existing SQLite store?

Let’s take a look now at how you can configure the container to use your previously-created persistent store.

Before NSPersistentContainer

Supposing that your previous Core Data stack creation step pointed to a .sqlite file somewhere in your user’s documents directory:

1// Configure NSPersistentStoreCoordinator with an NSPersistentStore
2let psc = NSPersistentStoreCoordinator(managedObjectModel: model) // model instance creation not shown here...
3
4let storeURL = try! FileManager
5        .default
6        .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
7        .appendingPathComponent("NameOfDataModel.sqlite")
8
9try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: nil)

After NSPersistentContainer

The key to migrating to NSPersistentStore with an existing SQLite persistent store is the NSPersistentStoreDescription class. Take a look at the following code to see how to configure an instance of NSPersistentStoreDescription and assign it to the NSPersistentContainer instance’s persistentStoreDescriptions property:

 1let container = NSPersistentContainer(name: "NameOfDataModel")
 2
 3let storeURL = try! FileManager
 4        .default
 5        .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
 6        .appendingPathComponent("NameOfDataModel.sqlite")
 7
 8let storeDescription = NSPersistentStoreDescription(url: storeURL)
 9container.persistentStoreDescriptions = [storeDescription]
10
11// Remaining setup for NSPersistentContainer

Breaking it down

The let storeURL = portion of the code is identical in both snippets.

The difference is how you tell the Stack where the persistent store is located. In times past, you’d tell the NSPersistentStoreCoordinator this information through its addPersistentStore method.

With NSPersistentContainer, you need to do two things:
1 – Initialize an NSPersistentStoreDescription instance with the storeURL (i.e. the URL to where your existing persistent store is located).

2 – Assign the NSPersistentStoreDescription instance to the NSPersistentContainer's persistentStoreDescriptions property.

One subtlety to note is that the property’s name is plural: persistentStoreDescriptions.

Even though may only a single persistent store description instance to assign, such as in the example code above, you still need to wrap it in an array before you assign it, since it’s possible to add more than one description to the container.

With that adjustment to the NSPersistentContainer stack creation process, your app will once again use the persistent store it used to use!

You might also enjoy…

Creating the Core Data Stack with Backwards Compatibility in Swift

Core Data Cheat Sheet for Swift iOS Developers

Resources

Core Data Fundamentals with Swift

Why is it called a “Closure” anyway? A Swift Conceptual Look.

Tue, 06 Jun 2017 04:00:41 +0000

What’s in a name?

If a programming language comes with a named feature, you can be pretty sure it was named that way for a reason. It’s a safe bet that the language designers were purposeful in their naming, so if you can figure out that essential “Why’d they name it that?” question, you might be that much closer to understanding the feature or concept.

Why “closure”?

Now the challenge: Actually figuring out the answer to that “Why?” question.

Swift is being developed in the open, and often times that gives curious minds insight into things like naming decisions. But closures in Swift have been around for longer than Swift has been open sourced.

That being the case, I really couldn’t find much in terms of the conversation around why closures are named “closures”.

Closures exist in other languages, so maybe Swift just borrowed the name. But that doesn’t help us answer the bottom line reason for naming closures “closures”.

Unpacking “closure” (thanks, thesaurus.com!)

So… I set out on a word adventure to help shed some light on what meaning is to be conveyed by the term “closure”.

It’s one thing to know that “closures are self-contained blocks of functionality that can be passed around and used in your code.” (Apple Developer Docs), but seriously — why not just call them “functions”??

Let’s unpack the word if we can. I put “closure” into thesaurus.com, and among the synonyms that I think best clarify the term “closure” in programming languages are these:

Plug
Seal
Cork

In this sense, “closure” seems to convey the idea of keeping something in… enclosing it.

Okay, so what is a closure enclosing? Great question!

Short answer? Variables.

Inevitably, if you peruse the Internet for what closures are, you’ll come across similar definitions to Apple’s, quoted above. Often, intermingled in the various definitions I’ve found, are phrases like “capturing variables” or “closing over variables”.

These phrases always seemed to muddy the water (for me, anyways). It wasn’t entirely clear what “capturing variables” or “closing over variables” meant. Until I saw the synonyms, “plug”, “seal”, “cork”.

Then it clicked…

An example for your imagination

I want you to take a function in Swift, and I want you to imagine the function as an empty swimming pool. Got it in your mind’s eye? Swimming pool. Empty (for now).

It’s runtime, and your Swift program is happily executing along. Then there’s a moment in your program where your function gets called. It begins executing, and suddenly, water comes rushing in filling the pool. A dozen diving coins get tossed into the water as well!

The coins represent the local variables and constants that your function creates to do its work.

Your function executes all the way to the return keyword, and at the precise moment that your function returns, the drain kicks in. Within milliseconds and with tremendous force, all the water is sucked out of the pool.

What do you think will happen to all the coins in the pool?

For this example, let’s just say the answer is, “they’ll go down the drain”. That would correlate pretty well with what normally happens to variables and constants that had been declared within your function when it returns.

Any variables and constants that are created inside a function are purged from memory whenever the function returns… down the drain, if you will.

Unleeeees…

What if, at some point while there’s still water in the pool, you were able to dive in, grab a few of the coins, and bottle them up?

What if you could stick them in a container and plug it with a cork or some other kind of seal?

If you could do that, the coins would survive the torrential drainage of the pool when the plug is pulled (i.e. the function returns). And that’s what I want you to take away from the example.

A closure acts as a mechanism for diving into the pool, scooping up the coins (i.e. variables and constants) it needs, and sealing itself, such that whenever its parent function (the pool) drains, it and the coins inside survive.

Closures in practice

When you hear that closures are “self-contained blocks of functionality that can be passed around and used in your code.”, you may not realize that they can go grab variables from their environment, package them up, and seal themselves tight, thus safeguarding those variables.

As it turns out, every closure you create has this capability built in.

Not all closures need to go out and capture variables, but all closures in Swift can do so if it’s relevant.

And that is what makes closures “closures”.

You might also enjoy…

<p>
  <a name="share" class="jump-target"></a>
</p>

A Swift Implementation of the Core Data Stack Using NSPersistentContainer

Mon, 15 May 2017 18:19:46 +0000

If you’re targeting iOS 10 and above, you’ve got the opportunity to pick your poison when it comes to creating the Core Data stack.

You could opt for the process I described in Creating the Core Data Stack with Backwards Compatibility in Swift — that process still works perfectly fine in iOS 10+.

Alternatively, you could use the new NSPersistentContainer class if you want to write a few less lines of code and keep up-to-date with the latest framework enhancements!

What’s the point of the “Core Data stack”?

It’s important to keep in mind the fundamental goal with creating the “Core Data stack”. At the end of the day, we’re all just trying to get our hands on an instance of NSManagedObjectContext.

Nearly every Core Data framework Type that we interact with requires an instance of NSManagedObjectContext to do its work. Whether it’s NSEntityDescription to initialize new NSManagedObject instances, an NSFetchRequest to retrieve data, or an NSFetchedResultsController to keep our UIs in sync, we’re always depending on NSManagedObjectContext.

So the bottom-line goal of setting up the “stack” is to configure all the plumbing necessary for our apps to work with the “under the hood” stuff of Core Data. The thing we interact with constantly is that all-valuable NSManagedObjectContext instance.

Creating the stack with NSPersistentContainer

NSPersistentContainer saves a few keystrokes and abstracts away a few of the moving parts when it comes to setting up the Core Data stack. Compare my Backwards Compatibility post if you’re curious about what’s being simplified.

So… how’s it done?

First: Make sure you’re targeting iOS 10+, macOS Sierra (10.12)+, watchOS 3+, or tvOS 10+

NSPersistentContainer is only available in Apple’s latest platform versions (latest as of May, 2017).

Once you’ve ticked the build target prerequisite above, check out this code example:

//Step 1
let container = NSPersistentContainer(name: "NameOfModel")

// Step 2
// Happens asynchronously!
container.loadPersistentStores(completionHandler: {
    persistentStoreDescription, error in
    // Step 3
    guard error == nil else { fatalError("Failed to load store: \(error)") }

    let mainContext = container.viewContext
    // Use the context to do Core Data stuff in your app
})

Step-by-step through the code

Using NSPersistentContainer can be seen as a 3 step process.

1 – Initialize an NSPersistentContainer instance. Its only parameter is the name of the model (look at your .xcdatamodeld file for this)
2 – Call loadPersistentStores on the container instance. This function executes asynchronously, so to hook back in and continue doing things when the function is finished with its work, you supply a completionHandler.
3 – Guard against errors and use the container’s viewContext property, which is the NSManagedObjectContext instance you need. I haven’t written in detail about this (yet), but in my Pluralsight course on Core Data in Swift, I go over how to take the managed object context and follow a dependency injection pattern so that you isolate where it’s created, and use the single instance throughout your app in a way that’s testable.

One consideration that I would encourage you to think about is the guard statement. Ask: “Is fatalError really the best thing for me to do?”

A lot of apps that use Core Data really can’t continue past this point if the persistent store can’t be loaded. In that case, the guard may not be so bad. If you can fall back to an alternate screen that doesn’t rely on Core Data though, that might be a more pleasant experience for your users than simply crashing with a fatal error.

Wrap up

This is the simplest way to use NSPersistentContainer to create your Core Data stack, and that’s where I want to leave it for today!

Thank you, as always, for your interest in the content I’m creating!

And yes, if you’re learning Core Data, I would love to contribute to your understanding of the framework. That’s why I built Core Data Fundamentals with Swift for Pluralsight! If you’re a subscriber, I’d be thrilled to engage with you on the course!

Why Do We Need to Annotate Escaping Closures in Swift?

Thu, 11 May 2017 17:58:46 +0000

My last entry on escaping closures ended up having way more interaction than I anticipated! It goes to show that you never know what the impact of a piece of writing will have. But that’s a different story… :]

Several readers commented here and on Medium with the question, “Why? Why do we need to mark escaping closures with @escaping?”

Do it yourself, compiler!

Observant minds looked at the compiler’s ability to say, “Hey! This closure can escape – Annotate it with @escaping!” and asked, “Well… why?? If you, compiler, are smart enough to figure out that I need to annotate it, why can’t you just deal with it automatically and let me go about my business?”

Good. Question.

And one that I didn’t know the answer to. So I researched!

Insight from the Swift gurus

As I dug around in the Swift GitHub repository and the Swift Evolution list I found a quote from Chris Lattner that stuck out:

The compiler has enough logic in it to provide a great QoI (Quality of Implementation) experience when a developer doesn’t think about escaping, and tries to escape a closure – it can provide a fixit that suggests adding @escaping.”

Did you catch that?

When the Swift compiler requires us to annotate our APIs with @escaping, that’s its way of doing “quality of implementation”.

Essentially, it’s a red flag saying, “You really ought to think about this whole escaping thing that you just introduced (whether you knew you were doing it or not)… it has significant impact on your implementation and on the caller of your function!”

I see what you did there… Let me help you out…

The Swift compiler, for better or worse, wants to be very… “helpful”…

Some people hate it. I love it.

I want to be told, “Hey, Andrew… you’re about to break stuff – don’t do that.”

I’d rather head off issues during development than at run-time.

How helpful is it, really?

But really… How helpful is this particular compiler error? What value does this fix-it option provide?

Try this: Think about what would happen if the compiler didn’t tell you about the possibility of your function’s closure escaping.

I was working the other day, cruising along writing what I thought was perfectly normal code when I hit this “annotate your function’s closure parameter with @escaping” error, myself.

“@escaping, Huh? What’s that?!”

1 – I wasn’t thinking about escaping closures because
2 – I had no idea that I could think about escaping closures!!

It turns out that this could have been really bad, agreed? Asynchronous behavior in software requires a little more thought than your normal top-down procedural approach.

If the compiler hadn’t stopped me, I could have inadvertently imposed the need to think in terms of dispatch queues or asynchronous callbacks on the users of my API.

Is this only something that “newbies” need to have the compiler’s help with though?

One could argue that I probably should have been aware of this particular feature of Swift — had I been a better developer, maybe I wouldn’t need the compiler to hold my hand so much.

Okay – Fair point. That leads me to one last gleaning from Lattner’s Swift Evolution entry that I’ll comment on before wrapping up.

Writing resilient code

Let me reflect really quickly on one more quote from the Swift Evolution entry before I end for today.

John McCall pointed out that resilience in the type system is different than resilience in practice: An API changing to capture a closure and use it long after it was originally passed is likely to break the clients regardless of whether the type system captures this as an issue. He argues (and the argument is strong IMO) it is better for resilient APIs to default to @noescape, since that forces the author of V2 to think about whether they are breaking their clients. (emphasis mine)

Resilience is all about how clients are affected when you change the API or its implementation.

Suppose that a team mate of mine writes a function… She’s just created an API, true?

Suppose that the function asks for a closure, but for now it’s just a regular old closure. No escaping or anything.

Others on my team are going to start coding against that function’s signature. If the function is honest, it allows me and my team to have expectations about what it’ll do when it executes.

Now suppose that I’m going to work on version 2 of that same API. Only now, I’m going to introduce the opportunity for that closure to escape (maybe intentionally, or maybe accidentally out of ignorance).

Thaaaat’s gonna break my team. For sure.

They’re using the API as it is expecting normal synchronous behavior from the function. Now I’ve gone in and fundamentally changed what their expectations should be.

In other words, I haven’t been very resilient.

The default behavior of closures passed to functions is to be @noescape. If I introduce the possibility for that closure to escape, I need to be red-flag warned about that, because I need to come up with some way to communicate this breaking change to the clients of the API. And/or provide an alternative so that clients of API v1 can still use it as expected.

Most of all, I need to think about the implications of what I’m doing, and sometimes (a lot of the times) that takes prompting.

The bottom line – The compiler is making you think

All of this to say: The compiler is making you think. Not only that, it’s forcing you to conform.

From what I’ve found, that’s the idea behind “why” we need to mark escaping closures with @escaping in Swift.

You might also enjoy…

What in the World is an “Escaping Closure” in Swift?

What in the World is an “Escaping Closure” in Swift?

Wed, 26 Apr 2017 14:41:07 +0000

If you’re mostly in the business of coding up closures to pass off to other functions as callbacks, you may not have run into the concept of an “escaping closure” yet.

When you step out of the role of consuming other peoples’ APIs in to the realm of creating your own (and you do this all the time!), this is where you’ll likely run into the concept of an “escaping closure” in certain scenarios.

I want to start off by defining the term. Then I’ll throw out a couple of usage scenarios that cause us to need to think in terms of a closure “escaping”.

Definition

First, a definition, shall we?

A closure is said to escape a function when the closure is passed as an argument to the function, but is called after the function returns.
–Apple Developer Documentation

So apparently, you can get yourself into the situation where you’re designing a function that takes in a closure as one of its parameters:

func doSomething(completion: () -> Void) { ... }

Furthermore, it appears that it’s possible to find yourself in a situation where the closure will execute, but somehow, it doesn’t get executed until after the function it got passed into returns. So it would go something like this:

Call doSomething and pass it a closure of Type () -> Void
doSomething performs its work and returns
The closure you passed (the one of Type () -> Void) gets executed

Weird, huh? How in the world can that happen? I’ll talk about that in a second.

The point for now is this: whenever you’re in a situation like this where the closure that you pass to a function gets executed after the function you passed it to returns, you’ve got an “escaping closure” on your hands.

As an API consumer, you might not know or care about the escap-y-ness of the closure.

As an API designer (which again, could be yourself, if you’re the one writing the definition of doSomething(completion:)), you have to care, because the Swift compiler will be angry with errors if you don’t.

So how do “escaping closure” scenarios happen?

Escaping closure scenarios

Here are a few scenarios that give rise to escaping closures.

Storing the closure as state

Apple’s docs give an example of appending a closure that’s passed into a function to a mutable array of closures within your class/struct:

1var completionHandlers: [() -> Void] = []
2
3func doSomething(completion: () -> Void) {
4    completionHandlers.append(completion)
5}

Presumabley then, at some later time after doSomething returns, all of the completion handlers in the array will be looped over and executed (or something like that)…

As you can see, this follows the 1. Pass closure, 2. doSomething returns, 3. Closure executed pattern we had before, doesn’t it?

So this is one scenario that could give rise to an escaping closure, IF you designed your system this way.

Whenever you take the closure, store it as state, and then execute it at a later time, the closure is “escaping” the function it got passed into.

Asynchronous asynchronous callbacks

No, I didn’t get repetitively redundant there. Well… I did, but it was on purpose. :]

Supposing that you’re working on your doSomething(completion:) function.

Within it, you make a call to another function that performs an asynchronous action and asks for a completion closure of its own.

What if you only want to call the completion handler that was passed into doSomething after the asynchronous action of the other function completes. That is, what if you only want the two completion handlers to be executed together:

1func doSomething(completion: () -> Void) {
2    doSomeOtherAsynchronousThing(completion: {
3    () -> Void in
4    // code that executes after the other asynchronous thing is done
5    completion()
6    })
7}

Here, you’ve got this nested asynchronous behavior going on, don’t you? Asynchronous asynchrony is happening.

Whenever you defer the execution of a closure to a time that’s after the “parent” function returns, you’ve got an “escaping closure” on your hands.

Declaring “this is an escaping closure!” in code

Whenever you’re implementing a function that introduces the possibility for a closure passed to it to escape, you’ll know it.

The Swift compiler will complain, and your app won’t build:

What do you do to fix it?

It’s pretty simple. In the declaration line of your function, you need to add the @escaping attribute right before the closure’s Type declaration:

doSomething(completion: @escaping () -> Void)

Wrapping up

My goal was to shed some light on the concept of “escaping closures”. With the definition and the example scenarios that give rise to escaping closures, my hope is that things are a little more clear for you. Sound off in the comments if you’re still struggling, or if you’ve run across other scenarios requiring you to use the @escaping attribute!

Core Data Model Attributes and NSManagedObject Property Types Must Match!

Sun, 23 Apr 2017 20:03:34 +0000

I admit – it might have taken me less time to figure out my runtime exception if I hadn’t just migrated my project to Swift 3 when I encountered the bug.

That’s the problem isn’t it? You go in… you intend to do one thing. Before long, you’ve got 15 files with an M out to the right. The project builds (finally), but ah – then there’s runtime.

When the crash occurs, you’re never sure if it was an existing problem, or if it was caused by the code conversion. Who knows – maybe it’s both?

Perhaps this is a story more about code conversion than it is about Core Data. In any case, perhaps it’ll help a poor soul struggling to figure out why just happened.

Data model Attributes and NSManagedObject property types – Match ’em!

Whenever you’re creating a subclass of NSManagedObject for the Entities in your data model, you’re in a mapping process.

Each Attribute on an Entity maps over to a property on the NSManagedObjectSubclass.

Not only must the names of those Attributes and properties match, but the Types of each must match as well.

Optionals are Types

String isn’t the same as String?.

Date isn’t the same as Date?.

They’re different Types.

So what happens if you specify that a certain Attribute named, say, createdOn is a Date with the Optional checkbox checked in the data model designer like this:

And over in the implementation of your NSManagedObject subclass, you have code that’s written like this:

`1`	`@NSManaged var createdOn: Date //instead of Date? (ie, the ? is missing)`

What’ll happen? Well, I can tell you what’ll happen. :]

When you run the app and attempt to load objects from your persistent store that have been saved with nil for the createdOn value, your app will blow up:

Xcode isn’t entirely unhelpful. While the EXC_BAD_INSTRUCTION message in the text editor isn’t very illuminating, the Debug Navigator on the left () provides some clues.

For me, it displayed just the breadcrumb that made me go, “Oh! Let me go check and see if I’ve got a Type mis-match between my data model and my NSManagedObject subclass”:

Interesting… It looks like there was an attempt to go from an NSDate? (optional) instance to a Date (non-optional).

The issue isn’t that I’ve got a mismatch between NSDate and Date. The runtime can swap those around and substitute them easily.

Rather, it’s that I’m trying to go from optional, where nil is fine, to non-optional, where nil…well…crashes things.

Lessons learned

What have I learned?

1 – Map Attributes to NSManagedObject subclass properties carefully.
2 – Don’t accidentally miss a ? to indicate that a property is optional if I’ve got it marked as optional in the data model
3 – Read the Debug Navigator. It’s not just a list of gibberish – it can actually provide helpful clues so you know where to go look to solve your problem!

Resources

Core Data Fundamentals with Swift

How to Unwrap Multiple Optionals with One If-Let in Swift

Wed, 19 Apr 2017 17:25:41 +0000

What do you do when you’ve got two (or more) optionals that you need to safely unwrap and work with?

Code examples

Suppose that you’ve got two arrays, both of which are optional. What I want to do right now is walk through a couple of scenarios where I unwrap them at the same time and print them to the console with a single if-let statement.

First, watch how it’s done to accomplish the goal of this article’s title. :]

Then, compare what you expected to be the print output, to the actual output to make sure your understanding of how the syntax works is complete.

Ready?

Scenario 1: Both arrays are initialized (non-nil)

1var greetings: [String]? = ["Howdy!", "Hello!"]
2var salutations: [String]? = ["Hi!", "Hey!"]

1if let g = greetings, let s = salutations {
2    print(g)
3    print(s)
4}

Output:
[“Howdy!”, “Hello!”]
[“Hi!”, “Hey!”]

Breaking it down

The syntax for unwrapping multiple optionals with a single if-let block is straightforward. It’s if followed by a series of let [constantName] = [optionalName] statements, separated by commas.

The output of this one is pretty much what you’d expect, too. The string form of the arrays is printed to the console window in Xcode or in your Playground.

Scenario 2: One array is initialized (non-nil), and the other is nil

Now suppose that the arrays looked like this:

1var greetings: [String]? = ["Howdy!", "Hello!"]
2var salutations: nil

1if let g = greetings, let s = salutations {
2    print(g)
3    print(s)
4}

Question: What do you think will be printed?

[“Howdy!”, “Hello!”] and “nil”
Just [“Howdy!”, “Hello!”]
Nothing will be printed

If you chose door number 3, you’d be correct.

The if-let block between the {}’s is only executed if both greetings and salutations are non-nil.

Takeaway

Unwrapping multiple optionals with a single if-let statement is pretty easy: if followed by a series of let [constantName] = [optionalName] statements, separated by commas.

The behavior is similar to using the && operator in a normal if condition. It’s like saying “if this optional is non-nil AND this optional is non-nil, then do this”

If you expect to work with one of the optionals in the list even if the other is nil, you’re going to need to split that up into multiple if-lets:

1if let g = greetings {
2    print(g)
3}
4
5if let s = salutations {
6    print(s)
7}

Creating the Core Data Stack with Backwards Compatibility in Swift

Sun, 16 Apr 2017 21:23:46 +0000

In 2017, we live in a world where there are still non-iOS 10 devices out in the wild. If your app is targeting an iOS version earlier than iOS 10, or macOS Sierra (10.12), you’ll be unable to take advantage of Core Data’s latest “stack creation” class called NSPersistentContainer. So what can you do?

While NSPersistentContainer does aim to simplify the stack creation process, at the end of the day, it’s not terrible to have to mess with some of this Core Data plumbing.

End goal of creating the Core Data stack

The end goal of Creating the Core Data stack is to get an instance of NSManagedObjectContext. That’s it.

Most apps that rely on Core Data will end up making fetch requests to obtain data, or wire up other classes like NSFetchedResultsController. To make these things work, you’ve got to provide an instance of NSManagedObjectContext.

NSManagedObjectContext is sort of that central gear in the whole system that makes the other gears turn.

So. Bottom line: Once you have an instance of NSManagedObjectContext, you’re golden. That’s what creating the Core Data stack gives you in the end.

3 steps to creating the Core Data stack

The Core Data stack can be created in about 3 steps:

1) Initialize an instance of NSManagedObjectModel

This corresponds to your .xcdatamodeld file. You’ll want to glance over to the project navigator on the left and locate the .xcdatamodeld file to record its name for this step.

1
2
3

// Initialize NSManagedObjectModel
let modelURL = Bundle.main.url(forResource: "NameOfDataModel", withExtension: "momd")
guard let model = NSManagedObjectModel(contentsOf: modelURL!) else { fatalError("model not found") }

2) Initialize and configure an instance of NSPersistentStoreCoordinator with the NSManagedObjectModel instance and an NSPersistentStoreType

The reason you create the NSManagedObjectModel instance first is because the next step depends on it. NSPersistentStoreCoordinator will use your NSManagedObjectModel instance to configure itself and prepare to create the correct kind of persistent store based on what NSPersistentStoreType you tell it to use.

In the code example that follows, I used NSSQLiteStoreType to create a SQLite persistent store. Regardless of what kind of persistent store you use though, NSPersistentStoreCoordinator needs your managed object model instance.

// Configure NSPersistentStoreCoordinator with an NSPersistentStore
let psc = NSPersistentStoreCoordinator(managedObjectModel: model)

let storeURL = try! FileManager
        .default
        .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
        .appendingPathComponent("NameOfDataModel.sqlite")

try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: nil)

3) Initialize an instance of NSManagedObjectcontext and assign it the NSPersistentStoreCoordinator instance

The last step is to initialize an instance of NSManagedObjectContext and assign it the NSPersistentStoreCoordinator instance.

1
2
3

// Create and return NSManagedObjectContext
let context = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)
context.persistentStoreCoordinator = psc

Putting it all together – creating the Core Data stack in code

When I create the Core Data stack, I like to encapsulate the code in a stand-alone function that returns an instance of NSManagedObjectContext.

Here are all three steps put together:

 2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22

                      Once you’ve got a function like createMainContext(),

class="lnt"> 1 language-swift" data-lang="swift">func createMainContext() -> NSManagedObjectContext {

// Initialize NSManagedObjectModel let modelURL = Bundle.main.url(forResource: "NameOfDataModel", withExtension: "momd") guard let model = NSManagedObjectModel(contentsOf: modelURL!) else { fatalError("model not found") }

// Configure NSPersistentStoreCoordinator with an NSPersistentStore let psc = NSPersistentStoreCoordinator(managedObjectModel: model) let storeURL = try! FileManager .default .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true) .appendingPathComponent("NameOfDataModel.sqlite")

try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: nil)

// Create and return NSManagedObjectContext let context = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType) context.persistentStoreCoordinator = psc

return context class="p">}

you’ll be able to call it to obtain a fully-configured NSManagedObjectContext instance.

I highly recommend you avoid calling it inside any of your view controllers. Instead, my recommendation is to call it to obtain your NSManagedObjectContext instance inside of the AppDelegate's application(_:didFinishLaunchingWithOptions:) function. From there, you can pass it to your first view controller, and from that first view controller on to other view controllers that need it through prepare(for segue:sender:).

For more on this “dependency injection” strategy, or if you’re more of a visual learner, check out my Pluralsight course, Core Data Fundamentals with Swift!

Resources

Core Data Fundamentals with Swift

You might also enjoy…

Swift Tip – Accessing a User’s Documents Directory with URL Extension

Mon, 10 Apr 2017 18:01:23 +0000

When you need to access the documents directory on a user’s device, what do you do?

In the past, I know I’ve gotten used to typing out the same set of code over and over throughout my apps. I know, I know – DRY – don’t repeat yourself.

One way to simplify this is to use a Swift extension to URL. Doing this will help you centralize where this code is located in your app, and keep your code DRY. If you need to access the documents directory in more than one spot, you’re just a URL property call away from it.

Extension implementation

extension URL {
    static var documentsURL: URL {
        return try! FileManager
            .default
            .url(for: .documentDirectory, 
                 in: .userDomainMask, 
                 appropriateFor: nil, 
                 create: true)
    }
}

Extension usage

Here’s an example of using the extension during the routine to create the Core Data stack. For that process, you need to grab a URL to where your SQLite database file will be located. Take a look:

// ...

let storeURL = URL.documentsURL.appendingPathComponent("AppDatabase.sqlite")

// use the URL

You could be needing to access the directory for saving files or retrieving files totally unrelated to Core Data. No matter what you’re doing, being able to write URL.documentsURL is pretty convenient!

Core Data Fundamentals with Swift

Sun, 02 Apr 2017 22:04:02 +0000

Core Data is an extremely powerful framework for managing and persisting data on your users’ devices. And let’s face it: saving data to your users’ devices is inevitable. The question is, which data management and persistence technology you use when the time comes for you to tackle this challenge?

“Core Data Fundamentals with Swift” will give you the essential skills you need to architect an app to use Core Data.

Course Trailer

You can check out a trailer of the course over at Pluralsight completely free.

Resources

Core Data Fundamentals with Swift

Topics

1 – Getting Started with Core Data

Module 1 is the introduction to the course with discussion of the motivating factors for using Core Data, course prerequisites, storyline overview, and a demo of the end product of the course.

I had a blast making the demo app. Essentially, I put you in the scenario where we team up to build a prototype of an app that our Human Resources department has come to us with. They came to us with an idea – Over the past year or two, they’ve noticed that employee morale is down a bit. To improve the situation, they’re implementing a new Employee Recognition program. As part of the new program, they’ve come to our internal software development team to see if it might be possible to build some kind of an app that allows employees to recognize one another for jobs well-done – electronic “Shout Outs” if you will.

And that’s where you and I come in – HR wants us to prototype something up so that they have an idea of what’s possible.

Throughout the course, we work on this prototype app together!

2 -Setting up the Core Data Stack

Working with Core Data begins with setting up the Core Data Stack. You will learn how to implement the stack, how to architect your app for testability and maintenance, and how to share Core Data components (such as NSManagedObjectContext) between view controllers.

3 – Creating a Data Model

Building a data model is the foundation for persisting information with Core Data. You will learn to create a data model in Xcode, and you will understand how to work with that model in Swift code.

4 – Building Relationships Between Entities

Understanding the importance of relationships and how to build them is vital to the efficiency and expressiveness of your Core Data model. You will learn why building relationships is worth the investment, and then you will gain the skills you need to be able to build these strategic links between Entities in Xcode.

5 – Saving, Accessing, and Deleting Data

Having the ability to save data to a Core Data persistent store is essential. Being able to retrieve that data later on for display, for modification, or even for removal from the persistent store is also a critical. You will learn the mechanics of how to use the Core Data framework classes that are involved with saving, accessing, and deleting data in this module.

6 – Showing and Synchronizing Data with NSFetchedResultsController

Displaying data in a user interface and keeping it synchronized with the state of the persistent store is a critical piece of the Core Data puzzle. You will learn how to use NSFetchedResultsController for keeping table views in sync. You will also examine using the iOS Notification Center as an alternative way to detect and respond to changes in the persistent store.

7 – Changing Core Data Models

It’s inevitable: You’re going to have to change your data model from its original form sooner or later. This module will guide you in creating new versions of your data model. You will also learn how to migrate your persistent store to new data model versions so that no data is lost as you make changes.

8 – Understanding Core Data Changes in iOS 10 and macOS Sierra

Change is constant. Be prepared for the latest enhancements to the Core Data framework by understanding what’s new in Core Data with Apple’s latest platforms. You will learn about a new framework class called NSPersistentContainer that is designed to simplify the Core Data stack creation process. This concluding module will also point you to resources that will help you build on your new Core Data foundation.

Course Resources

Demos of technology in action are super important to me. That being the case, I tried to pack as much demo content into the course as possible. You’ll get to see the full array of dev-time experiences, not just the final “it works perfectly” outcomes.

The course also comes complete with working Xcode projects that gradually build you up to the final version of the app, one step at a time through each module.

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Core Data: Solving Ambiguous Type / Redeclaration of Type

Wed, 29 Mar 2017 02:57:05 +0000

I just finished roasting some coffee from Peru. I’ve never had it before, but it got me thinking about my Roaster On the Go “app” as I thought about the context that I could use to show you the solution to the compiler error described in the title. I used this to demonstrate Working with Unwind Segues Programmatically in Swift, but now I’m going to use it to show you how to resolve these errors that can crop up when you’re implementing NSManagedObject subclasses for your Core Data Entities.

Scenario – Adding a data model

The “app” doesn’t currently use Core Data, but for this article, I’ve created a rudimentary data model that includes a single Entity called Product:

Now suppose that I’m ready to implement a subclass of NSManagedObject for the Product Entity.

Doing so right now using Xcode 8’s default settings is going to give me all kinds of issues.

To be clear, I’m using Xcode 8.2 for this scenario.

The error that I’m getting when I attempt to build after creating a subclass of NSManagedObject for the Product Entity is one of the following (depending on how you choose to create the NSManagedObject subclass):

Invalid redeclaration of ‘Product'

‘Product’ is ambiguous for type lookup in this context

or in the compiler output

filename “Product+CoreDataClass.swift” used twice

What’s happening??

This is a conflict with Xcode 8’s auto codegen for NSManagedObject subclasses. In some versions of Xcode 8 (version 8.2, for example), this auto codegen is turned on by default. This can present a problem if you intend to manually create NSManagedObjectSubclasses for your Entities.

Solution

To solve this problem, or to avoid it before it occurs, you essentially need to turn off Xcode 8’s auto code generation feature for NSManagedObject subclasses if you intend to implement your NSManagedObject subclasses manually (my personal preference).

Take a look at the steps below to get your project building again:

1 – Turn off automatic code generation for NSManagedObject subclasses

Open your data model (the .xcdatamodeld file in your project).

Click on each Entity in your data model and in the Data Model Inspector of the Utilities Pane, change the Codegen property from “Class Definition” or “Category/Extension” to “Manual/None”:

2 – Choose module

You also need to tell Xcode where it can look to find a definition for the NSManagedObject subclass that you will implement for this Entity by choosing “Current Product Module” for the Module value:

Save your .xcdatamodeld file.

3 – Clear derived data

Behind the scenes, Xcode creates files and implements Types for the Entities in your data model. It puts them in your derived data folder and automatically traverses this folder to look for Type definitions for Core Data Entities. So in order to get your project building again, you need to get rid of those files that Xcode created automatically.

The “big hammer” for this is to simply clear all of your project’s derived data. To do this, click on the Products menu, hold down the Option key, and click “Clean build folder…”:

Press Option Key -> Clean Build Folder..." width="224" height="321" class="alignnone size-full wp-image-13118" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2017/03/CleanBuildFolder.png 224w, https://www.andrewcbancroft.com/wp-content/uploads/2017/03/CleanBuildFolder-209x300.png 209w" sizes="(max-width: 224px) 100vw, 224px" />

Alternatively, you could opt to go in and delete the only auto-generated Swift files, but you’ve got to do some digging.

Click on File -> Project Settings:
Project Settings" width="353" height="495" class="alignnone size-full wp-image-13121" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2017/03/ProjectSettings1.png 353w, https://www.andrewcbancroft.com/wp-content/uploads/2017/03/ProjectSettings1-214x300.png 214w" sizes="(max-width: 353px) 100vw, 353px" />

Next, click on the arrow next to the path leading to your default derived data folder:

Next, find the folder for your project at the root of your default derived data directory (where you were taken in Finder when you clicked the arrow in Project Settings). Then get ready to dig…

Click Build -> Intermediates -> ProjectName.build -> Debug-iphonesimulator -> ProjectName.build -> DerivedSources -> CoreDataGenerated -> ProjectName

Delete the .swift files in this folder.

4 – Rebuild

After you rebuild, any compiler errors you previously had, related to “ambiguous Type” or “redeclaration of Type” should be resolved!

Resources

Core Data Fundamentals with Swift

Using a Core Data Model in Swift Playgrounds

Sun, 10 Jul 2016 20:48:54 +0000

Did you know that you can tinker with Core Data inside of Swift playgrounds in Xcode? You can!

Jeremiah Jessel, author at http://www.learncoredata.com, wrote up an article in 2015 detailing how you can use the Core Data framework inside a playground. He shows how you can do everything from setting up the Core Data stack, to creating NSManagedObjects programmatically in code. Great stuff!

After I read his guide, I got to thinking: I wonder if you can take an .xcdatamodeld file created with Xcode’s Data Model designer and use it in a Playground….

The short answer is, kinda. You can’t use the .xcdatamodeld file (at least, I couldn’t find a way), BUT, you can use the compiled “momd” file that gets created when you build your app.

Limitations

There’s at least two limitations / caveats I’ve come across as I’ve been playing with this concept:

No NSManagedObject subclasses

While you can create instances of the Entities in the model, if you’ve created NSManagedObject subclasses for your Entities, you won’t be able to use those in the playground. You’d have to resort back to setting properties on your NSManagedObject instances using setValue(_: forKey:).

But this is a minor drawback, especially if you’re just wanting to tinker.

Model updates

After you read the walkthrough, you’ll know how to get the model into your playground.

Here’s the deal though: If you ever make changes to your model, you’ll need to go through the steps necessary to re-add a freshly-compiled model to the playground’s Resources folder that includes the changes. This is because resources that are added to a playground are copied, not referenced.

I don’t think that’s a terrible draw-back, especially once you know how to do it.

So how do you do it? Here’s how:

Walkthrough

Get started by adding a Data Model to your project. If you’ve got a project already going that uses Core Data, you probably already have a .xcdatamodeld file in your project. If you don’t, though, one is easily add-able from the File menu:

Add Data Model file (unless you already have one)

File -> New -> File…

For my “smoke test”, just to see if it was possible, I left the default value for the model name as “Model.xcdatamodeld”.

Add entity with attribute

Once I had the data model added to the project, I went in and added an entity (named “Entity”) with an attribute (named “attribute” of type Integer 16):

Add a playground

Next up, I added a new playground to my project:

File -> New -> Playground…

Build project; Locate “momd” file

With a playground and a data model has some structure to it, I built the project (CMD + B) so that the .xcdatamodeld file would be compiled into an “momd” file. It’s the momd file that needs to be added to the playground as a resource.

To find the “momd” file, expand “Products” in your project navigator, right-click the .app file, and click “Show in Finder”:

Show .app package contents

In the finder window, right-click the .app file, and click “Show package contents”:

Drag “momd” file from Finder to playground Resources folder

Write Core Data code to use model

That’s it! Now that the “momd” file is in the playground’s Resources folder, you’re set to write code against it. You can insert NSManagedObject instances, perform fetch requests, etc. Here’s an example that I wrote up:

import UIKit
import CoreData

// Core Data Stack Setup for In-Memory Store
public func createMainContext() -> NSManagedObjectContext {
    
    // Replace "Model" with the name of your model
    let modelUrl = NSBundle.mainBundle().URLForResource("Model", withExtension: "momd")
    guard let model = NSManagedObjectModel.init(contentsOfurl: modelUrl!) else { fatalError("model not found") }
    
    let psc = NSPersistentStoreCoordinator(managedObjectModel: model)
    try! psc.addPersistentStoreWithType(NSInMemoryStoreType, configuration: nil, URL: nil, options: nil)
    
    let context = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
    context.persistentStoreCoordinator = psc
    
    return context
}

let context = createMainContext()

// Insert a new Entity
let ent = NSEntityDescription.insertNewObjectForEntityForName("Entity", inManagedObjectContext: context)
ent.setValue(42, forKey: "attribute")

try! context.save()

// Perform a fetch request
let fr = NSFetchRequest(entityName: "Entity")
let result = try! context.executeFetchRequest(fr)

print(result)

Woohoo! I thought this was pretty cool.

Don’t forget: If you make updates to your model, you need to re-build your app, delete the “momd” folder from your playground’s resources, re-drag the freshly-compiled “momd” file to your playground again to work with the latest version of the model.

Potential usefulness

The other important question to ask, besides “I wonder if this is possible?” is “How is this useful?”

Learning. Playgrounds in and of themselves make sense as a learning tool. How cool is it to be able to build the model you’re thinking of in the Xcode designer, import that into a playground, and tinker with it as a learning exercise??
This could also be useful when you need to try out your data model but don’t really want to wire it up to an actual user interface yet. Strip away all the UI complexity and just work with the data model… in a playground! It just seems like a more elegant solution to the “print it out to the console” method of experimenting with the model.
There might be situations when you’re building semi-complicated NSPredicate instances for a fetch request – why not get it working in a playground first, then migrate it over to your app? Just an idea!

You might also enjoy…

Core Data Cheat Sheet for Swift iOS Developers

Using Swift to Seed a Core Data Database

Displaying Data With NSFetchedResultsController and Swift

Sync Table View Data: NSFetchedResultsController and Swift

Resources

Core Data Fundamentals with Swift

Force Unwrapping Swift Optionals: Code Smell!

Tue, 14 Jun 2016 03:54:57 +0000

Do you find your Swift code riddled with !‘s?

I’m becoming more and more uncomfortable with seeing ! throughout my Swift code. It’s just a matter of time before it’s going to bite me.

Often, I do it because it’s the “easy thing” to do at the time. But it’s dangerous.

Swift optionals are trying to help us. They force us to deal with the possibility of something not having a value.

By force unwrapping an optional with the ! operator, we’re declaring, “This will never be without a value”. Really? Never? Are you sure? Only a Sith deals in those kinds of absolutes.

When a function returns an optional, or a property is declared as optional, we are, at the very least, meant to assume that there is a possibility of nil lying underneath.

Therefore, I’m considering it a sort of “code smell” when I see it in my own code. It’s not too much to throw an if let or a guard let in there to handle the possibility of nil.

Two exceptions

Two exceptions to the code smell rule:

1 – IBOutlet and IBAction

IBOutlets and IBActions are force-unwrapped, but that’s because they get injected when the Storyboard is loaded at run-time. It’s assumed that these are connected and will be supplied when the scene is loaded. If they get unwired somehow, we want an instant crash so we know to go back to the Storyboard and re-wire things to the view controller.

2 – Required properties to be set in prepareForSegue

Along those same lines, I consider properties that must be set when navigating to a new view controller to be in the same category as an IBOutlet or an IBAction. I want to know right away if I forget to set those in prepareForSegue in the parent view controller. So I’ll often force unwrap the optional in the declaration so that there’s an as-immediate-as-possible crash if it’s not set.

Hopefully when you’re working with optionals from here on, you’ll take a second sniff when you see the ! operator.

Is Protocol Oriented Swift Better than Object Oriented Swift?

Sun, 12 Jun 2016 20:59:48 +0000

A question was asked on Reddit and showed up in my feed as I was browsing this weekend:

What does protocol oriented programming mean, and why is it better than OOP?

I really like a few things that were said in one of the top “Explain Like I’m 5” comments that was posted in response to the question by CodaFi.

“Explain Like I’m Five” – A laundry service example

First, the example provided was very understandable. I highly recommend you jump over and just read through what the commenter wrote.

The theme was “laundry service”. Supposing that there was a Laundry object that encapsulated certain laundry-related functions… “Launder my clothes, please” — “Okay, here’s your clothes!”. You as a client simply interact with Laundry by saying “Launder, please!”. The Laundry object goes off and does its thing, which could range from simple to incredibly complex – the beauty is that as a client, as a person needing laundry done, you don’t care. As long as the laundry gets done and you get your clothes back, life is great!

“Problems” with Object Orientation

In my guide on the Fundamentals of Callbacks for Swift Developers, I describe the scenario that we’re all in as developers:

When we’re building software, we’re either using code built by others, or creating code for others to use, are we not? We’re either using code that “hooks into” what other developers have designed and made available to us, or we’re creating code that other code will “hook into” and interact with, even if the “other code” is written by us in our own app.

We wear two hats at once, when it comes to being clients and creators of code.

But what if we’re working with a Laundry object as a developer/creator, and not as a client (ie, someone who needs laundry done). What if we, as developers, get handed a Laundry object in a library and we want to customize its behavior… maybe improve the performance of launderClothes(), or override the implementation it to use some amazing new laundry service.

The way we’d do that is by crating a subclass. Here’s the beef with Object Orientation, according to the commenter:

[Object Orientation] encourages “encapsulating complexity” by exposing state and internals through inheritance.

Unpacking that: Software has innate complexity. Objects are “things” that encapsulate that complexity. They do it in a certain way though: They expose certain pieces of state and pieces of functionality. The way those abstractions over complexity get propagated and customized through the system is through this mechanism called inheritance.

But the commenter cites this methodology as “trouble” though. Why? Well…

“I may not want to know how my dry cleaning got done, but if I wanted to design a better route to go from dirty clothes to clean clothes, I would necessarily have to know every last detail of the steps that were performed so I can try to refine them in my subclass.”

So the commenter is coming at it from the point of a developer/creator. It’s pointed out that to truly be able to improve performance or refine algorithms in a subclass, we necessarily have to know every detail of the steps that were performed in the superclass. And it’s not always the case that we can discover that superclass implementation to improve upon it.

Shifting to Protocol Orientation

So… Protocol Orientation? If it’s better, how is it better?

I love how the commenter takes the object oriented example of laundry service, and refines it with nuances that come out of thinking in terms of protocols rather than just objects. Really. Have a look.

The primary difference we see is that rather than having a Laundry object… a single one… that does laundry in its own particular way, a shift occurs: We begin to deal in terms of describing ways to get laundry done.

If I want my laundry done one particular way by one particular guy I go Object-Oriented and stop caring about how things get done. But if I want to generalize over the ways to get laundry done I need to go Protocol-Oriented and stop caring about everything else.

In Protocol Orientation, the only thing that matters is the interface… the things that clients will interact with. Describe that to the best of your ability with a protocol, and let something else come along and worry about the how.

In the end, the only thing that a person needing laundry done needs to know is what interface is available for them to accomplish the laundering they have need of completing.

Being able to sit down and think about how something would look if you removed state and inheritance from the picture and just thought about the bare minimum required interface to that particular task is a far more powerful and simple approach to programming that enables reuse far easier than OO ever did.

Takeaways

The take-away point for me in this thread on Protocol Orientation is this: Protocols are about generalizing. They’re about the interface. It’s about a mindset and a focus (an orientation) toward thinking of ways to do certain things, and describing them clearly in the form of a Type in Swift.

Once the way to do something is described, other things, concrete Types, can come along and implement those in an infinite variety of ways.

Creating Calendar Events with Event Kit and Swift

Thu, 02 Jun 2016 17:37:15 +0000

Folks have asked more about working with Event Kit and Swift, so the series continues with this guide on how to create calendar events with Event Kit and Swift!

Previous guides in the series include the following:

Previous Guides

Demo

Here’s what we’re going for by the end of this:

As with my other guides, I’ve included a working project on GitHub for you to peruse and tinker with:

Resources

Event Tracker – Create Events

Code Example

The majority of the work to create an event happens in the example project’s AddEventViewController.swift file, so that’s where I’ll spend my time in this guide. First, let’s put the relevant code before us:

 1class AddEventViewController: UIViewController {
 2
 3    var calendar: EKCalendar! // Intended to be set in parent controller's prepareForSegue event
 4
 5    @IBOutlet weak var eventNameTextField: UITextField!
 6    @IBOutlet weak var eventStartDatePicker: UIDatePicker!
 7    @IBOutlet weak var eventEndDatePicker: UIDatePicker!
 8
 9    // ...
10
11    @IBAction func addEventButtonTapped(sender: UIBarButtonItem) {
12        // Create an Event Store instance
13        let eventStore = EKEventStore();
14        
15        // Use Event Store to create a new calendar instance
16        if let calendarForEvent = eventStore.calendarWithIdentifier(self.calendar.calendarIdentifier)
17        {
18            let newEvent = EKEvent(eventStore: eventStore)
19            
20            newEvent.calendar = calendarForEvent
21            newEvent.title = self.eventNameTextField.text ?? "Some Event Name"
22            newEvent.startDate = self.eventStartDatePicker.date
23            newEvent.endDate = self.eventEndDatePicker.date
24            
25            // Save the calendar using the Event Store instance
26            
27            do {
28                try eventStore.saveEvent(newEvent, span: .ThisEvent, commit: true)
29                delegate?.eventDidAdd()
30                
31                self.dismissViewControllerAnimated(true, completion: nil)
32            } catch {
33                let alert = UIAlertController(title: "Event could not save", message: (error as NSError).localizedDescription, preferredStyle: .Alert)
34                let OKAction = UIAlertAction(title: "OK", style: .Default, handler: nil)
35                alert.addAction(OKAction)
36                
37                self.presentViewController(alert, animated: true, completion: nil)
38            }
39        }
40     }
41
42     // ...
43}

Code Walkthrough

The general outline of the code is this:

Create an instance of EKEventStore – this will let you create EKEvents and save them.

1let newEvent = EKEvent(eventStore: eventStore)

Pull an EKCalendar instance from the Event Store – this will let you associate an event with a calendar.

1if let calendarForEvent = eventStore.calendarWithIdentifier(self.calendar.calendarIdentifier) { 
2// ... 
3}

Create a new EKEvent instance and set its properties.

1let newEvent = EKEvent(eventStore: eventStore)
2            
3newEvent.calendar = calendarForEvent
4newEvent.title = self.eventNameTextField.text ?? "Some Event Name"
5newEvent.startDate = self.eventStartDatePicker.date
6newEvent.endDate = self.eventEndDatePicker.date

Attempt to save the event with the EKEventStore instance that was created first.

 1do {
 2    try eventStore.saveEvent(newEvent, span: .ThisEvent, commit: true)
 3    delegate?.eventDidAdd()
 4    
 5    self.dismissViewControllerAnimated(true, completion: nil)
 6} catch {
 7    let alert = UIAlertController(title: "Event could not save", message: (error as NSError).localizedDescription, preferredStyle: .Alert)
 8    let OKAction = UIAlertAction(title: "OK", style: .Default, handler: nil)
 9    alert.addAction(OKAction)
10    
11    self.presentViewController(alert, animated: true, completion: nil)
12}

Gotchas

As I was working through this example, I was initially running into trouble when associating my newEvent with the calendar that was passed into AddEventViewController from the parent controller’s prepareForSegue method.

It turns out that if you retrieve a calendar from one EKEventStore instance, say, in the previous view controller, and attempt to assign it to an EKEvent that is associated with a different EKEventStore instance, things become really unhappy when it comes time to save the event.

Specifically, you’ll get an error that says “Thread 1: signal SIGKILL” followed by “Thread 1: EXC_BAD_ACCESS”:

The fix for this was easy, once I figured out what was going on: Simply re-retrieve a calendar instance using an appropriate calendarIdentifier from the EKEventStore instance you’re using to save the EKEvent with:

1if let calendarForEvent = eventStore.calendarWithIdentifier((self.calendar.calendarIdentifier))
2{
3    let newEvent = EKEvent(eventStore: eventStore)
4    
5    newEvent.calendar = calendarForEvent
6    
7    // ...
8}

Wrapping up

My focus in this guide was to demonstrate how to create and save and event to a user’s calendar. I intentionally left out a lot of the navigation aspects and prepareForSegue calls in order to highlight the event creation process itself. Be sure to check out the accompanying Xcode project on GitHub for full details on the flow of the application.

You might also enjoy…

Swift Cheat Sheet for Dates, Formatters, and Date Components

Thu, 26 May 2016 18:04:01 +0000

Working with NSDate, NSDateFormatter, and NSDateComponents can be a little convoluted, so I’ve created myself a cheat sheet that will be updated as I discover new tips and tricks in this realm.

The new cheat sheet can be found over at GitHub in the form of an Xcode Playground:

Resources

Swift Dates Cheat Sheet Playground

Topics that are included in the Playground are as follows:

Getting today’s date
Converting NSDate to String
Converting String to NSDate
Getting components of an NSDate
Setting components of an NSDate
Creating new NSDate instances from NSDateComponent instances

The best way to view this cheat sheet is by downloading the playground from GitHub, but here’s a straight copy-paste from the repo in case you just want to copy and paste it into a playground of your own from here:

 1import UIKit
 2
 3/*: 
 4# Overview
 5This is a cheat sheet for working with dates, date formatters, and date components.
 6
 7*/
 8
 9//: # Today's Date
10
11let today = NSDate()
12let thisTimeTomrrow = NSDate(timeIntervalSinceNow: 86400)
13let thisTimeYesterday = NSDate(timeIntervalSinceNow: -86400)
14
15/*: 
16# Date Formatting
17Working with NSDateFormatter to convert dates to stings and vice-versa
18*/
19
20//: ## Converting dates to strings
21let dateFormatter = NSDateFormatter()
22dateFormatter.dateFormat = "yyyy-MM-dd"
23
24print(dateFormatter.stringFromDate(today))
25
26dateFormatter.dateFormat = "MMM dd, yyyy"
27
28print(dateFormatter.stringFromDate(today))
29
30
31//: ## Converting strings to dates
32
33// Consider what might potentially come back from an API of some sort and set a dateFormatter's dateFormat property appropriately...
34
35dateFormatter.dateFormat = "yyyy-MM-dd"
36var stringFromApi = "2016-01-01"
37var date = dateFormatter.dateFromString(stringFromApi)
38
39stringFromApi = "May 26, 2016"
40date = dateFormatter.dateFromString(stringFromApi)
41
42/* Notice how the format set to the date formatter (yyyy-MM-dd) differs from the format that came back from the API (MMM dd, yyyy), which resulted in `date` being nil.
43*/
44
45/*:
46# Date Components
47Working with NSCalendar and NSCalendarUnit to work with components of dates.
48*/
49
50//: ## Getting date components
51var calendarUnitFlags: NSCalendarUnit = [.Year, .Month, .Day, .Hour, .Minute, .Second]
52var dateComponents = NSCalendar.currentCalendar().components(calendarUnitFlags, fromDate: NSDate())
53dateComponents.year
54dateComponents.month
55dateComponents.day
56dateComponents.hour
57dateComponents.minute
58dateComponents.second
59
60// Observe how leaving out .Hour, .Minute, and .Second affects the values of those components of a date:
61calendarUnitFlags = [.Year, .Month, .Day]
62dateComponents = NSCalendar.currentCalendar().components(calendarUnitFlags, fromDate: NSDate())
63dateComponents.year
64dateComponents.month
65dateComponents.day
66dateComponents.hour
67dateComponents.minute
68dateComponents.second
69
70//: ## Setting date component values
71
72dateComponents.year = dateComponents.year + 1
73dateComponents.month = 1
74dateComponents.day = 1
75dateComponents.hour = 0
76dateComponents.minute = 0
77dateComponents.second = 0
78
79//: ## Creating dates from components
80let newDate = NSCalendar.currentCalendar().dateFromComponents(dateComponents)

Parse PFCloud – “JSON text did not start with array or object”

Fri, 20 May 2016 03:33:03 +0000

It’s always the little things that lead to flatter foreheads (or at least it is for me).

Banging my head against the desk this evening working on a Parse migration, I finally figured out what was causing an error condition in a PFCloud function call.

The request to the server succeeded, but the response was malformed somehow:

Error Domain=NSCocoaErrorDomain Code=3840 “JSON text did not start with array or object and option to allow fragments not set.” UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set.}

“What?? I know the response is supposed to be JSON – I can even test it out and it works great in Postman.”

Weeeelll, it turns out that if you don’t get the URL to your self-hosted Parse Server correct, you’re going to get a response that’s not JSON. Doh!

I had left off the “/parse” portion of the URL to my self-hosted parse server:

 1func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]?) -> Bool {
 2    // Override point for customization after application launch.
 3    let configuration = ParseClientConfiguration {
 4        $0.applicationId = "YourAppId"
 5        $0.clientKey = "YourClientKey"
 6        $0.server = "https://your-self-hosted-parse-server/parse"
 7    }
 8    Parse.initializeWithConfiguration(configuration)
 9    
10    return true
11}

So, the bottom-line take-away? Make sure you get the full URL to your self-hosted Parse Server set to the server property of your ParseClientConfiguration instance. That endpoint could vary based on how you deployed the server to your cloud host of choice. For me, it was my goofy mistake of leaving off “/parse”.

Go forth and may your forehead be ever-more round than mine.

Working with Swift: Adopt a Protocol or Pass a Function?

Thu, 05 May 2016 17:59:16 +0000

Without fail, any time Rob Napier (@cocoaphony) speaks or writes, I gain insight into new and deeper ways to solve problems with Swift.

In January 2016, he gave a talk at dotSwift, and I wanted to record my thoughts on something he said that made a lot of sense when it comes to the topic of, “Should I create and adopt a protocol for this Type I’m creating, or should I just pass it a function instead?”

Two insights

During the talk, he compared some scenarios that were meant to help determine when to create a protocol, or when doing so would be overly complex, and passing a function might be the simpler thing to do instead.

Two phrases caught my attention:

A protocol is really just a promise to implement some functions, and a struct is mostly just a bundle of functions that implement the promise.

and

I can pass you an object that promises a function, or, I could just pass you the function.

[mind blown]

So in other words, there are times when, rather than going through the formality of…

Creating a protocol defining one or more functions that should be implemented
Creating a Type that adopts that protocol to promise that “I (as a class/struct/enum) will implement this/these function(s)”
Creating an instance of that Type
Passing off the instance to another Type that needs to call that promised function

…life might be simpler and code might be more clear and more concise when you just… pass the function instead!

When to pass a function

Rob gave us a couple or three rules of thumb. Not hard-and-fast, “It should always be this way”, but just some guiding thoughts to filter our decision-making about our architecture.

When it comes to finding opportunities that lend themselves to going the “just pass the function” route, consider the following:

If you’re creating a Type that depends on a single piece of functionality (a single function), maybe try depending on / passing just the function, rather than creating a protocol.
If you’re creating a Type that depends on more than a single function, but the nature of the dependent relationship is short-lived, maybe try depending on / passing just the function. How do you know if it’s short-lived? Ask, “How many times am I going to call the function(s) that I depend on? Once, and then I’m done? Or multiple times throughout the application life-cycle?” If it’s a once and done kind of relationship, much like a callback, then perhaps just depending on and passing the function, rather than creating a protocol, is the simpler route.

When to use a protocol

For some rules of thumb when it comes to choosing a protocol over just passing a function, you might consider:

If you’re creating a Type that depends on 3 or more related functions, wrapping those functions up in a protocol might be cleaner and more clear.
If you’re creating a Type that depends on some functions for a long period of time, consider a protocol. Long-lived relationships are better-described in a protocol. Think of something like a table view’s data source. This is a good example of when to use a protocol to describe the dependency and the relationship, because as data changes, the table view will need to constantly call into those protocol methods to refresh itself.

How to depend on a function

In order to fully grasp how to go the “just depend on / pass the function” route, you need to have an understanding of how function Types are described in Swift. With this knowledge, you’re set to do a couple of things:

1 – Create a property on the Type you’re implementing that is of some function Type. For example:

 1struct Vehicle<Fuel> {
 2    let move: (Fuel) -> Void
 3}
 4
 5// Fuel Types
 6struct Gas {}
 7struct RocketFuel {}
 8
 9let car = Vehicle<Gas>(move: { _ in print("use gasoline to move") })
10
11let rocket = Vehicle<RocketFuel>(move: { _ in print("use rocket fuel to move") })
12
13car.move(Gas())
14rocket.move(RocketFuel())

A full explanation of indicating function Types can be found by reviewing my guide on Swift Functions as Types

2 – Declare that such-and-such parameter on a function within your Type must be a function Type. For example:

1func getData(completion: (NSData) -> Void) {
2    let data: NSData = // do something to go get data
3
4    // call completion handler when getting data is done
5    completion(data)
6}

The above is an example of a callback scenario, which I give full treatment in Fundamentals of Callbacks for Swift Developers

You might also enjoy…

Listing Calendar Events with Event Kit and Swift

Thu, 28 Apr 2016 17:50:22 +0000

This is the continuation of a series of articles I’ve writing for Swift developers working with Event Kit.

Supposing that after asking the user for permission to use their calendars, and even allowing users to create new calendars from within your iOS app, one possible next step could be to list out all of the events for a calendar that they tap on.

Demo

Here’s what we’re going for by the end of this:

In this walk-through, I’ll explore the Event Kit API that allows us to query the user’s device to find and list out events for a calendar that match a date range.

Example project

I’ve got an example project up on GitHub that contains all the code necessary to list out events for a calendar inside of a table view. You can download that project here:

Resources

Event Tracker Example Project

Querying for events

The primary thing you’ll need to do in order to display a list of events from a calendar is to query the event store for events matching a properly configured NSPredicate.

Here’s a snippet of code, followed by an analysis of what’s going on:

 1class EventsViewController: UIViewController, UITableViewDataSource {
 2    var calendar: EKCalendar! // Passed in from previous view controller
 3    var events: [EKEvent]?
 4
 5    // ...
 6
 7    func loadEvents() {
 8        // Create a date formatter instance to use for converting a string to a date
 9        let dateFormatter = NSDateFormatter()
10        dateFormatter.dateFormat = "yyyy-MM-dd"
11        
12        // Create start and end date NSDate instances to build a predicate for which events to select
13        let startDate = dateFormatter.dateFromString("2016-01-01")
14        let endDate = dateFormatter.dateFromString("2016-12-31")
15        
16        if let startDate = startDate, endDate = endDate {
17            let eventStore = EKEventStore()
18            
19            // Use an event store instance to create and properly configure an NSPredicate
20            let eventsPredicate = eventStore.predicateForEventsWithStartDate(startDate, endDate: endDate, calendars: [calendar])
21            
22            // Use the configured NSPredicate to find and return events in the store that match
23            self.events = eventStore.eventsMatchingPredicate(eventsPredicate).sort(){
24                (e1: EKEvent, e2: EKEvent) -> Bool in
25                return e1.startDate.compare(e2.startDate) == NSComparisonResult.OrderedAscending
26            }
27        }
28    }
29    // ...
30}

Context: View controller

The context of the above snippet is a view controller. Inside the view controller class, there’s a calendar instance that is presumably set in the previous view controller’s prepareForSegue method. There’s also an optional array of EKEvent instances that acts as the data source for a table view, and a function called loadEvents in this view controller.

Configure start and end dates

The first few lines of code within the loadEvents function are to facilitate configuring a start and end date to use for querying the event store.

Use the event store to generate NSPredicate

To actually query the store, you need to create an NSPredicate instance. However, rather than calling NSPredicate's initializer, you will use an EKEventStore instance to generate a predicate. Apparently there’s some under-the-hood work that goes on to get a properly configured NSPredicate instance to use in your query.

So assuming you’ve got a valid start date, end date (both NSDate instances), and one or more calendars to search for events within, you’ll use the event store’s predicateForEventsWithStartDate(_: endDate: calendars:) method to get an NSPredicate instance.

Query the event store with generated NSPredicate

The last step is to call eventsMatchingPredicate(_:) on the event store, and use the predicate you just generated. You can optionally sort them, as I’ve done in the snippet.

Wrapping up

That’s the meat of querying the event store for a list of events. To learn how display them in a table view, I would recommend going ahead and grabbing the example project that I’ve provided. I’ve also got a couple of guides on working with table views if you need assistance with that part:

Table View Guides

You might also enjoy…

Adding Buttons to the Navigation Bar with Storyboards

Thu, 14 Apr 2016 18:20:41 +0000

Updated on March 20, 2017 – Xcode 8 & Swift 3

If you’re having trouble figuring out how to add buttons to the navigation bar in your Storyboard-based iOS app, my goal in this article is to help you through the process. Knowing what to click and where to drag to get things wired up isn’t entirely intuitive, so I want to be of help if I can.

Lots of StackOverflow posts point us to just adding the buttons in code, but for those who lean toward trying to do as much in the Storyboard designer as possible, this approach feels out of place.

The example I’m outlining here is done solely in the Storyboard.

Example scenario

The scenario is as follows:

We have a main screen with an add button in the top right of the navigation bar
Pressing Add will display a modal screen with two buttons in the navigation bar: Cancel, and Save

The Goal: Use only the Storyboard to add the ‘Add’ button, and the Cancel and Save buttons to the navigation bar. The end result will be something like this:

An example git repository has been created for this walk-through over at GitHub:

Resources

Storyboard Navigation Controller Example

Main Storyboard scene setup

The very first thing you need to do in order to get the add button to show up in the navigation bar is to embed your view controller in a navigation controller.

Select your view controller and choose Editor > Embed In > Navigation Controller:

Next, you need to search for a Bar Button Item from the Object Library in the Utilities Pane. Once you find it in the list, drag one up to the upper-right of the navigation bar:

To turn it from an “Item” button into a “+” button, you need to adjust the Bar Button Item’s attributes. Click on the button, either in the navigation bar itself or on the document outline for the Storyboard, and choose the Attributes Inspector for the control.

Then change the System Item property from “Custom” to “Add”:

That’s all there is to setting up that first scene. You’ll wire up the add button to modally show the “Add” scene in the next section.

Add Storyboard scene setup

Next up, you need an “Add” scene. For that, another View Controller is required. Drag out a new View Controller onto the Storyboard design surface. While you’re at it, go ahead and create a new AddScreenViewController class:

Once you’ve created a new AddScreenViewController class from the File > New > File dialog, make sure you’ve wired it up appropriately:

Now, to get this “Add” screen to show modally, you need to control + drag from the “plus (+)” button on the first view controller, over to the new AddScreenViewController you just dragged onto the Storyboard. Select “Present Modally” from the popover:

Now, the problem you’ll run into at this point if you run the app is that, while tapping the ‘Add’ (+) button does in fact present the Add screen modally, 1) There’s no way to dismiss the modal controller to go back to the main screen, and 2) There’s no navigation bar to add buttons to!

So, the trick to get a navigation bar in place so that you can add our ‘Cancel’ and ‘Save’ buttons is to embed the Add Screen View Controller in… you guessed it… a Navigation Controller:

Once this is done, your storyboard should look something like this:

Now all that’s left to do is to drag two Bar Button Items up to the navigation bar, just like we did for the “Plus” (+) button on the main screen:

Changing each of their System Item properties in the Attribute Inspector, just like we did before, will give them their “Cancel” and “Save” appearance:

If you control + drag the ‘Cancel’ and ‘Save’ buttons from the Storyboard scene to the .swift code file, you’ll be able to wire up IBActions to dismiss the view controller and return to the main screen. I won’t explain that step here, since the goal was to show you how to add the buttons themselves, but the example project on GitHub has the view controller dismissal implemented if you care to review it.

Wrapping up

That’s it! Buttons in the navigation bar, all done inside the Storyboard.

Hopefully this quick walk-through removes any stumbling blocks you might have in designing your Storyboard-based app with navigation controllers.

Swift Functions as Types

Fri, 18 Mar 2016 18:11:02 +0000

For the well-versed functional programmer, the fact that [functions in Swift are Types][1] is no surprise. But I’m relatively new to the game on that front, so when I first encountered the idea of thinking of a function as a Type back when Swift was announced in 2014, it was a real eye-opener for me.

Swift Types (in general)

In order to understand functions as Types, it’s probably a good idea to know what folks are talking about when they use the term “Type” in a general sense.

In Swift, we’ve got two kinds of Types when we talk about them generally:

Named Types
Compound Types

Named Types

Named Types are those which are defined and identified by the name that they’re given. Classes, structs, enums, and protocols fit this category of Type.

To define a Named Type, you’d do something like this:

1class SomeNewClassType {}
2
3struct SomeNewStructType {}
4
5enum SomeNewEnumType {}
6
7protocol SomeNewProtocolType {}

Initializing instances of Types and using their properties and methods, passing them around to functions that require parameters of those Types, or setting them as values to properties of other Types are all pretty standard thoughts that come to mind when using named Types.

Compound Types

Compound Types, on the other hand, don’t have names. Rather, they have “signatures” that define and identify them as Types. Swift has two compound Types: functions and tuples.

Now I know what you might be thinking: “Functions have names!”

Indeed many do. But when we’re thinking about them in terms of their Type-ness, we’ve got to go beyond the name to the function’s “signature” characteristics.

The name of a function (or tuple, since they can be type-aliased) is simply how we refer to the function in code to execute it or pass it around as an argument.

The “signature” of the function, however, is the part that characterizes the function as a Type.

I want to analyze what I’m talking about when I refer to a function’s “signature”, because that really is as the heart of my goal for this blog entry…

Function Types

What exactly makes up a function’s Type-ness or “signature” as I’ve been calling it? Two things:

The Type(s) of its parameters
The Type that the function returns

Combining the Type(s) that the function receives as inputs, and the Type that it returns composes to give the function its Type / “signature”.

Reading a function’s Type

It always helps me to visualize, so take apart an example.

If you’ve lived long on the Internet, you’re bound to have run across a Star Wars name generator… Plug in your name, and maybe a birth year, and out comes some crazy “Star Wars name” for you.

The function definition (minus the body) might look like this:

1func generateStarWarsName(firstName: String, lastName: String, birthYear: Int) -> String { 
2    // ... 
3}

If someone were to ask you, “What is the generateStarWarsName function’s Type?”, you could answer: “generateStarWarsName is a function Type that has three parameters, the first two of Type String, the last of Type Int, and that returns a value of Type String.”

Wordy? Yes. But it does explain in precise terms what the function’s Type is.

Function Type notation

Rather than write out the paragraph describing the function’s Type, it’s far more convenient to indicate a the Type of a function using a standard notation. This notation is also the syntax that the Swift compiler uses when it’s trying to work with function Types.

Essentially, it boils down to stripping away the function’s name and the parameter names to leave behind the raw Type information that composes to give the function its Type.

Given the above generateStarWarsName function, we could notate its Type as follows:

(String, String, Int) -> String

See how that works?

Remove “generateStarWarsName”, “firstName: “, “lastName: “, and “birthYear: ” and you’re left with that raw Type information. What remains is the function’s Type notation.

It tells you (and the Swift compiler) everything you need to know to be able identify the Type of that function… it’s “signature”, if you will.

Gotchas

A couple of gotchas when it comes to notating a function’s Type:

1 – If a function takes no parameters, the “parameter portion” of the Type notation will simply be () with nothing between the parentheses.

So for example, the Type notation of
func returnHelloString() -> String {}
is () -> String.

2 – If a function has no return type (ie, it doesn’t return anything), the “return type portion” of the Type notation will be -> Void.

So for example, the Type notation of
func sayHello() {}
is () -> Void, since it takes no parameters, and returns nothing.

Practice

Here are a few more examples for you to practice function Type identification. Can you write out the correct notation for each function’s Type?

1func complimentMe(name: String) -> String { 
2    // ... 
3}

Show answer

`(String) -> String`

1func countToTen() { 
2    // ... prints 1 to 10 to the console ...
3}

Show answer

`() -> Void`

Notice that while `countToTen` doesn't have the "-> Void” in its definition, it is listed in the function's Type notation for clarity.

When you read this function's Type, you'd say, "This is a function Type which takes no parameters and returns Void.”

1func addInts(first: Int, second: Int) -> Int { 
2    // ... 
3}

Show answer

`(Int, Int) -> Int`

1func fadeIn(duration: NSTimeInterval, delay: NSTimeInterval, completion: (Bool) -> Void){ 
2    // ... 
3}

Show answer

`(NSTimeInterval, NSTimeInterval, (Bool) -> Void)) -> Void`

This one's actually a more complicated "compound Type” – note the third parameter which indicates that `fadeIn` receives a function Type as one of its inputs. Remember that since functions are Types, they carry the characteristic of being able to be passed around to other functions as parameters, or stored in variables/constants!

<p>
</p>

```swift

func increment(input: Int) -> Int { return input + 1 }

func decrement(input: Int) -> Int { return input - 1 }

func chooseAdjustmentFunction(increase: Bool) -> (Int) -> Int { return increase ? increment : decrement }

    
    <p>
      <a id="show-answer-5" style="cursor: pointer;">Show answer</a>
    </p>
    
    <div id="answer-5" style="display: none;">
      increment: `(Int) -> Int`<br /> decrement: `(Int) -> Int`</p> 
      
      <p>
        chooseAdjustmentFunction(_:): `(Bool) -> (Int) -> Int`
      </p>
      
      <p>
        This one's complicated in a slightly different way. This time, it's the return Type of the function that's kind of crazy.
      </p>
      
      <p>
        Read this as, "A function Type which takes as Bool as a parameter and returns a function Type which takes an Int as a parameter and returns an Int.&#8221;
      </p>
      
      <p>
        You can see how the Types of the `increment` and `decrement` functions <em>match</em> the return Type of the `chooseAdjustmentFunction` function. </div> 
        
        <h1>
          Wrapping up
        </h1>
        
        <p>
          Knowing that functions are Types in Swift is a powerful thing. Being able to correctly articulate the Type of a function, and produce its notation in valid Swift syntax is even <em>more</em> powerful, because it's at that point when you'll be able to recognize which kinds of functions are valid to pass as parameters to <em>other</em> functions, or to assign as properties of other Types. It can also play a role in Swift's pattern matching features. But alas, those topics for another day!
        </p>
        
        <p>
          <a name="related" class="jump-target"></a>
        </p>
        
        <div class="resources">
          <div class="resources-header">
            You might also enjoy&#8230;
          </div>
          
          <ul class="resources-content">
            <li>
              <i class="fa fa-angle-right"></i> <a href="https://www.andrewcbancroft.com/2015/01/06/immutable-types-changing-state-swift/" title="Immutable Types with Changing State in Swift">Immutable Types with Changing State in Swift</a>
            </li>
            <li>
              <i class="fa fa-angle-right"></i> <a href="https://www.andrewcbancroft.com/2015/01/20/conveniently-transforming-immutable-types-swift/" title="Conveniently Transforming Immutable Types in Swift">Conveniently Transforming Immutable Types in Swift</a>
            </li>
          </ul>
        </div>
        
        <p>
          <a name="share" class="jump-target"></a>
        </p>
        
        <p>
        </p>

 [1]: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html#//apple_ref/doc/uid/TP40014097-CH10-ID158

Fade Views In/Out with Fadeable – A Swift Protocol Extension

Mon, 22 Feb 2016 19:07:27 +0000

During the production of my Pluralsight course on Managing Xcode Project Dependencies with CocoaPods, I wanted to provide viewers of the course the opportunity to see how to create and deploy a simple library out to the CocoaPods Trunk.

Inspiration

A simple idea came to mind: Create something that allows client developers of the pod to easily fade views in or out on any UIView instance. If you’ve read andrewcbancroft.com for a long time, you might remember that I wrote on this very subject already, but there, I used an extension to UIView, because protocol extensions hadn’t been invented yet!

For my course, I borrowed an idea that I first saw done by @NSFlexMonkey when he built the Rotateable protocol extension. Only instead of rotating, I’m fading, so I named it “Fadeable”!

Demo

Fadeable code sample

The “library’s” source can be found over at GitHub:

Resources

Fadeable

Here’s a snippet from the repository so you can see what the extension’s doing:

 1import UIKit
 2
 3public protocol Fadeable {
 4    var alpha: CGFloat {get set}
 5    
 6    mutating func fadeIn(duration: NSTimeInterval, delay: NSTimeInterval, completion: (Bool) -> Void)
 7    mutating func fadeOut(duration: NSTimeInterval, delay: NSTimeInterval, completion: (Bool) -> Void)
 8}
 9
10public extension Fadeable {
11    public mutating func fadeIn(duration: NSTimeInterval = 1.0, delay: NSTimeInterval = 0.0, completion: ((Bool) -> Void) = {(finished: Bool) -> Void in}) {
12        UIView.animateWithDuration(duration, delay: delay, options: UIViewAnimationOptions.CurveEaseOut, animations: {
13            self.alpha = 1.0
14            }, completion: completion)  }
15    
16    public mutating func fadeOut(duration: NSTimeInterval = 1.0, delay: NSTimeInterval = 0.0, completion: (Bool) -> Void = {(finished: Bool) -> Void in}) {
17        UIView.animateWithDuration(duration, delay: delay, options: UIViewAnimationOptions.CurveEaseOut, animations: {
18            self.alpha = 0.0
19            }, completion: completion)
20    }
21}
22
23extension UIView: Fadeable {}

In the code snippet above, I define the Fadeable protocol as [Some Type] that has an alpha property, and a fadeIn() and fadeOut() function.

Then I create an extension to the Fadeable protocol and provide a simple, default implementation which will animate the alpha to 0, or to 1, depending on whether or not the client developer is fading in or out.

Finally, I extend UIView to conform to Fadeable. And that’s it! Any UIView instance can now fade in or out by simply calling the appropriate function:

 1class ViewController: UIViewController {
 2    
 3    @IBOutlet weak var box: UIView!
 4    
 5    // ... Omitted for brevity   
 6
 7    // The storyboard has a button that can be tapped to toggle the fade action
 8    @IBAction func fadeToggleTapped(sender: UIButton) {
 9        if(box.alpha == 0) {
10            box.fadeIn()
11        } else {
12            box.fadeOut()
13        }
14    }
15}

Creating CocoaPod libraries

If you’re interested in seeing a full walk-through of how I created and published the Fadeable Library to the CocoaPods Trunk, I would love it if you gave Module 3 of my Pluralsight course, titled a watch! It’s titled Creating CocoaPod Libraries and covers from beginning to end, the process of creating a library that’s compatible with CocoaPods.

You might also enjoy…

Fundamentals of Callbacks for Swift Developers

Mon, 15 Feb 2016 18:21:33 +0000

Updated on October 12, 2016 – Swift 3.0

Callbacks: What are they? How do they work? What are they used for in practice?

My goal in this article is to provide answers to these questions so that you have a foundational understanding of this common programming pattern in iOS development.

What are callbacks?

Let’s approach the definition from a “big picture” scenario:

When we’re building software, we’re either using APIs, or building APIs, are we not? We’re either using code that “hooks into” what other developers have designed and made available to us, or we’re creating code that other code will “hook into” and interact with, even if the “other code” is written by us in our own app.

Learn by example: Designing an API for callbacks

Since this is the case, let’s put on the “API Designer” hat for a moment and suppose that we’re working to create a hypothetical Type called an ImageSketcher. One of the functions of ImageSketcher is called sketch() (parameters omitted for the moment). It will allow developers to pass it an image resource, such as a JPEG or a PNG, as one of its arguments. The function will then proceed to generate an animated sketch of that PNG for the user to view.

In order to do the work of generating the animated sketch, sketch() needs to do a lot of crunching. I have no idea what it’d take to do this in real life, honestly – let’s just work on the premise that it’ll take a few seconds to generate the animation so the end-user can watch it when it’s finished.

In situations like this, it’d be nice to design ImageSketcher where the start and end of the process are decoupled:

Pass off the image. Let it do its thing to generate the animation. When it’s finished, “hook back in” and respond to the knowledge that the animation generation is complete. At that point, we could ask the end-user, “Hey, your sketch is done! Want to watch it now?”

This particular example centers on a strategy that uses “asynchronous programming” techniques. It’s often done to boost app performance and/or responsiveness.

During that middle part where we’re “disconnected” from the ImageSketcher's sketch() function, control of the app wouldn’t be tied up. Folks could continue to interact with the app.

From a developer’s point of view, he/she can program against the API by calling the function, knowing that at [some unknown point in the future], it will finish, and that he/she will have the opportunity at that time to “hook back in” and respond to that completion event.

That last bit is critical. Giving other developers the opportunity to re-insert themselves with custom application logic when the asynchronous task ends is very important as an API designer.

Exactly what you as an API designer communicate back to the caller of your API is up to you, but put yourself in the client developer’s shoes for a moment:

Wouldn’t it be nice to know if something went wrong, or if data (the completed animation, for example) came out of that sketch()'s work? That’s exactly the kind of information that we’d expect an API designer would provide us with this completion event.

So… just what are the options could we give callers of this method to “hook-in” and know that the work is done?

“Hook-in” options

In scenarios like this, Swift developers have about 3 options to choose from:

Use NSNotificationCenter to alert “subscribers” that the sketch() function has completed its job. I wrote about this option in Fundamentals of NSNotificationCenter in Swift
Use the delegate pattern to create a contract between the ImageSketcher and the caller of the sketch() function. When sketch() has completed its task, the appropriate delegate method will be called. I wrote about this works in How Delegation Works – A Swift Developer’s Guide
Use a callback

So callbacks are used as another way for one piece of code to communicate with another piece of code somewhere else in the app.

How do callbacks work?

Here is a brief overview of the communication interaction using our hypothetical ImageSketcher as a working example:

An API designer has created the sketch(image:completion:) function, and has chosen to accept a completion “callback” as the means of communicating the fact that the animation has been generated and is ready to show the end-user.
Data, such as the completed sketch animation instance will be delivered through the completion callback’s parameter(s). The completion parameter of our sketch() function will have a signature that client developers must adhere to in order to facilitate the delivery of that data.
A client developer writes up a routine (a function or closure) and passes it as the completion parameter’s argument. The function/closure that he/she writes will have a list of parameters that matches up to what the API designer required.
When sketch() is finished generating the sketch, the designer of the API has programmed his/her function to call the callback that you pass in. The API designer will pass along any data that was generated as arguments to the callback function’s parameters.
The client developer’s callback logic executes.

Callbacks are functions that often take the form of a closure (basically an in-line function with no name that’s passed as a parameter to another function), but they could technically be a named function.

Perhaps it’s easiest to see in code itself. Here’s a skeleton view of what that looks like:

 1// API Designer World
 2struct SketchAnimation {
 3    // represents some fully-generated animation that's ready to play by the end user
 4}
 5
 6struct ImageSketcher {
 7    func sketch(image: UIImage, completion: (_ sketchAnimation: SketchAnimation) -> Void) {
 8        // do some crunching to create the SketchAnimation instance...
 9        let animation = SketchAnimation()
10        
11        // invoke the completion callback
12        // pass along the completed sketch animation instance
13        completion(animation)
14    }
15}
16
17// ---------------------------------------------------------------------
18
19// Client Developer World
20class MainViewController: UIViewController {
21    // ...
22    
23    // end-user interacts with the app somehow to create an image sketch animation
24    // when they do, this function is called...
25    func createSketchAnimation(imageToSketch: UIImage) {
26        let sketcher = ImageSketcher()
27        
28        sketcher.sketch(image: imageToSketch, completion: {(animation: SketchAnimation) -> Void in
29            // This is the callback.  It's a closure, passed as the argument to the sketch function's completion parameter
30            
31            // Ask the end-user if they'd like to view the completed animation now...
32            // You as a develoepr have access to the completed animation through the animation parameter to this closure
33        })
34    }
35    
36    // ...
37}

You’ll notice a couple of things…

First, I’ve separated the two “worlds” that exist: “API Designer World” and “Client Developer World”. Hopefully seeing both in action can give you the most complete picture of what’s going on with callbacks.

In “API Designer World”, we’ve got the ImageSketcher and its implementation.

In “Client Developer World”, we’ve got someone using an instance of ImageSketcher.

Second, notice the interaction. As an API designer, I was thinking, “Hey, when my sketching process is complete, I want to let the caller know that it’s finished and hand them the completed SketchAnimation instance. To do that, I’ll need them to pass me a function that I can hand it off to via a parameter”.

As a client developer, I’m thinking, “Okay, I’m going to call sketch(), but how am I going to know when it’s done and how will I get the animation? Oh! I see – I need to give it a completion closure (a callback), and they’ll hand me the completed SketchAnimation instance through my closure’s parameter. Sweet!”

I’m hoping the “thinking out loud” here helps you piece it together.

Examples from the iOS SDK

So how about a few real examples, say, from the iOS SDK. Where are callbacks used there?

UIAlertController

A really simple example of callbacks being used in the wild is when we work with UIAlertControllers. Take a look at this example:

 1let alertController = UIAlertController(title: "My Alert", message: "A Message", preferredStyle: UIAlertControllerStyle.alert)
 2
 3let OKAction = UIAlertAction(title: "OK", style: UIAlertActionStyle.default, handler: {(action: UIAlertAction) -> Void in
 4    // Do something based on the user tapping this action button
 5    
 6    // Notice that we get an instance of the UIAlertAction that was tapped if we need it
 7})
 8
 9alertController.addAction(OKAction)
10
11self.present(alertController, animated: true, completion: nil)
12// We could have provided a completion callback here, too,
13// but we didn't need to respond to the view controller's presentation, so we passed nil

So the UIAlertAction is actually the thing that takes the callback (the handler parameter). There’s also an example on a View Controller’s present() function. Both are intended to communicate something back to the caller.

In the case of the UIAlertAction, the handler will be the logic to handle the user’s tapping on that specific alert button.

In the case of the present call, Apple has given us the opportunity to “hook in” to the presentation event and know when it’s complete, in case we need to perform additional logic at that moment.

URLSession

The world of HTTP is inherently asynchronous, so you’d expect to see some kind of pattern employed to deal with the “disconnectedness” of the start and finish of a process, such as making an HTTP request.

URLSession encapsulates certain HTTP actions, such as retrieving the contents of a URL, in instances called URLSessionDataTask. How does it communicate the fact that the HTTP request is complete, along with the data contained in the response? You guessed it: A callback.

Take a look at this function signature from the Apple Developer Documentation on URLSession:

1func dataTask(with url: URL, 
2              completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTask

The completionHandler parameter of this function is the interface that the API designers have created for delivering the resulting payload of the HTTP request when it’s finished and ready to hand off for further processing.

Client developers of this API will be expected to make the call to dataTask(with:completionHandler:) and supply it a completion callback to know when things are complete.

Animations

You’ll see all kinds of completion callbacks sprinkled throughout some of the simpler iOS animation APIs.

If you take a look at the following function signatures from the Apple Developer Documentation on UIViews, you’ll see the completion parameters to many of these functions:

1transition(with:duration:options:animations:completion:)
2transition(from:to:duration:options:completion:)
3animateKeyframes(withDuration:delay:options:animations:completion:)
4addKeyframe(withRelativeStartTime:relativeDuration:animations:)
5perform(_:on:options:animations:completion:)
6animate(withDuration:delay:usingSpringWithDamping:initialSpringVelocity:options:animations:completion:)

Wrapping Up

Believe it or not, the usage of callbacks is one of the less-complicated ways of communicating between parts of code.

My goal in this article was to show all of the sides and perspectives and players to give you insight into how this communication takes place.

Now that the foundations are laid, it is my hope that you’ll be able to more confidently use callbacks and know what’s happening as you encounter them in your Swift code!

You might also enjoy…

Managing Xcode Project Dependencies with CocoaPods

Wed, 03 Feb 2016 18:23:49 +0000

Course Outline

I try to get as practical as possible in the course. As you’re watching you’ll be “embedded” into a team of iOS developers, and you’ll explore the problems that CocoaPods can solve for you by watching the team struggle through not having a dependency manager, and then sharing in their victories as they bring in CocoaPods to ease that dependency management struggle.

The course is a progressive journey. First, the team has problems managing dependencies without a dependency manager. Then, they bring in CocoaPods to help them find and organize 3rd party libraries. Then, they start to think, “Hey, what if we could create our own CocoaPod libraries?”. Finally, they use that knowledge of how to create a CocoaPod library to set up a private repository to share code internally between projects with their team.

I’ve got four modules that cover the following topics:

1 - Introducing Project Dependency Management

I teach the basic concepts and definitions associated with “project dependency management”. What is it all about? Why does it matter? And most importantly, how is it done in the Apple Ecosystem?

2 - Managing Dependencies with CocoaPods

I guide you through installing CocoaPods, configuring your Xcode project to use CocoaPods, and working with the CocoaPods command line utility.

3 - Creating CocoaPod Libraries

This is where things turned really fun for me. :] In this module of the course, I teach you how to create a CocoaPod library, host its source code on GitHub, and publish the library to the CocoaPods Trunk.

4 - Hosting a Private CocoaPods Repository

As the capstone to the course, I teach you how to set up a private spec repository and how to configure CocoaPods to utilize it. It really is the culmination of everything learned in the prior modules, but it’s also one of the most practical strategies for sharing code between your various Xcode projects that I’ve found to-date.

In addition to the four modules of content, the course comes with an example Swift iOS app if you’re a Pluralsight Plus subscriber!

Something for Everyone

The course is targeted at beginning to intermediate level developers. I assume no prior knowledge of how to work with a dependency manager.

That being the case, I do my best to offer something for everyone. If you’ve never used a dependency manager on another platform before, I’ve got you covered – I’ll take you step by step through using CocoaPods.

If you’re already using CocoaPods in your Xcode project, maybe you can benefit from the modules on creating CocoaPod libraries yourself! If you’re already creating libraries and contributing to the open source community, what about setting up that private spec repository to share with your team internally?

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Swift Framework Woes – Unresolved Identifier? No Member?

Fri, 08 Jan 2016 18:40:55 +0000

It’s the simple things that get us, isn’t it?

I was working on a simple little framework the other day, and I’d gotten things just how I wanted… or so I thought.

I was ready to test things out and import the framework into my real app.

import MyShinyNewFramework

Sweet! No build errors!

// attempt to use things defined in the framework

Not so sweet…

Use of unresolved identifier ‘…'

Value of type ‘…’ has no member ‘…'

I scrunched my forehead, puzzled, and immediately it came to me.

public public public all the things! Or at least, the things that others need to use from the framework. :]

Of course a framework’s usable API needs to be public, but I write far more code that doesn’t require thought of access control modifiers than code that does, so there’s always that initial head-scratching that happens when you’re to the point of testing and go, “WHAT?? Why is this not working??!”

Key Takeaway

Whenever you’re developing code (such as a framework) that’s intended to be used from the perspective of another Swift module, you need to include public before Types and functions that are intended to be “seen” and called from that other module. Otherwise, you’ll get those same fun compiler errors and join me in saying to yourself, “Doh! Yep… public… again.”

Working with Unwind Segues Programmatically in Swift

Fri, 18 Dec 2015 18:22:55 +0000

Updated on September 20, 2016 – Xcode 8 & Swift 3.0

Navigating between screens is a critical component to building iOS applications. The mechanism for navigation in Storyboard-based applications is the segue. Using segues, we can travel ahead to the next screen, which is extremely common. We can also travel backward in the screen “navigation stack” by programming a special kind of segue called an unwind segue.

Embedding a view controller inside a navigation controller gives us some built-in forward and backward navigation, so you may be asking, “What’s the need for an unwind segue??”

Well, suppose that we need to programmatically trigger the backward navigation, based on an interaction with something other than the default “back” button on the navigation bar. How would you do it? Yep – you’ve got it: by using an unwind segue.

This is a walk-through of how to work with unwind segues programmatically in Swift.

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

Example

An example app called “Roasters on the Go” has been created for this walk-through to help give you some context. It’s a mock mobile order system for purchasing green, un-roasted coffee beans (so that you can roast them yourself)!

Resources

RoasterOnTheGo Example Project (Swift 2.3 | Swift 3.0)

We’ll start at a list of coffees categorized by region
Tapping an coffee origin country will take you to the order screen
Pressing the ‘Order Now’ button will simulate the placement of an order
Tapping “OK” on the alert will trigger the unwind segue (which is the goal of this walk-through)

Here’s a sample of what the fake app does:

The goal is to go back to the list of coffee origins after ‘OK’ is pressed on the alert. Let’s look at the steps to make this happen.

1 – Create an unwindTo___ IBAction

The first step is to create an IBAction that we can wire up the unwind segue to.

Supposing that you’ve got two view controller: The MenuViewController which lists out the menu of coffees to purchase, and the OrderViewController which allows your app users to buy that particular coffee.

If we’re wanting to go from OrderViewController to MenuViewController, we need to create the IBAction in the MenuViewController:

1class MenuViewController: UITableViewController {
2    
3    // ...
4    
5    @IBAction func unwindToMenu(segue: UIStoryboardSegue) {}
6    
7    // ...
8}

Placing the IBAction code in the right spot is critical to the functioning of the unwind segue. In this example where we want to go from Order to Menu, if you place the IBAction in the OrderViewController, the Storyboard will let you wire it up just fine, but the transition back to the menu screen will never happen at runtime.

Therefore, it’s important to remember: Place the “unwindTo___” IBAction function in the view controller source file for the screen you’re unwinding back to.

2 – Wire up the unwind segue

Next up is to wire connect the view controller to the unwind segue IBAction that we just created.

Here, you’re going to be looking at the screen that you’re going to unwind from. In the running example, this will be the Order View Controller’s scene in the Storyboard.

To wire up the OrderViewController to its unwind segue, you need to right-click and drag (or control + drag) from the View Controller icon to the Exit icon in the Storyboard Scene:

You’ll be presented with list of IBActions to connect to. You’ll choose the unwind segue action that was created in step 1:

3 – Specify a segue identifier

For this step, you’ll want to make sure that the Document Outline of the Storyboard is expanded. This will allow you to easily select the unwind segue in the outline, and specify its identifier in the Attributes Inspector of the Utilities Pane:

Since we want to take the user back to the menu when placing an order is finished, we’ll give it the identifier of “unwindToMenu”.

4 – Trigger unwind segue programmatically

The final step is to write a bit of code to trigger the unwind segue at the appropriate time.

In our example, we want to trigger it when the user taps on the ‘OK’ button of the alert. Here’s a snippet of code that will accomplish that task:

 1@IBAction func orderButtonTapped(_ sender: UIButton) {
 2    let alert = UIAlertController(title: "Order Placed!", message: "Thank you for your order.\nWe'll ship it to you soon!", preferredStyle: .alert)
 3    let OKAction = UIAlertAction(title: "OK", style: UIAlertActionStyle.default, handler: {
 4        (_)in
 5        self.performSegue(withIdentifier: "unwindToMenu", sender: self)
 6    })
 7    
 8    alert.addAction(OKAction)
 9    self.present(alert, animated: true, completion: nil)
10}

Wrapping up

Whenever you need to programmatically trigger backward navigation in your app, using an unwind segue can be a great feature to take advantage of. This walk-through took you step-by-step through working with unwind segues in Swift.

Get Social With Swift – Posting to Facebook and Twitter

Mon, 23 Nov 2015 19:17:38 +0000

Building social media features into our apps has never been easier! In this guide, I will walk you through how to get started with accessing the Social framework for iOS so that you can take advantage of Apple’s built-in support for two major social media platforms: Facebook, and Twitter.

For your convenience, I’ve created a simple GitHub repository with an example Xcode project to help you see all of this code in action:

Resources

SocialSwift Example Project

Note: To try things out in this guide you need to run your app on a physical device, because the Social media features we’re looking at below are not available in the iOS Simulator.

The first step is to import the Social module into your .swift file. It’s a simple declaration at the top of your file:

1// ...
2
3import UIKit
4import Social
5
6// ...

Checking service availability

Next up is to make sure that the user has Facebook, Twitter, or both set up on their device.

In the example that’s included with this guide, I will respond to a user’s tapping on a button in the UI to trigger the presentation of an SLComposeViewController instance (which we’ll configure shortly).

Within the body of the IBAction associated with the button, I will check whether or not the Facebook service is available:

1@IBAction func postToFacebookTapped(sender: UIButton) {
2    if(SLComposeViewController.isAvailableForServiceType(SLServiceTypeFacebook)) {
3        //...
4    }
5}

Service types

Currently there are 4 service types that represented by String constants in Swift. Passing one of the following into SLComposeViewController.isAvailableForServiceType(_:) will check for that service’s availability on the user’s device:

SLServiceTypeFacebook
SLServiceTypeTwitter
SLServiceTypeSinaWeibo
SLServiceTypeTencentWeibo

For the purposes of this guide, we’ll look at the first two, which map to Facebook and Twitter, respectively.

Note: Social media features in the Social module are not available for use/testing on the iOS Simulator, so you need to use a physical device to try things out.

Creating an SLComposeViewController

The Social framework comes with a Type that allows us to present some Apple-built UI to post to any of the four service types. To get at this out-of-the-box user interface, we look to SLComposeViewController's initializer that takes an argument for the type of service we’d like to create a post for:

1@IBAction func postToFacebookTapped(sender: UIButton) {
2    if(SLComposeViewController.isAvailableForServiceType(SLServiceTypeFacebook)) {
3        let socialController = SLComposeViewController(forServiceType: SLServiceTypeFacebook)
4
5        // ...
6    }
7}

In this code snippet, we’re creating an SLComposeViewController instance to post to Facebook, since I’ve specified the SLServiceTypeFacebook type to the initializer.

(optional) Configure the SLComposeViewController

Optionally, you can choose to pre-populate the “create post” UI with some initial text, an image, or a URL. Here’s a sample of what that might look like:

 1@IBAction func postToFacebookTapped(sender: UIButton) {
 2    if(SLComposeViewController.isAvailableForServiceType(SLServiceTypeFacebook)) {
 3        let socialController = SLComposeViewController(forServiceType: SLServiceTypeFacebook)
 4//            socialController.setInitialText("Hello World!")
 5//            socialController.addImage(someUIImageInstance)
 6//            socialController.addURL(someNSURLInstance)
 7        
 8        // ...
 9    }
10}

Present the SLComposeViewController

The last step is to present the controller!

 1@IBAction func postToFacebookTapped(sender: UIButton) {
 2    if(SLComposeViewController.isAvailableForServiceType(SLServiceTypeFacebook)) {
 3        let socialController = SLComposeViewController(forServiceType: SLServiceTypeFacebook)
 4//            socialController.setInitialText("Hello World!")
 5//            socialController.addImage(someUIImageInstance)
 6//            socialController.addURL(someNSURLInstance)
 7        
 8        self.presentViewController(socialController, animated: true, completion: nil)
 9    }
10}

If you need to perform an action when the user has finished their post (or cancelled the action), the completion closure is your opportunity to hook into that event and execute the code you need.

Wrapping up

As you can see, integrating social media sharing capability into your app has never been easier. Now, in this guide, I didn’t explicitly go over how to create posts for Twitter, but it’s as simple as switching SLServiceTypeFacebook to SLServiceTypeTwitter. The example I’ve provided with this guide does include code for Twitter, so feel free to download the full project over at GitHub!

Creating Trust-able Unit Tests in Swift

Wed, 04 Nov 2015 02:42:08 +0000

It may come as a surprise to you, but a green-lit passing unit test is not always a sign that all is well with our software. Our apps and their corresponding unit test suites always start off clean and basic and simple.

But they don’t stay that way for long.

Cycles of code changes and additions and re-writes take place throughout the days, weeks, and months of the application development cycle. The app’s code-base and unit tests become more complex as the end-product progresses along its asymptotic approach to completion.

Unit tests are only as good as they are trust-able. As our products navigate their way through development iterations, how can we keep a handle on the trustworthiness of our unit tests? How can we be assured that they’re testing the right thing? How can we know that changing a unit test because a fundamental requirement has changed is still accurate when it lights up green? After all, we’re writing code to test our code!

Here, I explore several categories of thought that will help you think about creating trust-able unit tests.

Test Organization

How you organize the code within a single unit test can make all the difference in understanding it when you return to it later.

Having a consistent strategy for organizing the body of a test function will save you time and effort in trying to understand what’s happening. Keeping things consistent across a team of developers will make everyone more productive as well.

Two of the most common organizational structures for unit tests are the “Arrange-Act-Assert (AAA)” and the “Given-When-Then” structures:

 1func testAppFeatureBehavior() {
 2    // Arrange
 3    let sut = SystemUnderTest()
 4    // configure properties as necessary to prepare the system for the next step
 5
 6    // Act
 7    sut.functionProducingObservableBehavior()
 8
 9    // Assert
10    XCTAssert(...expectations are met...)
11}

A similar pattern is the “Given-When-Then” structure:

 1func testAppFeatureBehavior() {
 2    // Given
 3    let sut = SystemUnderTest()
 4    // configure properties as necessary to prepare the system for the next step
 5
 6    // When
 7    sut.functionProducingObservableBehavior()
 8
 9    // Then
10    XCTAssert(...expectations are met...)
11}

They’re exactly the same structures with different descriptive comments outlining the three phases of the test.

The outline itself can help you look at the test and verify its trustworthiness as it pertains to its logical, clear order and organization.

Test Length

Another contributor to the trustworthiness of a given unit test is the number of lines of code it has.

It’s been said that a 100% guaranteed bug-free line of code is the line of code that was never written in the first place!

It makes sense that if we can keep our unit tests short and to the point, there will be a smaller chance for error than if the test body is extremely long.

Small (<20ish lines of code) tests are more-trusted than large tests.

20 lines of code is sort of arbitrary, but can help alert you to when you might need to re-look at the test and apply DRY (Don’t Repeat Yourself) principles. Large test bodies may be a sign that there’s a possible opportunity to factor out common, repeated test code.

Extracting out larger portions of code into smaller named functions may also help with the clarity of your unit test code, leading you to say with greater confidence, “I trust that this test is correct”.

Test Complexity

Unit tests should be as simple as possible. Reducing the complexity of a unit test results in clarity.

Make sure there’s a clear path through the test case.

Avoid branching logic (if-else statements) or looping constructs in your tests if at all possible. If you find the need to test two code paths of your system under test, write two tests for that, rather than applying if-else logic inside of a single unit test.

If you’re using analytics, such as cyclomatic complexity, absolutely make sure your unit tests have as low of a cyclomatic complexity as possible.

Test Semantics

Applying simple clean coding practices to your unit tests can also go a long way in terms of being able to trust your tests.

Use descriptive and meaningful phrases (DAMP) in your test names and variables. Be sure to update them as the semantics of your system under test change. This will provide a consistency and accuracy to the names of things that will lead to a greater confidence that your tests are giving you an accurate picture of the health of your system.

You might also enjoy…

Considerations for Choosing 3rd Party Swift Libraries

Tue, 27 Oct 2015 18:04:09 +0000

While relying on 3rd party dependencies can provide you the benefit of not having to spend time implementing a portion of your app, realize that you’re essentially giving away little pieces of your app when you bring in a dependency.

You’re delegating away a certain level of control off to someone else who has no knowledge of or interest in the final outcome of your team’s app.

Adding dependencies to your project doesn’t come without cost, so it’s best to count that cost up front in order to make sure it’s a good idea to pursue this option.

If you are going to seek out modules of code from a 3rd party, what are some key assessment factors that could help you in this important decision?

Josh Brown wrote a really comprehensive list of questions that guided me a lot in my own considerations of choosing a 3rd party library. I’m really grateful for his article – if you’ haven’t read it, go check it out!

My own list that follows takes a more categorical approach for those of us who think in box-like structures. I thought of at least four broad categories that we should think about and ask questions about when it comes to choosing our dependencies.

How can you avoid depending on bad Swift libraries? What are some markers of good ones? Let’s find out!

Community matters

A good library has a good community surrounding it. Try using your favorite search engine to see what kind of content comes up for the dependency you’re thinking about. Search on StackOverflow to see what questions are being asked and what issues folks are running into, and what kinds of answers (if any) are being given.
Take a look at the GitHub stars and forks counts. Stars are a good way for developers to flag repositories that are interesting to them. Forks indicate potential contributors to the repository, since the typical flow is to fork the project, branch, publish the branch, and submit a pull request.
“Buzz” and “popularity” can come and go, but if folks are talking about the dependency you’re considering, that’s not a terrible sign. Unless what they’re talking about all the problems the library has, haha. In all seriousness, though, utilize social media and observe / ask around to see what other developers are saying about it before bringing it into your app.

Maintenance matters

When was the last commit to the repository? If it was 5 years ago, this could be a red flag. Sure, it could just mean that the library is “done” and works great. But you and I both know that as the world of software moves forward, change is inevitable, and a library that doesn’t change with the times is more than likely doomed to failure. Checking the pulse of the repository on GitHub is one way to determine how well-maintained the library is.
How many issues are open? How many are being closed as resolved? Repositories with a lot of issues open could indicate an active community… unless those issues never get closed. In which case the indicator is a less positive one. Once again, GitHub’s Pulse feature will be a good guide even on figuring out how the repository owner is responding to issues that come their way.

Documentation matters

If a library has no documentation to speak of, how are we as developers supposed to figure out how to use it? The better and more exhaustive the documentation, the better the chances are that the library is worth surviving the candidate list to incorporate into your project
Even better is when the repository owner provides examples of how to use their library. Seeing examples will give you an idea of what’s possible, how nice the API is, and is overall a good reference point for integrating it with your own app. Documentation without examples is less valuable than documentation with examples.

Quality matters

If you’re using CocoaPods, know that each CocoaPod that’s submitted to the central ‘Trunk’, as they call it, receives a quality index that is based on various pieces of analysis that can be done on the repository and on the code within the pod itself. Some of the analysis that’s done is based on some of the things I just discussed, such as GitHub stars, documentation, etc. A full list of how the CocoaPods quality index is assessed and assigned can be found at https://guides.cocoapods.org/making/quality-indexes

Wrapping up

So there you have it – a few broad categories to think in terms of when trying to get direction on whether or not you should bring a given 3rd party library into your own Swift project.

Do you have other “box-like” categories that you use to guide your dependency decisions? Feel free to sound off in the comments with your thoughts!

Testability Tip for Swift Developers – Parameterize and Push

Fri, 04 Sep 2015 18:36:52 +0000

In a previous “Testability Tip for Swift Developers”, I discussed the principle of observability. “If it’s observable, it’s testable” was the primary conclusion of the article, and I pointed toward using the public access control modifier for parts of your app that you intend to test.

In this edition, I’d like to introduce a new principle that I try to adhere to when I’m unit testing, namely, “If it’s controllable, it’s testable”. Here’s what I mean by “controllable”…

Controllability

In Testing is to Software as Experiment is to Science, I analyzed how testing software mirrors scientific experimentation. Good scientific experiments are controllable. That is, they are set up such that everything stays as constant as possible except the thing you’re poking at.

Changing multiple things at a time in an experiment clouds the ability to verify that [tweak x] produced [y outcome]. So a scientist will do his/her best to control the environment by holding as many variables constant as possible, so that he/she can make accurate conclusions about the outcome.

The same goes for testing software. If I’m going to automate a test, I want to set up my “experiment” such that I control as much of the system as possible so that I can set up valid expectations and verify results coming from the system under test. Note that I’m using the term “system” in a very broad sense – it could be referring to an entire app, a single “object”, or a function.

Parameterize and push

So where does “parameterize and push” come into play?

Parameterizing sets us up with the ability to provide inputs into the system we’re testing. Anytime you have an input, you have the ability to supply a value of your choosing.

Serving as inputs to the system, you can view parameters as entry points for controls. They’re “controls” because we decide what those values should be before we pass them off as arguments to those parameters. So long as the system we’re testing only gets the data it uses from its inputs (its parameters), we can be guaranteed predictable, controlled outputs on the other end.

Forms of parameterization

Three forms of parameterization are common:

At the instance level through initializers
At the instance level through property setters
At the function level through function parameters

Using an initializer, or a public variable property, or by adding parameters to your functions and using only those parameters for the function’s computation and output production, you give yourself the ability to control the system in various ways that are appropriate on a test-by-test basis.

Usefulness and examples of parameterization

Setting up your instance definitions to use a set of inputs from the very start through initialization gives you the ability to provide real “production-ready” values in your app, but fake “test-customized” values for testing. Creating fake objects for testing is outside the scope of this article, but providing public initializers with parameters is a really great way to set yourself up for being able to test that particular instance.

 1// Prefer
 2public class DatabaseCommunicator {
 3    let database: Database
 4    
 5    public init (database: Database) {
 6        self.database = database
 7        // able to supply a controlled input via parameter, such as supplying a 
 8        // customized "fake" database to use for testing but still supply a "real" database in real life
 9    }
10}
11
12// over
13public class DatabaseCommunicator {
14    let database = Database()
15    // stuck with talking to a real database...
16}

Another viable option is to provide public variable properties that can be set after the instance is initialized. This is a little more round-about, but I would still call it a form of “parameterization” because the strategy still provides you with the same control point that an initializer with parameters does.

 1// prefer
 2public class DatabaseCommunicator {
 3    public var database: Database
 4    // able to supply a controlled input via property setter, such as supplying a 
 5    // customized "fake" database to use for testing but still supply a "real" database in real life
 6    public init() { self.database = Database()}
 7}
 8
 9// over
10public class DatabaseCommunicator {
11    let database = Database()
12    // stuck with talking to a real database
13}

At the function level, the usefulness of parameters is that you can supply inputs and examine outputs with ease. If you pull in data from the encapsulating instance inside the function body, say by referencing self.somePropertyValue, you’ve got a bit more setup to do to be able to accurately verify results. somePropertyValue needs to actually have a value before the function will produce accurate results. If you’d opted to simply define parameters for everything the function needs in order to produce its output, you can test that function in isolation far more easily and be guaranteed that your results are correct and accurate.

 1// prefer
 2func getNameFromDatabase(database: Database) -> String {
 3    return database.getName()
 4    // able to supply a controlled input via parameter, such as supplying a 
 5    // customized "fake" database to use for testing but still supply a "real" database in real life
 6   
 7}
 8
 9// over
10func getNameFromDatabase() -> String {
11    let database = Database()
12    // stuck with talking to a real database
13    return database.getName()
14}
15
16// and over
17func getNameFromDatabase() -> String {
18    return self.database.getName()
19    // requires additional setting of the database property on 'self'
20    // before you're able to get results from this function
21}

Parameterization or “Dependency Injection”?

Yes.

What I’m calling “parameterization” is really just “dependency injection”. But the term “dependency injection” can sound really daunting, while we’re used to working with parameters. I intend for the meaning of each term for the purpose of this article to be equivalent.

Wrapping up

Parameterizing, your instance definitions and functions provides you an immense amount of leverage when it comes to controlling your system under test. I encourage you to try this out and do your best to shift to a more parameterized approach to writing your code for improved testability. Remember, “Controllable is testable”!

You might also enjoy…

Testability Tip for Swift Developers – Public Over Private

Sharing a Core Data Model with a Swift Framework

Wed, 26 Aug 2015 04:04:05 +0000

Updated on June 13, 2017 – Swift 3.0, Xcode 8

Code re-use is a powerful thing, but it’s not always easy to pull off. We strive for it though, because in the long run, it makes maintaining the code far, far easier than if we just settled for copying and pasting.

With the introduction of dynamic frameworks in iOS 8, a world of possibility opened up for iOS developers to achieve some pretty cool re-use scenarios, one of which we’re going to dive into today.

Not only can we share code between projects, we can also share Core Data models between projects by utilizing frameworks!

Perhaps you’re working on an iOS + Mac app combination and the data model for each is identical. Maybe you’re building several iOS apps that have different user interfaces but share some underlying persistence-layer models. Whatever the case may be, wouldn’t it be awesome to design the Core Data model once and share it between your projects?

Example scenario

Our working example for this walkthrough will be the following:

Our team is building an iOS app and a Mac app and the underlying data model will be exactly the same between them. The only difference between the apps will be the target platform.

The app will target car enthusiasts everywhere – we will empower car fanatics to manage of a list of their favorite cars.

We’ll be creating two Xcode projects during this walkthrough: One will be the framework and will be called “CarKit”. The other will be a single view iOS application. We won’t actually dive into the Mac project, but one could imagine the process being very similar for importing CarKit into the Mac application when it came time to build that one.

I’m providing a completed CarKit + Carz package for you to look at over at GitHub:

Resources

CarKit + Carz Core Data Framework Example

Let’s get started!

Creating a Swift framework project

To get started with creating a Swift framework, begin with Xcode’s New Project dialog (File -> New -> Project…). Typically we stay in the realm of the “iOS Application” project templates, but if you click “Framework & library”, you’ll see the option to create a new Cocoa Touch Framework:

In keeping with Apple’s “___Kit” theme, we’ll name our framework “CarKit”:

Add a data model file

Once the framework project has been created, we’re set to drop in a new Data Model file from Xcode’s new file dialog (File -> New -> File…). Choose Core Data, and then Data Model:

Give the data model file a name that seems to fit your situation. For our example, let’s name it “CarModel”:

Add model attributes

Next it’s time to actually add attributes to the model. Since our theme is cars here, we’ll stick with three simple attributes: year, make, and model:

Create NSManagedObject subclass

With the model attributes all configured, it’s time to create an NSManagedObject subclass. This will make consuming the model much easier in client applications. I’ve actually written up a full walk through on creating an NSManagedObject subclass in Swift as there are some nuances. Feel free to read up on that if you so desire!

Be absolutely sure to mark your NSManagedObject subclass and its properties public – otherwise, the client app won’t be able to see the class or its properties:

As I point out in Implement NSManagedObject Subclass in Swift, you need to set the Module property in the Data Model Inspector to be CarKit (which is the same as the “Current Project Module” option for this example):

Build and inspect outputs

We’ve got a framework, and we’ve got a Data Model with attributes and an NSManagedObject subclass all appropriately implemented. Now it’s time to build the project and inspect the output of the build!

Command + B to build, and then head up to the File menu and choose Project Settings:

In the Project Settings area that appears, click the small gray arrow under the “Derived Data” section:

Next, find the derived data folder for your project. It should be named the same as your project with a set of random characters after. Sometimes there will be multiple folders that could be your project. You can look at the last modified date to help figure you figure out which one was most recently built and choose that one.

Expand the Build folder down to Build -> Products -> Debug-iphonesimulator. There you should see the CarKit.framework artifact, and within it, everything that’s needed to be able to utilize the data model in a client application. Awesome!

Note: This framework is not production-ready. It’s a little more involved to create a framework that one can run on a device / pass validation when submitting to the app store. The development of the framework remains the same, but the build phases and procedures must be modified to make it “universal”. Rather than overly complicate this walkthrough, I recommend reviewing “Universal Cocoa Touch Frameworks for iOS 8 – (Remix) by @kodmunki to create a “universal” framework capable of being run in the simulator and on iOS devices.

Creating the framework-dependent app

With the framework built, it’s time to create the iOS app that will utilize that framework and its packaged assets! Begin a new project from File -> New -> Project and select “Single View Application”. I’ll name our example app “Carz”. Ensure that “Use Core Data” is selected so that you get the boilerplate Core Data code put into your project by Xcode:

Remove Xcode-generated .xcdatamodeld file

When you select “Use Core Data” in the project creation window, Xcode automatically generates some boilerplate code, which we want. But it also gives us a “Carz.xcdatamodeld” file, which we will not need because we’ll use the model that’s found in CarKit. Remove the “Carz.xcdatamodeld” file that Xcode provides for you:

Obtain framework Bundle Identifier

Speaking of using the CarKit Core Data model, we’re now ready to configure that piece of the app. To do this part, you will need to know the Bundle Identifier from your framework project. To find out what it is, jump back over to the framework project, click the top-level node in the project navigator, click on the framework target name, and look under the General tab of the project configuration. There you’ll find the Bundle Identifier, which you can copy to your clipboard:

Replace managedObjectModel property initialization

Out of the box, Xcode generates some code to help locate your Core Data model file. The boilerplate managedObjectModel property looks like this:

lazy var managedObjectModel: NSManagedObjectModel = {
    // The managed object model for the application. This property is not optional. It is a fatal error for the application not to be able to find and load its model.
    let modelURL = NSBundle.mainBundle().URLForResource("DataModelFileName", withExtension: "momd")!
    return NSManagedObjectModel(contentsOfURL: modelURL)!
}()

However, this won’t work for us, because we’re going to use the data model from CarKit, and CarKit is not in the mainBundle(). This is why we jumped over and copied the Bundle Identifier for CarKit in the previous step. To locate the data model file in that bundle, you’ll replace the managedObjectModel initialization step to the following (for CarKit):

lazy var managedObjectModel: NSManagedObjectModel = {
        // The managed object model for the application. This property is not optional. It is a fatal error for the application not to be able to find and load its model.
        let carKitBundle = Bundle(identifier: "com.andrewcbancroft.CarKit")
        
        let modelURL = carKitBundle!.url(forResource: "CarModel", withExtension: "momd")!
        return NSManagedObjectModel(contentsOf: modelURL)!
}()

Recall that “CarModel” is the name of the Core Data model we created for the framework in CarKit. We simply look for that artifact by calling URLForResource:withExtension: on the carKitBundle to initialize an NSManagedObjectModel instance.

Add CarKit framework to project and embed binary

Now it’s time to actually bring in the framework for use within our app. I typically open up a Finder window and drag over a copy of the framework (in this case, the CarKit.framework file) into my project. Feel free to organize it into a “lib” folder.

Assuming that you go through all the necessary steps to make the framework production-ready, you’ll want to embed the binary and ensure that it’s referenced in the “Linked Frameworks and Libraries” portion of your project configuration:

Taking the model out for a test drive (pun intended)

It’s simple enough to try things out by writing a simple little snippet of code in the AppDelegate:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    // Override point for customization after application launch.
    
    let newCar = NSEntityDescription.insertNewObject(forEntityName: "Car", into: self.managedObjectContext!) as! Car
    newCar.year = 2015
    newCar.make = "Tesla"
    newCar.model = "S"
    
    do {
        try self.managedObjectContext?.save()
    } catch _ {
    }
    
    let fetchRequest = NSFetchRequest<NSFetchRequestResult>(entityName: "Car")
    let cars = (try! self.managedObjectContext?.fetch(fetchRequest)) as! [Car]
    
    print(cars, terminator: "")
    
    return true
}

This code simply obtains a new Car object, sets some properties, and saves it all with the managedObjectContext instance that’s configured in the AppDelegate.

Then it goes and performs a fetch request to grab all the Car objects and prints them. The results? See for yourself:

Wrapping up

This walkthrough guided you through the process of creating a framework for the purpose of sharing a Core Data model with multiple projects. My hope is that you’re now empowered to make use of _re_use by utilizing Swift frameworks to share even portions of your persistence layer!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Analyzing Swift Protocol Extensions and C# Abstract Classes

Fri, 07 Aug 2015 03:52:25 +0000

Being a C# developer by day and a Swift developer by night has me constantly thinking about the similarities and differences between these two languages. I genuinely enjoy programming with each, and I love it when I can take a strategy that works well in one language, and see where that might cross over to the other. One of the areas I’ve been pondering as of late is the idea of how Swift and C# compare in terms of protocol extensions and abstract classes.

Swift doesn’t have the notion of abstract classes like C# does. However, it does now have an amazingly powerful feature called protocol extensions, which were explained and demonstrated in the popular WWDC15 talk on Protocol Oriented Programming. Why am I comparing protocol extensions with C# abstract classes? What are the similarities? What are the differences? Which one do I like best? The analysis of and concluding answers to these questions is the goal of this article.

Why the comparison?

What got me thinking about this? Well, I was re-watching Protocol Oriented Programming the other day and was digesting some of the arguments for why protocols often serve as better abstractions than classes. When classes are used to model a generalized abstraction, the only way they do it is through inheritance. Subclasses of some other, more generalized, base class will automatically be able to behave the same and store the same state as that base class by virtue of inheritance.

Protocols on the other hand, model abstraction through composable template-like descriptions: “Adopters of this protocol will do [x, y, and z] by implementing [function x, function y, and function z] and will have [property a, and property b]”, etc… But they define a template only – no implementations are defined within a protocol.

In C#, we have a similar mechanism to protocols called interfaces. The same paradigm of defining a template with no implementations exists in C# when we use an interface to model some abstraction. C#, of course, also has classes and can pass along behavior and state to subclasses through inheritance.

Understanding C# abstract classes

But C# has one other mechanism for abstraction: abstract classes. These special types of abstractions have the ability to behave like interfaces (or protocols) in that they can strictly define a template with no implementation, requiring all subclasses to supply that implementation. But abstract classes are unique in that they aren’t required to define a template only – they can actually provide a default implementation that may or may not be overridden in a subclass, depending on what the implementer of the subclass wants to do.

We still can’t make instances of an abstract class, just like we can’t make instances of an interface or protocol. But with abstract classes, we can provide some default implementation that can be a customization point for concrete subclasses, should the implementer of the subclass desire to override this default behavior.

Bringing it back to Swift

So… what does this have to do with Swift? Well, it seemed to me that there’s a little overlap between Swift 2.0’s new protocol extensions, and C# abstract classes. How?

With Swift protocol extensions, we can now provide default implementation for a protocol requirement, such that any adopter of the protocol automatically uses that implementation and satisfies that particular requirement of the protocol.

A given Type implementing the extended protocol could choose to provide its own implementation to customize the behavior as it needs. But if it chooses not to, it gets that default behavior for free.

Therein lies the overlap I see between Swift protocol extensions and C# abstractions. But let’s explore a little more in terms of similarities and differences between the two by analyzing an example.

Working example: Modeling athletes

Suppose for a moment that we’re working on an app that models athletic competition (such as marathons, triathlons, and other sporting events). Now, athletic competition implies athletes, does it not?

How then, could we model an Athlete in an abstract way? That is, how can we provide just the blueprint for what an Athlete does, so that such a Type can be entered into one of the athletic competitions and perform in it?

Modeling the Athlete abstraction with C#

In C#, we’ve got two possibilities: Create an interface, or create an abstract class.

Using an interface may look something like this:

1public interface Athlete
2{
3    public void Run();
4    public void Swim();
5    public void Cycle();
6    // Other things that an Athlete may be able to do
7}

Using an abstract class may look very similar. The primary difference is in the declaration of each method, where we mark each of them virtual, so that they can be overridden in a subclass to provide that customization point I talked about earlier:

1public abstract class Athlete
2{
3    public abstract void Run();
4    public abstract void Swim();
5    public abstract void Cycle();
6    // Other things that an Athlete may be able to do
7}

Right off, you might be asking, “Should a marathon runner have to be able to swim and cycle??”. It’s a great question, and I’ll address it further down in the article when I discuss “refactoring for enhanced composability with Swift protocol extensions”.

Modeling the Athlete abstraction with Swift

In Swift, we essentially have one possibility that compares with C# for a pure abstraction, that is, just the blueprint describing an Athlete's capabilities: Create a protocol.

The Athlete protocol might look something like this:

1protocol Athlete {
2    func run()
3    func swim()
4    func cycle()
5    // Other things that an Athlete may be able to do
6}

We still don’t avoid the necessity of a marathon runner being required to be able to swim and cycle. And having read David Owens’ recent recommendations on Protocols, I’m even more uncomfortable with modeling an Athlete this way, because it feels like we’re treating a protocol as a Type here, which he identifies as a less powerful usage of protocols.

I want to refactor this, but for this moment in time, we’ll stick with the code as-is, just to keep it as similar to the C# code as possible. I’ll discuss an option for refactoring this shortly.

Default implementation for athletic abilities

As the example stands right now in both C# and Swift, we’ve got a situation where any Type wishing to be an Athlete, whether it be by implementing the C# interface, subclassing the C# abstract class, or adopting the Swift protocol, must provide implementations of each of those athletic abilities (run, swim, and cycle). The Type can’t not implement one of those requirements and have the code still compile. They’re requirements of what it means to be an Athlete, so the Type must conform.

Suppose that in our scenario, any given Athlete has one primary ability which he/she is amazing at, but when it comes to his/her non-primary abilities, the Athlete is only able to perform at “average” skill.

This sounds like a case where it might be nice to have overridable default implementation provided. Any specific type of Athlete could override that default implementation to perform the ability better or worse, depending on what kind of Athlete he/she is. But if the specific Athlete Type didn’t provide an customized override, the Type would get the “average” behavior for free.

How could we make this happen?

Default implementation with C#

In C#, abstract classes allow us to do just that. Here’s how a default implementation might be written:

 1{
 2    public virtual void Run()
 3    {
 4        // run with average speed and endurance
 5    }
 6
 7    public virtual void Swim()
 8    {
 9        // swim with average speed and endurance
10    }
11
12    public virtual void Cycle()
13    {
14        // cycle with average speed and endurance
15    }
16}

So now, when we want to model a MarathonRunner, we can override his/her ability to run, swim, and cycle as appropriate:

1{
2    public override void Run()
3    {
4        // run with average speed and __insane__ endurance
5    }
6}

It’s not terrible – At least here we can rely on the default implementation if we just want to give a MarathonRunner “average” abilities in all areas but running.

We might prefer that a MarathonRunner not be required to have any ability to swim or cycle, but that’s always the struggle with inheritance-based modeling. You only get to choose one base class to inherit from, and you’re bound to get some behavior that you don’t need, simply because it’s hard to model abstractions using inheritance that avoid giving you more than you need.

Default implementation with Swift

The default implementation story with Swift was non-existent until Swift 2.0 entered the scene. The approach is similar, but as we’ll see shortly, provides far more power in terms of composability. Take a look at the implementation that compares most closely with C# for now:

 1extension Athlete {
 2    func run() { // run with average speed and endurance 
 3    }
 4
 5    func swim() { // swim with average speed and endurance 
 6    }
 7
 8    func cycle() { // cycle with average speed and endurance 
 9    }
10}

Now when we want to model a MarathonRunner in Swift, we can adopt the Athlete protocol, and provide “override” implementations for any of the protocol’s requirements that we’d like. Anything we don’t provide a custom implementation for falls back to the protocol extension’s implementation, just like in C#:

1class MarathonRunner: Athlete
2{
3    func run() {
4        // run with average speed and __insane__ endurance
5    }
6}

Similarities

Here’s a list of the similarities I see between C# abstract classes and Swift protocol extensions:

Both outline a set of requirements that either a subclass or a protocol adopter must implement.
Both provide a means to automatically satisfy some (or all) of the requirements by providing a default implementation. With C#, we simply mark the method virtual to allow overriding in the subclass, and provide then an implementation. With Swift, we define a protocol extension that implements one or more of the protocol’s requirements.
Both ease the burden of subclasses (C#) or protocol adopters (Swift) to implement all of the requirements when reasonable default implementations could suffice.
Both are used to provide customization points in subclasses (C#) or protocol adopters (Swift), when the default implementation is inadequate.

Differences

So there are some similarities that I hope you can see and appreciate between C# abstract classes and Swift protocol extensions. But there are some major differences that should also be recognized:

Fundamentally, C# abstract classes are a “behavior by inheritance” tool, while Swift protocol extension are a “behavior by composition” tool.
Consequently, C# abstract classes impose a significant limitation: subclasses can inherit from one and only one base class. Swift protocols, on the other hand, can be decomposed into fine-grained, specific requirements that can later be re-combined and composed into more robust and dynamic Type specifications. While C# interfaces provide this same composability, they don’t have the ability to provide default implementation, which is a significant difference between the Swift counterpart.
As a consequence of that, subclasses of a C# abstract class get all of the behavior, whether they need (or want) it or not. Swift protocols, being composable, allow a Type to conform to just the pieces it needs. The protocol extension can still exist to provide default behavior when it’s appropriate. But if a certain Type needs no ability to [do some thing], it simply drops conforming to that protocol and no superfluous behavior is imposed upon the Type.

Preferring one over the other

Needless to say, I prefer Swift protocol extensions over C# abstract classes (shocker). I love the composability they offer, while at the same time allowing me to provide default implementations where it’s appropriate. In my opinion, Swift protocol extensions are the perfect blend of interface and abstract class in C#. If only C# had “interface extensions”. :]

Since we can apply multiple protocols to a Type to signify what the Type can do, and essentially compose its behavior, how might we diverge from the constraints we had previously when we tried to stick closely with the C# abstract class paradigm?

Recall that I was uncomfortable with making a MarathonRunner have ability to swim and cycle, however “average” that ability may be. What I really want is to break things out a bit more, but still be able to provide that default implementation when I want it.

How might I refactor this by leveraging even more of the power of Swift protocol extensions?

Refactoring for enhanced composability with Swift protocol extensions

I think I might like to define 3 protocols instead of 1. Rather than modeling things as Athletes, I’d much rather model some athletic behavior, and let the specific kinds of athletes adopt whatever behavior is most appropriate for each athlete type.

So I’ll ditch the Athlete protocol, and define these three instead:

 1protocol Runnable {
 2    func run()
 3}
 4
 5protocol Swimmable {
 6    func swim()
 7}
 8
 9protocol Cycleable {
10    func cycle()
11}

Alright… now… how about some default implementation?

 1extension Runnable {
 2    func run() {
 3        // run with average speed and endurance
 4    }
 5}
 6
 7extension Swimmable {
 8    func swim() {
 9        // swim with average speed and endurance
10    }
11}
12
13extension Cycleable {
14    func cycle() {
15        // cycle with average speed and endurance
16    }
17}

Excellent. Now to cap things off, I’ll define some Types that adopt just the protocols that are needed:

 1struct MarathonRunner: Runnable {
 2    func run() {
 3        // run with average speed and __insane__ endurance
 4    }
 5}
 6
 7struct Triathlete: Runnable, Swimmable, Cycleable {
 8    func swim() {
 9        // swim with lightning speed and crazy endurance
10    }
11
12    // fall back to protocol extension's average run speed & endurance
13    // fall back to protocol extension's average cycle speed and endurance
14}
15
16struct Andrew {
17    // Let's not impose the re-definition of any of the athletic terms, shall we?
18}

Notice how the different types of athletes only pick up the behavior that’s relevant to their ability. Nothing more, and nothing less.

I also enjoy being able to look at a Type declaration like Triathlete and see that he/she is able to run, swim, and cycle. It feels right to compose abilities this way. And it’s even more convenient that some of the Triathlete's behavior is already implemented for me by virtue of the protocol extension.

Wrapping up

I hope this analysis helped you see some of the same things I saw when it comes to how abstractions can be modeled with Swift, and how that compares with others languages like C#.

Setting Up Carthage for the Terminal-Timid

Thu, 30 Jul 2015 04:05:05 +0000

The old adage “Don’t go reinventing the wheel” comes into play often when developing software, doesn’t it? Why build this [thing] ourselves when someone else has invented it already?

Fantastic libraries and frameworks exist out there to assist developers with common and sometimes even difficult problems. Whether it be an easier-to-use abstraction over the networking stack with AFNetworking or AlamoFire, or adding a popular behavior-driven development testing framework like Quick to our workflow, we find ourselves constantly wanting to be able to take advantage of the things that others are doing in the community so we don’t have to invent that wheel again ourselves.

The need for dependency management

With that comes the need for an easy way to manage external dependencies in our projects. We find the need to make sure that our projects have the right versions of whatever libraries or frameworks we’re bringing in. We want to ensure that if we move to another machine or add folks to our teams that they can go and restore all those same external dependencies without a lot of hassle. Therein lies at least partial justification for the usage of dependency managers.

The long-running “king of the hill” of dependency management for iOS developers has been the ever-popular CocoaPods. However, there’s a new kid on the block, and its picking up popularity. This “new” dependency manager is called Carthage.

What is Carthage?

From the GitHub repository’s main page for Carthage (emphasis mine):

Carthage is intended to be the simplest way to add frameworks to your Cocoa application… Ultimately, we created Carthage because we wanted the simplest tool possible—a dependency manager that gets the job done without taking over the responsibility of Xcode, and without creating extra work for framework authors.

I’ve used Carthage for simple tasks like bringing in Quick for unit testing. It delivers on the promise of being simple, but even in its simplicity, installing and using Carthage requires the use of the Terminal.

Terminal tension

If you’ll withhold judgement of this confession, I’ll openly share that I’m not a whiz on the command line. I have found that the more I spend time in the Terminal, the less timid I become. It’s been a gradual transition into spending intentional time on the command line, but I share this to simply relate to those of you who, like me, find themselves thinking, “Really? All of this involves running commands in the Terminal? Ugh…”

Hang in there. Becoming proficient at this will take practice, but it’s worth it. Carthage really does make your dependency management simpler and more shareable with your team. Even if you’re working alone, I recommend investing the time to overcoming any anxiety you may have around the Terminal.

Installing Carthage

So here’s the deal: The folks on the Carthage team have actually made it pretty easy to install Carthage without the Terminal. If you go to their releases page on GitHub and download + run the Carthage.pkg file for the latest release, you’ll be set up. BUT, Carthage is a command-line tool, so to use it, you’ll still need the Terminal.

With that in mind, I’ve decided to get used to working with this tool totally from the command-line from the start, which means installing it from the Terminal window. There’s a couple more steps involved, but I’d argue that it’s good practice. If you’re wanting to overcome your anxiety around the Terminal, skip the .pkg installation method and continue on.

Terminal installation

Installing Carthage from the command line assumes that you have a package manager for OSX called “Homebrew” installed on your Mac. If you don’t, you need it. And yes, it involves the Terminal too, but don’t worry – I’ve got you covered in the steps to follow. We’ll use Homebrew to install Carthage which will be used to manage the external dependencies in our app.

First things first – installing Homebrew

Installing Homebrew isn’t complicated. It just involves knowing the command to run in the Terminal to get it downloaded and registered in your machine.

From the Homebrew homepage we learn that the installation simply requires us to type in the following in the Terminal:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Pasting in the command and pressing enter will immediately produce a lot of stuff in the terminal window. It’s okay. Don’t panic.

It’s simply letting you know what’s about to happen if you agree to continue:

So it’s going to…

Install some files into some directories on your computer.
Change the read-write permissions on some directories to be group writable. This allows Homebrew to do its thing when you tell it to.
Change those same directories’ group to admin. So these last two bullet points go together.

You’re prompted to press ‘RETURN’ to continue (or anything else to stop the installation). If you’re good with the changes it describes to you, press ‘RETURN'.

Yikes! What’s all this now?

Well, for the installation to continue, Homebrew needs to elevate the level of permissions it has in order write all the files it needs to write and to set all the permissions it needs to set. Under the hood, it’s run a sudo command. It requires your password to authorize this elevation. Go ahead and type your password, and press ‘RETURN’ to continue.

The installation will continue by downloading all of the necessary files and performing all the changes it said it’d make. When it’s done, you’ll get an “Installation Successful” message:

Sweet! To test it out, you can simply type brew help like it suggests in the line below the “Installation successful!” message. It should print out a bunch of stuff to the Terminal window, explaining how to use Homebrew:

Well done! We can now use Homebrew to install Carthage. You can use it to install all kinds of other fantastic utilities as well, but for now we’ll focus on the Carthage installation…

Now to install Carthage

With Homebrew installed, we’re almost there. From the Carthage GitHub repository page, we learn what commands to run on the command line to get Carthage installed.

First, we run brew update to make sure that Homebrew is totally up-to-date. If you just installed Homebrew for the first time, you’re probably good to go. Just to be safe though, go ahead and run it.

The last step is to run brew install carthage. Yes. It’s that simple. Homebrew will take care of everything else for you! Here’s the final result:

Cartfiles

Once Carthage is installed, it’s time to create your Cartfile file. After I read the documentation on how to set this up, I found myself doubting whether I’d done it right, so again, to alleviate any fears our there around the mystery of what’s going on I’ll share what I’ve discovered.

First of all, the documentation merely says, “Create a Cartfile that lists the frameworks you’d like to use in your project.” I scratched my head and asked, “Okay – well, where? And should it have a file extension?”

The answers that worked for me were, “Somewhere in your Xcode project (I put it under Supporting Files)” and “No file extension…just the name Cartfile works”.

To demonstrate, here’s a couple of screenshots depicting how to add a Cartfile to your Xcode project…

Simply add a new Empty file, found under iOS -> Other:

In the new file dialog, simply type in “Cartfile”, and press Create:
Create" width="783" height="298" class="alignnone size-full wp-image-12192" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2015/07/Cartfile-create.png 783w, https://www.andrewcbancroft.com/wp-content/uploads/2015/07/Cartfile-create-300x114.png 300w" sizes="(max-width: 783px) 100vw, 783px" />

Wrapping up

This is where I’m going to stop for now and defer to the Carthage GitHub documentation to explain more about what exactly to put into the Cartfile and how to run the subsequent commands to grab the libraries and frameworks you list, and build them so that they can be added to your Xcode project. I may pick this back up again, but this guide was starting to get lengthy, and I felt that actually building the frameworks from a Cartfile could very well deserve isolated treatment for the sake of clarity. If you’re interested in reading more on Carthage, sound off in the comments or shoot me an e-mail! Thanks for reading.

Dissecting 10 Read 10 Said – My New Swift iOS App

Thu, 23 Jul 2015 03:57:33 +0000

I’m very excited to announce that my new app, 10 Read 10 Said, is now available for iOS and Android!

While the goal of the app is to help you implement the “10 Read 10 Said” strategy for memorizing Bible verses, my goal in this article is to dissect the app, and share with you how some of the major features were implemented.

As it turns out, most of the major features of the app are things that I’ve already written about over the past year of producing Swift content! The approach I’ll take, then, is to walk through each screen and point out which articles I’ve written might pertain to the particular feature implementations that are visible from that screen.

I hope this tour satisfies the curiosity of many like myself who ask, “I wonder how they did that!”

App Demo

To demonstrate the major functionality of the app, I’ve created a short (50 second) YouTube video. Take a look, and then I’ll break down each screen:

Verse List

To begin, the Verse List scene has been embedded in a UINavigationController. This caused me to have to make a few changes in AppDelegate to properly dig in to access the verse list controller and set some properties on it.

I’ve covered the details of how to “unpack” a UINavigationController and access its first child view controller in my article titled “Access Sub-Controllers from a UINavigationController in Swift”.

Table View

The next most obvious thing to notice about the verse list is that it’s been implemented with a UITableView. Additionally, each cell is a “custom” cell, rather than one of the default cell styles that Xcode gives you out of the box. I’ve written an article or three on these:

UITableView Articles

Data Soure

The verse list’s data source is an NSFetchedResultsController. This, of course, implies that my underlying data framework for the app is Core Data. Here are some of the articles I’ve written on these subjects:

Core Data

Core Data Articles

NSFetchedResultsController

NSFetchedResultsController Articles

Add Verse

Adding a verse and synchronizing things to the table view (and the persistent data store) involves all-things Core Data and NSFetchedResultsController. Using the combination of these two made things super easy to keep up-to-date in the UI.

When you press ‘Save’, your verse gets sent to the managed object context for the app. Once it’s saved using the context, the verse list gets automatically updated using its NSFetchedResultsController data source. I really liked the results!

Memorize

The memorization screen brings into play a few UI elements that I’ve experimented with and written on in the past. First, let’s take a look at these two screen layouts to have the visual before us:

Read It, Said It

The most notable thing I can think of on this scene is the circular progress indicator to help visualize how close you are to completing the read / said goal.

A few other subtle notes are the fade in/out animations that happen when you complete the read goal, the said goal, and the peek/hide action. Check out the related articles for those pieces:

UI Articles

Wrapping up

While this isn’t the first app I’ve worked on and published to the App Store, it is my first personal project idea that’s out there. I had a lot of fun building it as a utility for myself in my own Scripture memorization efforts. My hope is that the tool (and more importantly, the strategy) is helpful to others as well!

My goal in this article was to give you a “behind the scenes” look at 10 Read 10 Said. I hope your curiosity has been satisfied by some of these inside looks into the app!

UITableView Swipe to Delete Workflow in Swift

Fri, 17 Jul 2015 04:00:18 +0000

Data management applications, by which I mean an app where you’re allowing users to add, edit, and delete bits of data as part of your app’s core function, very likely use a table view (or two) to visualize lists of information that users of the app can interact with.

Making changes to the information listed in the table view and signaling those changes in a fluent way becomes a top concern for these types of apps. How do we allow users to add or remove “records” to the system? Furthermore, how do we signal that those changes were effective and refresh the view of the data in the UI?

The primary concern I want to focus in on in this article is the ever-common paradigm of “swipe to delete” when using a table view. What could the workflow of deleting a row from the table view (and its data source) look like? How could it be implemented in Swift? Let’s explore…

Workflow

The workflow of “swipe to delete” that I typically use in my own applications is this:

Swipe a table view row and have the Delete button appear.
Press the delete button, which triggers a confirmation: “Do you really want to delete this?”
Based on the user’s response to the confirmation, delete the object from the data source and remove it from the table view, or cancel.

The confirmation step is atypical for iOS it seems. Swiping to delete an e-mail or a reminder or just about anything else in Apple’s own apps simply deletes the item right away.

There may be a good reason for this, but I like to give folks an out if they didn’t mean to do it. It’s fair enough to say, “Well, they went to the effort of swiping the row and pressing the button… surely they mean to do it!”. I still feel more comfortable if I get the opportunity to cancel something like a delete operation. Feel free to disagree there – for this article, I’ll assume you want to include that into your delete workflow, and will demonstrate a simple way to implement all three steps of the strategy.

Implementation

To demonstrate the implementation of this workflow, suppose that we’ve got a table view listing out all of the planets in our solar system (all of the news on Pluto this week has me thinking in this direction, so I just went with it). Feel free to grab the example project over at GitHub:

Resources

Swipe to Delete Example

The table view looks like this once its data source is all configured:

Swipe

What we want is to be able to swipe one of the rows and delete the planet from the data source and, consequently, remove it from the table view in a nice, fluid way:

To accomplish this, we need to do a couple of things.

First, your view controller needs to conform to the UITableViewDelegate protocol, because the swipe to delete functionality is encapsulated by one of the table view delegate methods. It’s a simple change at the class declaration:

class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate { ... }

The delegate method that causes the buttons to appear on swipe is called tableView(_:commitEditingStyle:forRowAtIndexPath

Its implementation for the example I’m working through looks like this:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    var deletePlanetIndexPath: NSIndexPath? = nil
 6
 7    // ...
 8
 9    func tableView(tableView: UITableView, commitEditingStyle editingStyle: UITableViewCellEditingStyle, forRowAtIndexPath indexPath: NSIndexPath) {
10        if editingStyle == .Delete {
11            deletePlanetIndexPath = indexPath
12            let planetToDelete = planets[indexPath.row]
13            confirmDelete(planetToDelete)
14        }
15    }
16
17    // ...
18}

So what’s happening here? The primary thing to notice is that we’re evaluating the editingStyle from the method’s parameter list. Comparing it to the .Delete UITableViewCellEditingStyle value is what allows us to know that the Delete button was tapped.

Since I have a confirmation step to take care of, I’ve chosen to store the indexPath of the row we’re wanting to delete in a class-viewable variable so that I can use it later on when we handle the deletion (if the user confirms it).

The final step of this function is to call confirmDelete(), which has its own explanation coming up…

Confirm

The next step is confirming that the user really wants to delete the particular planet they’ve initiated the delete action on:

How is this implemented? It all boils down to using iOS 8’s new UIAlertController:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    func confirmDelete(planet: String) {
 6        let alert = UIAlertController(title: "Delete Planet", message: "Are you sure you want to permanently delete \(planet)?", preferredStyle: .ActionSheet)
 7        
 8        let DeleteAction = UIAlertAction(title: "Delete", style: .Destructive, handler: handleDeletePlanet)
 9        let CancelAction = UIAlertAction(title: "Cancel", style: .Cancel, handler: cancelDeletePlanet)
10        
11        alert.addAction(DeleteAction)
12        alert.addAction(CancelAction)
13        
14        // Support display in iPad
15        alert.popoverPresentationController?.sourceView = self.view
16        alert.popoverPresentationController?.sourceRect = CGRectMake(self.view.bounds.size.width / 2.0, self.view.bounds.size.height / 2.0, 1.0, 1.0)
17        
18        self.presentViewController(alert, animated: true, completion: nil)
19    }
20
21    // ...
22}

We’re asking the user if they’re sure they want to permanently delete the planet using the .ActionSheet style.

The next step of the function is to create a couple of UIAlertAction buttons: one for Delete and one for Cancel, with the appropriate style (.Destructive and .Cancel, respectively).

Finally, we provide a function to each UIAlertAction instance. The handlers, of course, could have been implemented with closures, but I chose to built out a couple of named functions, just to be able to step through it with you, and to separate out the logic of the steps a little more. Feel free to do whichever seems most natural to you.

Delete or cancel

This is the final step! The following code snippet is an implementation of the two handlers specified for the initialization step of the UIAlertAction buttons, which were handleDeletePlanet and cancelDeletePlanet:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    var deletePlanetIndexPath: NSIndexPath? = nil
 6
 7    // ...
 8
 9    func handleDeletePlanet(alertAction: UIAlertAction!) -> Void {
10        if let indexPath = deletePlanetIndexPath {
11            tableView.beginUpdates()
12            
13            planets.removeAtIndex(indexPath.row)
14            
15            // Note that indexPath is wrapped in an array:  [indexPath]
16            tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Automatic)
17            
18            deletePlanetIndexPath = nil
19            
20            tableView.endUpdates()
21        }
22    }
23    
24    func cancelDeletePlanet(alertAction: UIAlertAction!) {
25        deletePlanetIndexPath = nil
26    }
27
28    // ...
29}

Clearly, handleDeletePlanet() is the most involved. The essential process is this:

Call beginUpdates() on the table view instance to signal the start of UI updates to the table view.
Remove the planet from the data source using the deletePlanetIndexPath we set in the alert controller step.
Call deleteRowsAtIndexPaths() on the table view to remove the planet from the UI.
Reset the class-viewable deletePlanetIndexPath to nil.
Call endUpdates() on the table view instance to complete the UI updates.

There’s one gotcha, that I’ve tried to highlight by way of comment in the code snippet: Notice that within the call to deleteRowsAtIndexPaths (plural), I’ve wrapped the indexPath we’re removing in an array. It’s subtle, but this delegate method expects an array of indexPath instances, not a single index path instance. It’s simple enough, but it can catch you off guard if you’re in the mindset of removing a single row and come across this method, which is flexible enough to allow you to delete several at a time.

Wrapping up

Swipe -> confirm -> delete or cancel. Those are the steps we analyzed in this commonly needed workflow in data management applications.

You might also enjoy…

Circular Progress Indicator in Swift

Fri, 10 Jul 2015 04:31:49 +0000

Updated on April 17, 2017 – Swift 3

Circular progress indicators are a nice and compact way to visualize progress information for users of your iOS app. I was extremely grateful to come across Kaan Dedeoglu’s KDCircularProgress project on GitHub. It’s a versatile little UI component written in Swift that provides a great amount of flexibility and customization options. I love it!

As a bonus to this amazing component, recent contributions by Kaan have opened up the ability for us to lay out and set up the circular progress indicator in the Storyboard!

My goal in this article is to help get you up and running with this library in your own Storyboard-based Swift project.

Example project

Kaan’s GitHub repository has an example project, but I’ve also gone ahead and made one as well for showing how to use this indicator in a Storyboard. We’ll be using the example I created as a reference point for the forthcoming walk-through.

Resources

Circular Progress Example

Getting started

The most obvious starting place is to head over to the KDCircularProgress repository on GitHub to grab the KDCircularProgress.swift source file and add it to your own Swift project. Kaan has things set up with CocoaPods as well if you care to use that. I found adding the .swift file to my project to be the least intrusive way to add this indicator to my UI components arsenal.

To the Storyboard!

Since Kaan added IBDesignable and IBInspectable support, working with the circular progress indicator in the Storyboard is super easy.

To get started, all you need to do is drag a plain View over to the Storyboard Scene. Set up your constraints to correctly position the view where you need it:

Next, you need to set the View’s class to a custom class, namely, KDCircularProgress:

With that in place, Xcode will process things and allow you to modify the properties of the progress indicator directly in the attributes section of the Utilities pane. Best of all, you’ll see those changes be reflected in the Storyboard scene in real-time as you adjust values!

viewDidLoad()

While in the Storyboard, I set a few values so that I could actually see certain colors when progress had been made. However, to get things set to their true initial state, there may be some values you want to reset in viewDidLoad(). For example, I set the angle property to 90 degrees so that I could see the color of the progress track in the storyboard. But when I load the app, I want the angle to be 0 degrees (since no progress has been made when the app first loads).

To accomplish this, you’d simply make sure there’s an outlet between your progress view in the Storyboard and the View Controller. Once they’re connected, you can write something as simple as circularProgressView.angle = 0 to start off with no progress.

Increasing progress

We’re dealing with a progress indicator here, so this implies that there’s a beginning, some incremental steps taken toward a completion goal, and of course, the fully completed whatever it was you were doing.

The example I’ve contrived is a simple counter with an upper limit of 5. So as you tap “Increase Progress”, the circular progress view should update to be some fraction of the way around the 360 degree circle based upon how close we are to completing the count to 5.

There’s a function I’ve built to calculate the new angle:

1func newAngle() -> Double {
2    return 360 * (currentCount / maxCount)
3}

The rest is simply a matter of updating the current count and animating to the new angle:

1@IBAction func increaseProgressButtonTapped(sender: UIButton) {
2    if currentCount != maxCount {
3        currentCount += 1
4        let newAngleValue = newAngle()
5        
6        circularProgressView.animate(toAngle: newAngleValue, duration: 0.5, completion: nil)
7    }
8}

Resetting the indicator

To reset everything, we’d want to update the state of our current count back to 0.

The change to the circular progress indicator’s visualization of the progress state can be animated by calling the view’s animate(fromAngle:toAngle:duration:completion:) method:

1@IBAction func resetButtonTapped(sender: UIButton) {
2    currentCount = 0
3    circularProgressView.animate(fromAngle: circularProgressView.angle, toAngle: 0, duration: 0.5, completion: nil)
4}

Wrapping up

There are a ton of other customization options that you can play with. I highly recommend this UI component if you’re looking for an easy-to-use, versatile circular progress indicator!

Every Swift Value Type Should Be Equatable

Wed, 01 Jul 2015 18:07:35 +0000

As I listened to the WWDC15 talk on Building Better Apps with Value Types in Swift I was struck by a sentence that I had never dawned on me before:

Every Value Type should be Equatable.

That is, every Value Type should conform to the Equatable protocol.

Talk about a sweeping statement! Wow – every Value Type should be Equatable? Hmm… Let’s unpack the “why’s” and “how’s” of this statement.

Why?

I’d never thought about why I might want my Value Types in Swift to be Equatable. Not that I thought it’d be a terrible idea to implement the == operator for a Type… I just never realized that this was actually expected behavior of Value Types!

The reasoning in the talk was that Values are intuitively meant to be compared for equality. Because they’re Values, there is inherent expectation from clients of the Type to be able to ask and know if one Value is equal to another Value of the same Type.

We naturally expect to be able to ask two variables/constants, each holding Int Values (because in Swift, Int is a Value Type), if they equal each other. And we naturally expect the comparison to compare the actual numbers… the Values themlselves.

1let a = 10
2let b = 5 + 2 + 3
3a == b // true
4
5let x = 1
6let y = 2
7x == y // false

Likewise, we naturally expect to ask two Strings if they’re equal:

1let str1 = "I love Swift!"
2let str2 = "I love Swift!"
3str1 == str2 // true
4
5
6let str3 = "i love swift!"
7str1 == str3 // false - case-sensitive comparison

In fact, we naturally expect to ask these kinds of equality questions about any of the Swift standard library Value Types, don’t we?

How?

We do expect to test for equality between two Value Types. It just makes sense.

So now the question is, “How?”

The simple answer is that our Value Types need to implement an == operator. But there’s something really important to consider:

Properties of equality

To be truly equal, the == operator not only needs to be implemented, but it needs to be implemented in such a way that it behaves as we’d expect when doing our comparisons. During the talk, Doug mentioned three important properties of equality that need to hold for our Value Types:

The comparison must be reflexive
The comparison must be symmetric
The comparison must be transitive

That sounds awfully “math-y”. In fact, it’s the exact same terminology used in mathematics. But don’t worry, the terminology is simple and natural to understand.

Reflexive

To be reflexive, the Type’s == operator needs to make sure that the expression x == x returns true.

So if I have let x = 1 and I write the expression x == x, I do in fact get true because Int‘s equality operator is reflexive (as expected).

Symmetric

To be symmetric, the Type’s == operator needs to compute things in such a way that the expression x == y and y == x return the same value.

Here’s an example of symmetry:

 1let x = 1
 2let y = 1
 3
 4x == y // true
 5y == x // true
 6
 7let str1 = "Hi"
 8let str2 = "Hello"
 9
10x == y // false
11y == x // false

Transitive

Finally, to be transitive, the Type’s == operator needs to compute things in such a way that when x == y is true, and y == z is true, then x == z is also true.

Here’s an example of transitivity:

1let x = 100
2let y = 50 + 50
3let z = 50 * 2
4
5x == y // true
6y == z // true
7x == z // true

Implementation

Most of the time, the implementation of == is very simple. If your Value Type is comprised of other Value Types that have an == operator that’s correctly implemented with the semantics I just described, then the implementation for your Type is straight-forward.

An example might help to set things up for understanding. Suppose that we’re building a sight-seeing app for a local tourism company. We’ve got a struct called Place to help us encapsulate the idea of… well… a “place” to visit. It looks something like this:

1struct Place {
2    let name: String
3    let latitude: Double
4    let longitude: Double
5
6    // init is auto-generated by the compiler in this case
7}

Since Place is a Value Type (Struct) which is comprised of other Value Types, you’d simply need to do something like the following to make it Equatable:

1extension Place: Equatable {}
2
3func ==(lhs: Place, rhs: Place) -> Bool {
4    let areEqual = lhs.name == rhs.name &&
5        lhs.latitude == rhs.latitude &&
6        lhs.longitude == rhs.longitude
7    
8    return areEqual
9}

One of the first things to notice is that the == operator has to be implemented as a stand-alone global function, rather than as part of the Type definition.

Notice also that even though we have the source for the Type that we want to make Equatable, I chose to signal the Equatable protocol adoption through an extension on the Type, rather than at the Type declaration itself. Both are acceptable, but it’s become convention to use the extension strategy for this particular protocol.

The implementation of == uses the intuitive semantics that one Place isn’t the same as another Place unless the names, latidudes, and longitudes are all the same.

lhs and rhs simply mean “left-hand side” and “right-hand side”, respectively. Since there’s a Place instance on the left-hand side of the == operator, and a Place instance on the right-hand side of the == operator when we use it in practice, it makes sense to label these parameters according to that pattern.

The implementation could literally be read as, “If the Place on the left-hand side’s name is equal to the Place on the right-hand side’s name, AND … the latitude … AND … the longitude, then the two Place instances are equal.”

Dealing with reference types

If Reference Types are involved with your Value Type implementation, things could get a little more complicated. “Complicated” probably isn’t the right word… but you do have to think a little more about your Type’s equality semantics.

Let’s modify the example just a little bit:

Supposing that Place had an additional property called featureImage which held a reference to a UIImage instance (a Reference Type), we’d need to test for equality a little bit differently. And how we test for equality depends on the particulars of our Type’s equality semantics:

Are the two Places equal if both of them point to the same featureImage (ie, should we just use === to check and see if the references are the same)?
OR, are the two Places equal if both of their featureImage instances contain the same underlying bitmap (ie, they’re the same picture in essence)?

As you can see, the phrase “it depends” applies here. Certainly we need to test for some kind of equality on the featureImage in order to have a complete == implementation. But how we go about it really comes down to the semantics that you and others would expect from asking the question, “Is this Place equivalent to that Place?”

For this example, I’m going to go with the latter statement: that two Places are equal if both of their featureImage instances contain the same underlying bitmap.

 1extension Place: Equatable {}
 2
 3func ==(lhs: Place, rhs: Place) -> Bool {
 4    let areEqual = lhs.name == rhs.name && 
 5            lhs.latitude == rhs.latitude &&
 6            lhs.longitude == rhs.longitude &&
 7            lhs.featureImage.isEqual(rhs.featureImage) // depends on your Type's equality semantics
 8
 9    return areEqual
10}

Wrapping up

Every Value Type should conform to the Equatable protocol. In this article, we unpacked the “why’s” and the “how’s” of this fundamental characteristic of Value Types. From here, we’ve all got to jump on board and ensure that we meet this expectation in our code!

You might also enjoy…

Send a Type to Obedience School – Using Swift Extensions for Additional Protocol Conformance

Swift UIColor Extension – Create using RGB Values (Not %)

Fri, 26 Jun 2015 03:11:48 +0000

I’ll say it up front – I’m not a great designer. What tends to happen with me and projects is that I end up saving all-things color until the end of a project. You know… the old procrastinator’s motto: “If you don’t get it done today and tomorrow doesn’t come, then you ain’t gotta do it!”

So the other day came and I had to “do color”…

Thankfully, a buddy of mine has good skills in the area, and gave me a color palette to use. Score!

Working with colors

I decided it might be nice to go ahead and encapsulate my color scheme in code and set the various tints and font colors and navigation bar backgrounds to their appropriate values in code.

This seemed like a really nice way to keep all the color stuff in once place, so that if I ever needed to change things, I’d be able to do it in one spot, and the whole app would just magically take on the adjustments.

Inevitably, I’d need to create myself some UIColor instances.

Baffled

For those of us who spend a lot of time designing in the Storyboard, as opposed to creating views and layouts directly in code, coming up against the UIColor API when you haven’t in a while can be…well…baffling. Not because it’s “hard” but because it’s not as intuitive as it looks on first-sight. Here’s what I mean…

My color-adept friend had given me some hex color values. Looking at UIColor of course, there’s no initializer or class function to create a color with such a value. No worries, though – there are plenty of converters out there!

So I got my red, green, and blue values all in order and did the thing that seemed most obvious: I supplied UIColor‘s init method with those values, verbatim:

let primaryColor = UIColor(red: 39.0, green: 44.0, blue: 79.0, alpha: 1.0)

And then I realized that I hit the same “gotcha” that I had before. UIColor takes a percentage of red, green, and blue, not the value of red, green, and blue. I needed to divide the values by 255.0 each in order to obtain a value between 0 and 1 as the initializer requires. Sure, this is in the documentation:

The red component of the color object, specified as a value from 0.0 to 1.0.

Similar instructions appear for green, blue, and alpha.

It’s easy enough to fix, but man – that sure seems like an easy-to-fall-for mistake if you’re coming to this API after spending time away from it, or if you’re brand new to iOS development.

UIColor extension

Having to divide the RGB values by 255.0 every time was just annoying enough that I created a UIColor extension to help me be able to do the intuitive thing and just supply the RGB values verbatim, like I’d done to begin with. Here it is for your enjoyment:

1extension UIColor {
2    static func colorWithRedValue(#redValue: CGFloat, greenValue: CGFloat, blueValue: CGFloat, alpha: CGFloat) -> UIColor {
3        return UIColor(red: redValue/255.0, green: greenValue/255.0, blue: blueValue/255.0, alpha: alpha)
4    }
5}

Wrapping up

I feel a little silly for having made this mistake, but hey – making the mistake is a good way to remember what not to do in the future. And now that I’ve written an extension (and this blog post), maybe I’ll be set for next time I spend extended periods of time avoiding colors.

You might also enjoy…

Creating Calendars with Event Kit and Swift

Wed, 17 Jun 2015 17:46:29 +0000

Updated on April 19, 2016 – Swift 2.1 | Added example project

Apple’s Event Kit framework empowers developers to interact with an iOS device’s calendar database. Not only can we read calendars and events from the database, we can also create calendars.

In a previous article, we looked at how to handle asking the user for permission to access their calendars. Now my goal is to show you how to create local calendars on the user’s device programmatically with Swift using the Event Kit framework.

Here’s a demo of what we’re going for by the time I’m finished with this article:

If you’d like to tinker with the code for yourself, you can download the example project:

Resources

Event Tracker – Create Calendar

Import EventKit

Step 1 in this whole process will be to import EventKit at the top of your Swift file:

1import UIKit
2import EventKit
3
4// ...

Importing EventKit gives us access to everything we need to work with calendars.

General outline for creating a local calendar

Now, we’ll proceed with creating a local calendar on the user’s device. It’s important to note that there are other kinds of calendars that you can create. For example, you can create calendars that sync with iCloud. For now though, we’re going to narrow the focus down to just creating the calendar on the user’s local device.

Here’s the general outline (and then some code):

Create an EKEventStore instance
Create a new EKCalendar instance using that event store instance
Configure the new calendar’s title
Wire up the new calendar’s source
- Obtain a list of the available sources from the event store instance
- Filter that list down to the EKSourceTypeLocal source type
- Assign it to the calendar’s source property
Save the calendar using the event store instance
Handle any problems that might have occurred

Code example

That’s the general outline… Now for the code!

 1// Create an Event Store instance
 2let eventStore = EKEventStore();
 3
 4// Use Event Store to create a new calendar instance
 5// Configure its title
 6let newCalendar = EKCalendar(forEntityType: .Event, eventStore: eventStore)
 7
 8// Probably want to prevent someone from saving a calendar
 9// if they don't type in a name...
10newCalendar.title = "Some Calendar Name"
11
12// Access list of available sources from the Event Store
13let sourcesInEventStore = eventStore.sources 
14
15// Filter the available sources and select the "Local" source to assign to the new calendar's
16// source property
17newCalendar.source = sourcesInEventStore.filter{
18    (source: EKSource) -> Bool in
19    source.sourceType.rawValue == EKSourceType.Local.rawValue
20}.first!
21
22// Save the calendar using the Event Store instance
23do {
24    try eventStore.saveCalendar(newCalendar, commit: true)
25    NSUserDefaults.standardUserDefaults().setObject(newCalendar.calendarIdentifier, forKey: "EventTrackerPrimaryCalendar")
26} catch {
27    let alert = UIAlertController(title: "Calendar could not save", message: (error as NSError).localizedDescription, preferredStyle: .Alert)
28    let OKAction = UIAlertAction(title: "OK", style: .Default, handler: nil)
29    alert.addAction(OKAction)
30    
31    self.presentViewController(alert, animated: true, completion: nil)
32}

The most confusing part of the code above for me was obtaining the right source to assign to the new calendar’s source property. Let’s unpack that for a second…

Obtaining and assigning the calendar’s source

The eventStore instance gives us the ability to query for a listing of its relevant calendar source types. But why are we going to the event store just to get a list of all the sources so that we can filter it down to just the one we want? Well, because this is the only way to get EKSource instances! Take a look at this quote from the Apple Documentation:

You do not create instances of EKSource. You retrieve EKSource objects from an EKEventStore object. Use the sources property to get all the EKSource objects for an event store, and use the methods in this class to access properties of the source object. (emphasis added)

So that answers the question of why we query the event store for that list of source types. But now, how do we narrow that list down to the one we want? That’s where the call to filter comes in…

First let’s isolate that code segment from the rest so it’s clear what we’re analyzing:

1newCalendar.source = sourcesInEventStore.filter{
2    (source: EKSource) -> Bool in
3    source.sourceType.rawValue == EKSourceType.Local.rawValue
4}.first!

The goal of this code is to take the list of sources in the event store, and filter them so that only the one matching the value of EKSourceTypeLocal is returned. This is easily accomplished using the filter function on the array of EKSources that’s returned by the event store.

But filter also returns an array, so to get the single source we’re looking for, we’ll simply grab the first element out of the array filter returns, and assign it to the new calendar’s source property. There are no duplicated EKSourceTypes in the list returned by the event store, so our filter expression should only return one match wrapped in an array.

That’s it for configuring the calendar. The remainder of the code uses the event store instance to save the calendar, and handle any errors that might occur with the save process.

Saving the calendar identifier

One last thing to note is that if you’re creating a calendar for your app to store events in, you probably want to stash the calendar’s identifier value somewhere, so that you can query the event store for the calendar directly, at a later point in time.

Using NSUserDefaults.standardUserDefaults() is a convenient way to store this calendar identifier value. The code to pay attention to is highlighted in this snippet:

 1// ...
 2
 3// Save the calendar using the Event Store instance
 4do {
 5    try eventStore.saveCalendar(newCalendar, commit: true)
 6    NSUserDefaults.standardUserDefaults().setObject(newCalendar.calendarIdentifier, forKey: "EventTrackerPrimaryCalendar")
 7} catch {
 8    let alert = UIAlertController(title: "Calendar could not save", message: (error as NSError).localizedDescription, preferredStyle: .Alert)
 9    let OKAction = UIAlertAction(title: "OK", style: .Default, handler: nil)
10    alert.addAction(OKAction)
11    
12    self.presentViewController(alert, animated: true, completion: nil)
13}

So assuming that the calendar was saved successfully without error, we’ll simply access the standard user defaults, and insert a new object (our calendar’s identifier) for a key that we’ll use to retrieve the identifier again later.

Wrapping up

Having the ability to create a calendar for an iOS application using Event Kit is a powerful thing if you’re wanting to take advantage of some of the built-in event-related features of the iOS platform. In this article we saw how to create a calendar using Event Kit and Swift. Additionally we analyzed some of the less-than-intuitive pieces of accessing the event store for a list of sources. We concluded by saving the new calendar’s identifier to NSUserDefaults so that we could easily retrieve the calendar from the event store at a later time.

You might also enjoy…

Improvements to Unit Testing in Swift with Xcode 7

Wed, 10 Jun 2015 17:43:09 +0000

One of the most exciting things that’s come out of WWDC 2015 is the fact that unit testing in Swift has been greatly simplified. The latest announcements have actually rendered a few of my articles on the subject obsolete, once Xcode 7 is in full circulation among the Swift developer community.

If you’re using Xcode 6.x, you may still find use in a couple of my previous articles:

If you’re jumping headlong into Xcode 7 world, setting yourself up for unit testing is incredibly simple. Essentially, all internal and public Types (and members of those Types) are visible to your unit test project when you import the module using the @testable keyword in front of the import. With Xcode 7, there’s no reason to change any of the access modifiers on your Types/members to support testing.

@natashatherobot has an excellent 3-step write-up that I won’t repeat here. To summarize though, you’ll simply…

Code your Types (classes/structs/enums) using the default internal access.
Add an import statement to the file containing your XCTestCases. There’s special syntax for this now: @testable import AppName/ModuleName
Begin unit testing with access to all public and internal Types and members!

Access Sub-Controllers from a UINavigationController in Swift

Tue, 02 Jun 2015 17:37:44 +0000

The sequence of accessing a UINavigationController's first child from within the AppDelegate or within prepareForSegue(_:sender:) always gets me. Here are a few quick snippets to help you and I quickly get up and running when working with navigation controllers in our Swift applications:

AppDelegate

Every iOS application has one root view controller that’s presented when the app finishes its launch process. Suppose we’re building a navigation controller-based app… that is, we’re building an app where the first (root) view controller is a UINavigationController. In our Storyboard, we’ve set up a Scene with some UI controls with a view controller and some properties, and we’ve embedded that view controller in a navigation controller.

What if we want to set some of the view controller’s properties after the app launches? How could we go about doing that?

I tend to always think of the “first view controller” as the first Scene in the Storyboard where I’ve set up UI components. To iOS, however, the navigation controller is actually the first (or root) view controller.

When an app incorporates a navigation controller as its first (root) view controller, we end up needing to do a little digging into the view controller hierarchy to get access what we might perceive as the true “first view controller”.

Digging for the first view controller

Here is a snippet of how to dig into the UINavigationController's view controller hierarchy to grab the first one and set some fictitious properties on it, all from within the AppDelegate:

 1class AppDelegate: UIResponder, UIApplicationDelegate {
 2
 3    var window: UIWindow?
 4
 5
 6    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
 7        // Override point for customization after application launch.
 8        
 9        let navigationController = window?.rootViewController as! UINavigationController
10        let firstVC = navigationController.viewControllers[0] as! NameOfFirstViewController
11        // set whatever properties you might want to set
12        // such as an NSmanagedObjectContext reference
13
14        return true
15    }
16
17    // ...
18}

So the workflow goes like this:

Get the window’s root view controller (which is the navigation controller in our case)
Get the navigation controller’s first view controller from its array of view controllers (which is what I always think of as the “first” view controller)
Set whatever properties you need to set

Note: With iOS 13, the code to access the root view controller needs to go in your app’s SceneDelegate.

You may be worried about the usage of implicitly unwrapped optionals in this snippet. I tend to avoid them wherever possible too, but I used them here because I reasoned that my navigation controller-based app hinges on the fact that the root view controller of the application is a UINavigationController. Something so fundamental to the app warranted my usage of the implicitly unwrapped optionals, since changing the navigation paradigm of the app would probably break things anyway.

If you’re not convinced by that line of reasoning, no worries – you can switch out some of the ! operators for ? operators and add in some if-let syntax to protect against encountering nil. For example:

 1class AppDelegate: UIResponder, UIApplicationDelegate {
 2
 3    // ...
 4    if let navigationController = window?.rootViewController as? UINavigationController {
 5        if let firstVC = navigationController.viewControllers[0] as? NameOfFirstViewController {
 6            firstVC.someProperty = someValue
 7        }
 8    }
 9    // ...
10}

Prepare for segue

What about in prepareForSegue(_:sender:)? When would this even be necessary?

Well, suppose that we have an app which segues into a navigation controller. We may need to pass some data off the next view controller, but that “next view controller” is technically the navigation controller, not the controller where our properties are declared.

In similar fashion to the AppDelegate situation, we want to dig into the navigation controller’s view controller hierarchy to access the first child so that we can pass the data along. Here’s an example implementation:

 1public class ViewController: UIViewController {
 2
 3    // ...
 4    override public func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
 5        
 6        let destinationVC = segue.destinationViewController as! UINavigationController
 7        let nextViewController = destinationVC.viewControllers[0] as! SecondViewController
 8        
 9        nextViewController.someProperty = someValue
10    }
11    // ...
12}

The only thing that really changes between the AppDelegate example and the prepareForSegue example is where we obtain the UINavigationController from. In AppDelegate, the navigation controller comes from the window’s root view controller. In prepareForSegue it comes from the segue’s destination view controller.

After that, though, the process for grabbing the first child of the navigation controller is the same.

Wrapping up

Accessing a navigation controller’s view controller hierarchy was just vague enough for me to write this little reference for myself, but I hope you benefited from it as well!

Sync Table View Data: NSFetchedResultsController and Swift

Fri, 29 May 2015 03:20:54 +0000

Updated on September 23, 2015 – Swift 2.0

My goal with this article is to help you utilize the full power of NSFetchedResultsController.

This is a continuation on a series of articles I’ve written on Core Data and NSFetchedResultsController, so you may want to check out those previous posts to get an idea of where I’m picking up in this walk-through. Previously I touched on how to seed a Core Data database, and how to take that data and display it in a table view with an NSFetchedResultsController.

As with the previous posts, I’m providing an example Xcode project over at GitHub, so feel free to follow along with the live working example:

Resources

Sync Table View Example Project

In this installment to the series, I want to answer the question, “How do I update the rows in a table view when I add or remove objects from the Core Data database?” I will show how to implement the NSFetchedResultsControllerDelegate protocol, which is the key to automatically synchronizing changes made to your Core Data persistent store with a table view.

Examining the NSFetchedResultsControllerDelegate protocol

The NSFetchedResultsControllerDelegate protocol is the piece of the puzzle that helps us update a table view with changes made to the Core Data persistent store. There are five methods that we’ll be taking a look at:

controllerWillChangeContent(_:)
controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:)
controller(_:didChangeSection:atIndex:forChangeType:)
controller(_:sectionIndexTitleForSectionName:)
controllerDidChangeContent(_:)

The two methods that are responsible for doing the actual updates to the table view’s structure are controller(_:didChangeSection:atIndex:forChangeType:) and controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:). If some of the changes to the table view result in new sections being created, controller(_:sectionIndexTitleForSectionName:) will help give it an appropriate title (and make sure the other sections keep their appropriate titles as well).

controllerWillChangeContent(_:) and controllerDidChangeContent(_:) help inform the table view that changes are about to happen / just finished happening. Sandwiching the primary “didChangeObject” and “didChangeSection” protocol methods with these two methods allows the table view to animate in all of the changes to its structure in one batch.

So, the general structure of the NSFetchedResultsControllerDelegate section of your source file might look like this:

 1// MARK: NSFetchedResultsControllerDelegate methods
 2public func controllerWillChangeContent(controller: NSFetchedResultsController) {
 3    self.tableView.beginUpdates()
 4}
 5
 6public func controller(
 7    controller: NSFetchedResultsController,
 8    didChangeObject anObject: AnyObject,
 9    atIndexPath indexPath: NSIndexPath?,
10    forChangeType type: NSFetchedResultsChangeType,
11    newIndexPath: NSIndexPath?) {
12        
13        // implementation to follow...
14}
15
16public func controller(
17    controller: NSFetchedResultsController,
18    didChangeSection sectionInfo: NSFetchedResultsSectionInfo,
19    atIndex sectionIndex: Int,
20    forChangeType type: NSFetchedResultsChangeType) {
21    
22        // implementation to follow...
23}
24
25public func controller(controller: NSFetchedResultsController, sectionIndexTitleForSectionName sectionName: String) -> String? {
26    return sectionName
27}
28
29public func controllerDidChangeContent(controller: NSFetchedResultsController) {
30    self.tableView.endUpdates()
31}

controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:)

This is the method that governs how we want to handle the rows in a table view when the synchronization would require inserting rows, updating existing ones, removing them, or reordering them.

I’ll give you the implementation and then point out a couple of “gotchas” and expound a little more. Recall that we’re working with a sample app named “Zootastic”, so if you see references to Animals in the example, you’ll know why. :]

 1public func controller(
 2        controller: NSFetchedResultsController,
 3        didChangeObject anObject: AnyObject,
 4        atIndexPath indexPath: NSIndexPath?,
 5        forChangeType type: NSFetchedResultsChangeType,
 6        newIndexPath: NSIndexPath?) {
 7            
 8            switch type {
 9            case NSFetchedResultsChangeType.Insert:
10                // Note that for Insert, we insert a row at the __newIndexPath__
11                if let insertIndexPath = newIndexPath {
12                    self.tableView.insertRowsAtIndexPaths([insertIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
13                }
14            case NSFetchedResultsChangeType.Delete:
15                // Note that for Delete, we delete the row at __indexPath__
16                if let deleteIndexPath = indexPath {
17                    self.tableView.deleteRowsAtIndexPaths([deleteIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
18                }
19            case NSFetchedResultsChangeType.Update:
20                if let updateIndexPath = indexPath {
21                    // Note that for Update, we update the row at __indexPath__
22                    let cell = self.tableView.cellForRowAtIndexPath(updateIndexPath)
23                    let animal = self.fetchedResultsController.objectAtIndexPath(updateIndexPath) as? Animal
24                    
25                    cell?.textLabel?.text = animal?.commonName
26                    cell?.detailTextLabel?.text = animal?.habitat
27                }
28            case NSFetchedResultsChangeType.Move:
29                // Note that for Move, we delete the row at __indexPath__
30                if let deleteIndexPath = indexPath {
31                    self.tableView.deleteRowsAtIndexPaths([deleteIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
32                }
33                
34                // Note that for Move, we insert a row at the __newIndexPath__
35                if let insertIndexPath = newIndexPath {
36                    self.tableView.insertRowsAtIndexPaths([insertIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
37                }
38            }
39}

Right away you’ll notice we enter a switch on the type parameter of the method. There are four options possible in the NSFetchedResultsChangeType enum: Insert, Delete, Update, and Move.

Beware of a few common gotchas with each case of the switch:

First of all, notice that first argument of the majority of the tableView methods takes an array of NSIndexPaths. Be sure to wrap your argument in [ and ] to create an array.
Pay extra attention to which index path parameter you’re referencing in each case. For insert, the goal is to add a row at the newIndexPath. For Delete, the goal is to remove the row at indexPath. Move will require a deletion of the indexPath and an insertion at the newIndexPath. Getting these mixed up will cause runtime errors, so pay close attention here!

controller(_:didChangeSection:atIndex:forChangeType:)

If your table view only has one section, you don’t need to worry with this one.

If your table view has multiple sections, you want to make sure and implement this protocol method – if you fail to do so and the change to the persistent store results in adjustments to the table view that can’t be handled, runtime errors can occur. For example, deleting all rows in a section would result in the section needing to be deleted as well, but without this protocol method being implemented, the update to the table view can’t be made and the app crashes.

Once again, I’ll throw the code your way and follow up with commentary:

 1public func controller(
 2    controller: NSFetchedResultsController,
 3    didChangeSection sectionInfo: NSFetchedResultsSectionInfo,
 4    atIndex sectionIndex: Int,
 5    forChangeType type: NSFetchedResultsChangeType) {
 6    
 7        switch type {
 8        case .Insert:
 9            let sectionIndexSet = NSIndexSet(index: sectionIndex)
10            self.tableView.insertSections(sectionIndexSet, withRowAnimation: UITableViewRowAnimation.Fade)
11        case .Delete:
12            let sectionIndexSet = NSIndexSet(index: sectionIndex)
13            self.tableView.deleteSections(sectionIndexSet, withRowAnimation: UITableViewRowAnimation.Fade)
14        default:
15            ""
16        }
17}
18
19public func controller(controller: NSFetchedResultsController, sectionIndexTitleForSectionName sectionName: String?) -> String? {
20    return sectionName
21}

For this one, we’re only implementing code for Insert and Delete. The necessary information to insert a section or remove a section (ie, the sectionIndex) comes as a parameter to the method.

We utilize an NSIndexSet to wrap up the section that needs to be inserted or deleted and pass it to the table view’s insertSections() and deleteSections() methods, respectively.

You might also enjoy…

Swift How-To: Setting up a Table View

Tue, 19 May 2015 02:31:38 +0000

Think of this screencast as the “Hello World” of creating a view controller with a table view. I cover organizing things in the Storyboard, Auto Layout constraints, and the implementation of the data source protocol methods for a table view.

Screencast

Screencast Transcript

[0:01]

Hi, I’m Andrew from andrewcbancroft.com.

I use table views fairly often in my examples, so I’ve decided to create a short walkthrough of how to set up a table view in Swift.

Think of this as the “Hello World” of creating a view controller with a table view.

[0:16]

In this walkthrough, I’m using Xcode 6.3.1, which has me writing Swift 1.2 syntax in a couple of spots.

[0:24]

To get started, I’m going to drop into the search bar of the Object Library, which is in the Utilities Pane to hunt for a table view.

Once I’ve narrowed the results and located the Table View control, I’ll click and drag one onto my Storyboard scene.

[0:41]

With the table view in place, filling the entire scene, I’ll control + click and drag up to the yellow View Controller icon to wire up my the table view’s dataSource… and delegate properties.

[0:56]

Now I need to connect the table view to my View Controller source file. To bring up the assistant editor, I’ll option+click the ViewController.swift file in the Project Navigator.

[1:06]

With the table view and the source side by side, once again, I’ll control + click the table view, and drag over to the ViewController source file to create an IBOutlet property for my table view.

[1:21]

Next up is to specify that my ViewController class will conform to the UITableViewDataSource protocol… and the UITableViewDelegate protocols.

[1:31]

Of course, at this point, I haven’t actually implemented any of the required protocol methods, so I get a compiler error saying so.

I’ve written up a handy UITableViewDataSource cheat sheet over at my website (andrewcbancroft.com). I’ll go grab that code and paste it into my View Controller.

[1:51]

Here I am at andrewcbancroft.com – I’ve searched for “UITableViewDataSource” and located my cheet sheet.

[2:02]

Scrolling down, I find the code I need, switch the code snippet plugin to “raw” mode, select everything, and copy.

[2:12]

Switching back over to my Xcode window, I paste the code snippet in.

[2:16]

As I mentioned in the beginning, this walkthrough can be thought of as the “Hello World” of table view setup. With that in mind, for now, I’ll create a dataSourceArray with some dummy data in it, just to get things compiling and displaying data.

[2:31]

Now that I’ve got the data source geared to go, I need some cells to display data in.

For this task, I’ll close the assistant editor…

Next, I’ll click to open the document outline. I find that working with the view hierarchy is much easier to manipulate using this outline, rather than clicking to try and select the right thing in the Storyboard Scene.

[2:55]

I’ll select the table view, and open the Utilities pane to get access to the Attributes inspector.

[3:01]

I’m going to configure this table view to have one kind of prototype cell.

[3:06]

Increasing the Prototype Cells count added a new node to the document outline’s view hierarchy.

I’ll expand the Table View and click on the Table View Cell to do a bit more configuration.

[3:19]

I’ll set the Style to Basic…

Then I’ll give it an identitifer of “BasicCell”.

I need this “BasicCell” string for one of my other data source proocol methods, so I’ll select it, and copy it.

[3:37]

Back in my ViewController.swift source file, I’ll paste that “BasicCell” string as the argument to dequeReusableCellWithIdentifier.

[3:48]

The last step to get things wired up is to set the cell’s textLabel.text property.

I’ll use the dataSourceArray’s values here.

Simply indexing into the array at the indexPath.row value that’s currently being rendered in the table view will grab the string out of the array and assign it to the textLabel.text property of the cell.

[4:13]

When I run the app and observe the table view’s behavior, I’m not quite satisfied with it. The status bar overlaps the rows and makes the text hard to read.

Additionally, the table view doesn’t extend all the way to the bottom when I run it in the iPhone 6 sized simulator.

[4:30]

I’ll stop the app and make an adjustment in the Storyboard.

[4:34]

Selecting the table view from the document outline will allow me to grab the top edge and drag the hight downward slowly until it “snaps” into place where the bottom of the status bar would appear to be.

[4:48]

Next, I’ll set some constraints. Within the document outline, I’ll control + click from the Table View to the View and set constraints for “Top Space to Top Layout Guide”, Center Horizontally, Center Vertically, and Equal Widths.

[5:17]

Running the app one more time gives me the behavior I want!

[5:31]

Thanks for watching – I have other resources r elated to Swift and iOS development at andrewcbancroft.com, and you can find me on Twitter: @andrewcbancroft

Beginner’s Guide to Event Kit in Swift – Requesting Permission

Thu, 14 May 2015 20:37:52 +0000

Updated on October 26, 2016 – Swift 3.0

EventKit provides a set of classes for accessing and manipulating a user’s calendar events and reminders. In the tutorial that follows, my goal is to walk you through the first steps of setting up an app that utilizes EventKit. I will demonstrate how to request permission to the user’s calendar and show a couple of examples for how to handle the user’s response (for when they grant access, or deny it).

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

Example scenario

Let’s start by proposing a basic scenario to serve as this tutorial’s example.

Suppose that we’re building an app that, for now, has a single View Controller. We’d like this View Controller to display a list of calendars if the user grants us permission to do so. If they deny permission, we’d like to show a message to them that indicates that our app can’t function without this permission, and we’ll allow them to click a button to grant us permission in the Settings of their device.

I’ve created such an app as an example – jump over to GitHub to grab the code and explore. Read on for an explanation of some of the finer points of the setup and code.

Resources

Example Xcode Project (Swift 2.3 | Swift 3.0)

Storyboard setup

One of the first things you’ll deal with in EventKit is the need to set yourself up with a UI to handle the different responses that the user can give you on that first application launch when you ask, “Can we access your calendar?”. We’ll get to the particulars of how request that permission shortly. But first, let’s dissect how we might arrange a Storyboard with some views that do the right thing for a given response to that permission prompt.

The user can either grant permission, or deny permission to interact with their calendar or reminders. We need to be prepared for either scenario.

Tableview for the calendar list for when access is granted

I’m feeling optimistic today, so let’s begin with the case where the user grants us permission to their calendar from the get-go.

When the user grants us permission, we’d like to list out their calendars inside a table view. We’ll worry with setting up the data source later in the tutorial. For now, we’ll drag over a table view from the Utilities pane.

To get the table view to fill the whole screen, I do a couple of things. Usually, when you drag one out from the Utilities pane, the table view will fill the whole scene in the Storyboard. From that layout, I drag the top edge down until it “snaps” to the line where I’d expect the bottom of the status bar to be positioned. Then I set the following constraints:

Center X
Center Y
Equal width to Superview
Top space to Top Layout Guide for height.

I’ve created a short screencast on setting up a table view if you’d like a complete walkthrough:

Resources

Here’s a detailed view of the constraints, along with a visual of what the Storyboard Scene looks like with the table view installed:

As a final note, I’ve set the hidden property of the table view to true in the Storyboard. I’ll toggle the table’s visibility based on the user’s granting or denying of the calendar access later, but I thought it was worth pointing out that the initial state of my table view in the example is hidden.

“Need permission” view for when access is denied

There will be times when a user denies access to the calendar before realizing that doing so essentially stops all the functionality provided by your app. If your entire app, or even just a portion of it requires access to function, you need a way to inform the user of this, and provide them a way to navigate to settings and grant access manually if possible.

The way I did this in the sample project was to organize a new View onto the Storyboard Scene which contains a label with some instructions, and a button that takes the user to the Settings page for our app when they tap on it.

Once again, some constraints are involved in getting things to appear correctly at run-time. I won’t go into the details of this here, since it’s likely that every implementation of this will be slightly different.

One thing I will point out though, is that the View’s alpha has been set to 0 so that I can perform a nice fade in transition if the user denies access. Here’s a look at the Scene with the invisible “NeedPermissionsView” installed:

The role of the Event Store

At the heart of EventKit is the EKEventStore. EKEventStore is the central “thing”. Creating an instance of EKEventStore provides developers with an API for performing various read/write operations on the user’s calendars and reminder lists.

A View Controller that interacts with the calendar should hold a reference to an EKEventStore instance. It’s easy to create one – here’s an example:

1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
2
3    let eventStore = EKEventStore()
4
5    // ...    
6}

Checking for calendar authorization

Once we have a reference to an EKEventStore instance, we can use it to do things like check whether or not the user has granted us permission to use their calendar. From there, we can make decisions about whether or not we need to request permission, and subsequently figure out which view to show (the table view or the need permission view).

Where we check for calendar authorization is important. My recommendation is to check each time the view appears (ie, in viewWillAppear(), because it’s completely possible that the user could grant access at first, switch to settings, and deny access. Our app would need to respond appropriately.

In the example project provided with this article, I’ve created a function named checkCalendarAuthorizationStatus(). Here a peek at what it does:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4    
 5    override func viewWillAppear(animated: Bool) {
 6        checkCalendarAuthorizationStatus()
 7    }
 8    
 9    func checkCalendarAuthorizationStatus() {
10        let status = EKEventStore.authorizationStatus(for: EKEntityType.event)
11        
12        switch (status) {
13        case EKAuthorizationStatus.notDetermined:
14            // This happens on first-run
15            requestAccessToCalendar()
16        case EKAuthorizationStatus.authorized:
17            // Things are in line with being able to show the calendars in the table view
18            loadCalendars()
19            refreshTableView()
20        case EKAuthorizationStatus.restricted, EKAuthorizationStatus.denied:
21            // We need to help them give us permission
22            needPermissionView.fadeIn()
23        }
24    }
25
26    // ...
27}

The key function here is EKEventStore's authorizationStatus(for:) function. Passing in EKEntityType.event is what corresponds to the user’s calendar. If we wanted to check for access to their reminders, we’d use EKEntityTypeReminder.

The possible EKAuthorizationStatus enumeration values are simply switched over – the logic to be performed is encapsulated in separate functions for ease of readability.

Let’s step through each of those functions one by one…

Update Info.plist for iOS 10 support

Apple now requires us to have a key/value pair in Info.plist that provides a description to the user as to why our apps need access to their calendar.

To set this value, open your Info.plist file, and add a new key for “Privacy – Calendars Usage Description”:

The value that you provide for this plist key ends up being displayed in the alert that’s displayed when you request access.

Requesting access to calendars

As the title of this tutorial suggests, all things start here. Whenever our application loads and we call authorizationStatus(for:), the status that will be returned is notDetermined. It’s at this point that we’d like to request access to the calendar.

To do so, let’s dissect the requestAccessToCalendar function:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3   // ...
 4   
 5    func requestAccessToCalendar() {
 6        eventStore.requestAccess(to: EKEntityType.event, completion: {
 7            (accessGranted: Bool, error: Error?) in
 8            
 9            if accessGranted == true {
10                DispatchQueue.main.async(execute: {
11                    self.loadCalendars()
12                    self.refreshTableView()
13                })
14            } else {
15                DispatchQueue.main.async(execute: {
16                    self.needPermissionView.fadeIn()
17                })
18            }
19        })
20    }
21
22    // ...
23}

Our EKEventStore instance provides a function called requestAccess(to:). Once again, passing in EKEntityType.event is what signals that we’re requesting access to the calendar. The rest of the interesting parts are found in the completion closure that we provide.

There are three main things to note with this portion of the implementation:

The two parameters that are passed in to the closure is a Bool indicating access was granted (true) or denied (false). The second is an NSError.
We need to call dispatch_async() and indicate that we want to jump back over to the main queue to execute our UI refreshes.
self.needPermissionView.fadeIn() utilizes a UIView extension from my post, Fade In / Out Animations as Class Extensions in Swift.

Access granted! Load calendars and refresh table view

When access is granted, we can call the eventStore instance’s calendarsForEntityType function and pass it EKEntityType.event to grab an array of the user’s calendars to display in our table view. Here’s a look:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    var calendars: [EKCalendar]?
 6
 7    // ...
 8    
 9    func loadCalendars() {
10        self.calendars = eventStore.calendars(for: EKEntityType.event)
11    }
12    
13    func refreshTableView() {
14        calendarsTableView.isHidden = false
15        calendarsTableView.reloadData()
16    }
17
18    // ...
19}

Access denied – Show needs permission view

When access is denied, we need to unveil the “Needs Permission View” we created in our Storyboard Scene.

Recall that in that view, there’s a button to direct the user to the Settings page for our app so that they can easily grant access to the calendar from there. That button is wired up to an IBAction. Here’s an example implementation of that IBAction:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    @IBAction func goToSettingsButtonTapped(_ sender: UIButton) {
 6        let openSettingsUrl = URL(string: UIApplicationOpenSettingsURLString)
 7        UIApplication.shared.openURL(openSettingsUrl!)
 8    }
 9
10    // ...
11}

Wrapping up

That pretty much completes the setup process for working with Event Kit! The remaining cases for the checkCalendarAuthorizationStatus() function simply re-use the functions I just dissected when exploring the requesting permission process.

I encourage you to head over to GitHub and dive into the code for yourself as you get started with utilizing Event Kit in your app!

You might also enjoy…

Strong, Weak, and Unowned – Sorting out ARC and Swift

Fri, 08 May 2015 18:01:09 +0000

I’m willing to bet that a good number of Swift developers struggle with the particulars of how strong, weak, and unowned affect the run-time behavior of their code. I, myself, wouldn’t want to have to give an explanation of the finer points of Automatic Reference Counting (ARC) if my life depended on it.

I wanted to stop being unsure about the implications of typing one of those three words before variable / constant declarations, so I finally pulled up the Apple Documentation on ARC and began trying to digest the semantics. This article is an attempt to share what got sorted out in my brain as it regards ARC and Swift.

This article is long enough that I thought, “Why don’t I summarize my conclusions up front and then let folks read about how I got there if they so-desire”. So here you go: Conclusions first!

Conclusions

To determine if you even need to worry about strong, weak, or unowned, ask, “Am I dealing with reference types”. If you’re working with Structs or Enums, ARC isn’t managing the memory for those Types and you don’t even need to worry about specifying weak or unowned for those constants or variables.
Strong references are fine in hierarchical relationships where the parent references the child, but not vice-versa. In fact, strong references are the most appropraite kind of reference most of the time.
When two instances are optionally related to one another, make sure that one of those instances holds a weak reference to the other.
When two instances are related in such a way that one of the instances can’t exist without the other, the instance with the mandatory dependency needs to hold an unowned reference to the other instance.

To see how I arrived at this set of conclusions, read on or jump around!

ARC and memory management

For many, much of “memory management” feels like a huge black box.

The mystical nature of memory management is exaggerated by the fact that many of the languages we’re familiar with abstract it away. For the most part, we can simply write code and not think too hard about the number of bytes our object instances are using or how they get cleaned up when they’re done being used. It just works.

Automatic Reference Counting (ARC) is one of those abstractions over managing memory. It’s the methodology Apple employs to free up memory when class instances are finished using it.

ARC only applies to classes (so not structs or enums), because Automatic Reference Counting applies only to reference Types. Structs & enums are value Types, so ARC does not manage the memory associated with instances of those Types.

The question that begins the discussion of our featured keywords is, “How does ARC know when an instance is “finished using” the memory it borrowed?”

Strong references

Strong, weak, and unowned are keywords that describe the nature of a reference in the ARC paradigm.

All references are strong references by default unless otherwise specified. Most of the time, this is the right thing to do. Strong is always implied when you declare a variable or constant. You don’t need to type strong in Swift.

So what does the “strength” of a reference have to do with how ARC manages memory?

ARC doesn’t free up the memory being used by a class instance until all strong references to that instance are broken. How are strong references broken?

Strong references can be broken…

When a variable that references an instance of something is set to nil
When a parent variable that holds a reference to a child class instance is to nil it will break the reference to the parent and the child
When a variable or constant goes out of scope – for example, if something gets initialized inside a control-flow code segment like an if/else or inside a for loop, when execution moves past that code segment, the reference is broken and the memory is freed by ARC

Everything in ARC’s memory management model hinges on the number of strong references are connected to an instance. The moment that the number of strong references counts down to zero, the memory where that instance was stored is freed.

So where does weak and unowned come in?

Weak and unowned references

Weak and unowned references come into the picture when we start talking about the relationships that emerge between class instances.

Relationships between instances

Relationships between classes are core to the Object-Oriented paradigm. Whether you plan them or not, these relationships exist, and they affect the ARC memory management model.

So which kinds of relationships exist? Which ones warrant the use of weak and unowned?

Hierarchical relationships

Much of our programming in Swift involves hierarchical relationships. Things are often modeled in such a way that one class instance holds strong references to one or more child class instances, and those child class instances hold one or more strong references to other child class instances, and so on. The strong reference relationship in this type of situation flows in one direction: from parent to child.

In this arrangement, strong references are normal and fine. But what happens if, say, a child class were to hold a reference back to its parent? This is where we can get into trouble with ARC.

Optional, mutually dependent relationships

By the end of this section, my goal is to demonstrate the role of weak references.

When class instances depend on each other, that is, they both hold a reference to one another, it can be said that the instances are mutually dependent. Sometimes, the dependence isn’t required – in these cases, it makes sense for one instance to exist without a reference to the other, and vice-versa.

If we were talking database cardinality, we might say that the relationship is 0:1 both ways.

An example is always nice to have before us – This past week, a tornado hit a zoo here in Oklahoma, and a few exotic animals escaped, so the theme is on my mind.

In a zoo, an Animal lives in an Exhibit. Sometimes Exhibits may be vacant. They could be cleaning it, or the Animal that lived there is sick or being moved, or a tornado hits it, etc.

Likewise, an Animal may not live in an Exhibit. It could be held in a temporary location while its Exhibit is being cleaned, or be in the process of being treated or transferred to another location, or it could have escaped the zoo due to a tornado, etc.

We could model this example as follows:

 1class Animal {
 2    let name: String
 3    let species: String
 4    init(name: String, species: String) { 
 5        self.name = name
 6        self.species = species
 7    }
 8
 9    var exhibit: Exhibit?  // notice the optional nature of exhibit
10}
11 
12class Exhibit {
13    let title: String
14    init(title: String) { self.title = title }
15
16    var animal: Animal? // notice the optional nature of animal
17}

Let’s consider the situation where an Animal is living in an Exhibit. It might be nice to traverse a relationship between them to get information about one or the other. So as we instantiate an Animal and an Exhibit, the next immediate step would be to assign the instances to each other’s corresponding property.

Now consider the situation that happened this week – a tornado hits the zoo and the Animal escapes from its Exhibit. Say that unlike this week, the Animal isn’t recovered (they actually got the animals that escaped back). Suppose that it roams the plains of Oklahoma in freedom. The zoo, in turn, has to close the Exhibit. To model this, we may simply set the Animal instance to nil and the Exhibit instance to nil.

Memory leak warning

The example just given is one that shows how it is possible to create a memory leak in your application. How?

It all has to do with ARC – remember that it only frees up memory for a class instance when there are zero references to it.

In our Animal – Exhibit example, both instances referenced each other. When we set the Animal instance to nil, the Exhibit instance still held a reference to it through its animal property.

In turn, since that Animal instance is still around, it holds a reference to the Exhibit instance through its exhibit property. So when we set the Exhibit instance to nil, the Animal still holds on to it.

Now we have a dilemma. While the Animal and the Exhibit continue to reference each other (so neither instance’s memory can be freed), nothing else does – there’s no way to access either instance any more. Thus, a memory leak is created.

But there’s hope! In this “Optional, mutually dependent relationship” scenario, this is where the keyword weak comes into play.

Breaking strong reference cycle

The situation just described is what’s known as a “strong reference cycle”.

Thankfully, there’s a way to break those cycles and avoid memory leaks.

In the situation where that optional mutually dependent relationship exists, such as between an Animal and an Exhibit, changing one of those instances reference to the other from strong to weak will break the cycle.

It doesn’t really matter which class holds the weak reference, just as long as one of them does.

 1class Animal {
 2    let name: String
 3    let species: String
 4    init(name: String, species: String) { 
 5        self.name = name
 6        self.species = species
 7    }
 8
 9    var exhibit: Exhibit?  // we'll hold a strong reference to the exhibit
10}
11 
12class Exhibit {
13    let title: String
14    init(title: String) { self.title = title }
15
16    weak var animal: Animal? // but notice - we're holding a _weak_ reference to the animal
17}

Making the Exhibit's animal property hold a weak reference to an Animal instance eliminates the possibility of a strong reference cycle.

So what about unowned?

Mandatory, one-way dependent relationships

By the end of this section, my goal is to demonstrate the role of unowned references.

There is one final category of relationship that pertains most immediately to the topic of ARC. There are times when two class instances are related to one another, but one of those instance cannot exist without the other.

Let’s continue with the zoo theme. Suppose that our zoo issues AnnualPasses to Visitors. A Visitor can come to the zoo without an AnnualPass, of course, and can thus exist on its own and happily enjoy the exhibits. An AnnualPass, however, is always issued to a Visitor and cannot exist without being associated with one.

To model this kind of relationship, we may define some classes as follows:

 1class Visitor {
 2    let name: String
 3    var annualPass: AnnualPass?
 4    init(name: String) {
 5        self.name = name
 6    }
 7}
 8 
 9class AnnualPass {
10    let number: UInt64
11    unowned let passholder: Visitor // notice the use of an _unowned_ reference
12    init(number: UInt64, passholder: Visitor) {
13        self.number = number
14        self.passholder = passholder
15    }
16}

Notice a couple of things:

The Visitor holds an optional strong reference to an AnnualPass instance
The AnnualPass holds a non-optional unowned reference to a Visitor instance

Modeling things this way also eliminates the possibility of a strong reference cycle by allowing the strong reference count to reach zero when a Visitor variable is set to nil.

Conclusions

I know I stated these at the beginning, but I’ll restate them here just for completeness…

To determine if you even need to worry about strong, weak, or unowned, ask, “Am I dealing with reference types”. If you’re working with Structs or Enums, ARC isn’t managing the memory for those Types and you don’t even need to worry about specifying weak or unowned for those constants or variables.
Strong references are fine in hierarchical relationships where the parent references the child, but not vice-versa. In fact, strong references are the most appropraite kind of reference most of the time.
When two instances are optionally related to one another, make sure that one of those instances holds a weak reference to the other.
When two instances are related in such a way that one of the instances can’t exist without the other, the instance with the mandatory dependency needs to hold an unowned reference to the other instance.

Testing is to Software as Experiment is to Science

Thu, 30 Apr 2015 04:01:24 +0000

The principle of science, the definition, almost, is the following: The test of all knowledge is experiment.

The sole test of the validity of any idea is experiment.

These quote came from Chapter 1 and Chapter 2 of the Feynman Lectures on Physics.

I’m not a physicist, but the software developer in me resonated with the connection between experimentation and validation of what we know about the world around us. Almost immediately, I related it to the world of software.

Validity is confirmed by experiments (tests)

The universe around us is an immense mystery. We have many ideas about it, but the ideas that are validated by experiment are the ones we cling to more tightly than the ones that remain in the realm of guess and theory.

How do we know that things are valid within a software application? The answer, of course, is by testing that software… experimenting with it, if you will, and observing the outcomes of those experiments.

Your software is a universe of mystery until it’s tested.

Repeated experiments (tests) are most valuable

Experiments that are conducted multiple times are significantly more valuable than a single observation made from a single experiment. Repeated experiments increase the probability that what was observed was not an accident, but was truly the result of correct procedure validating a correct hypothesis. Performing the experiments as identically as possible to one other is the key to trusting the results.

Likewise, repeated testing of software is far more valuable than testing it once and walking away. Repeated tests done identically over time provide the reassurance we need to know for sure that our software behaves as we expect as it morphs to accommodate new ideas and new needs.

Sure, we could spin up the app in a simulator and click/tap through it to see if pressing [Button X] does what its label implies it will do. But I’ve heard it said that if we have to do it more than once, it should be automated.

Testing is one of those things that needs to be done often. Pretty much any time the app’s code changes (even just a little bit!), there is warrant to check and make sure the universe as we knew it still obeys all the laws we previously discovered.

Repeated tests are just as valuable to software as repeated experiment is to science. The more we can automate them, the greater the consistency in our repeated observations of how the software behaves.

Experimentation (testing) is a creative effort

Designing the right experiment to elicit the right conditions to make that one critical observation is a creative process. Sometimes, scientists have to go to great lengths to make their observations. But they all find it worth it when their experiment yields results!

I work with some amazing scientists on a day-to-day basis. Watching them work and hearing about some of the things they have to do in order to test their ideas is so fascinating to me. For example, one of our Principal Investigators is making observations about how microgravity affects a plant’s cell walls. To do that, he had to literally launch his plant’s seeds into space! They’re aboard the International Space Station. Growing plants! In space! I’m blown away by these guys!

While we needn’t launch our code into space just to experiment with it, sometimes we have to get creative in order to make the observations we need to make from our code. Automated testing isn’t easy. Running the app and clicking a button and watching what happens with our own eyes is easy, but it’s tedious and I’m lazy!

Creating the right environment (in code) for a test to verify what it needs can take effort, but in the end, when the test yields results time after time after time, I’ve always found that it’s worth it!

Wrapping up

My hope is that seeing automated unit testing from a slightly different perspective has sparked some thoughts and ideas in your mind. How can you begin experiment with your code with automated tests? How can you begin to make repeatable observations about your code so that you know, for sure, that it works, even after you go about making changes to it as time goes along?

I’ve devoted a bit time to writing about unit testing in Swift since the language was released. I hope this article adds something unique to the collection and that it gets you motivated to validate your software universe with tests!

You might also enjoy…

Clarifying Swift Access Control (Hint: Swift Isn’t C#)

Fri, 24 Apr 2015 18:02:34 +0000

As it turns out, Swift isn’t C# (or Java or VB.Net or…)! My day job keeps me busy writing C#, so I’ll reference it as my go-to comparison language for this article. The conclusion, however, carries over to other languages that have access control modifiers.

I just spent the greater part of a week experimenting with Swift extensions. I was trying to figure out some seemingly strange behavior that they were exhibiting.

After publishing “3 Nuances of Swift Extensions”, I quickly learned that I had a fundamental misunderstanding of Swift access control, thanks to some observant folks in the Swift community.

What was the hiccup? Read on to find out where I went wrong…

How private is private?

One of the most surprising “nuances” from “3 Nuances of Swift Extensions” that I discovered was that if you define an extension within the same source file as another Type, the extension’s members can see the other Type’s private properties and functions! “Whaaat?? How is this possible?!”, I reacted.

Well… To restate the obvious, Swift isn’t C#… and it isn’t C# in more ways than just syntax.

Ever since access control modifiers were introduced in Xcode 6 Beta 4, I had it in my mind that public, private, and internal worked just like they do in C#. Sure, I read the blog article on access control published by the Swift team, but it was a mere cursory look. I basically saw the three key words and thought, “Ah, I got this… moving on!”

This was a fundamental mistake for me to make, and it goes to show that just because there are similarities between languages, it doesn’t mean the semantics of those similarities carry over.

Semantics of private

Private is the access modifier that got me all confused. The concept of public and internal carry over fairly nicely, but private is the one that’s fundamentally different between C# and Swift, so that’s where I’ll focus.

In addition to this article, recommend giving the Swift team’s original article on access control a very close read, just to make sure all the semantics of public and internal in Swift are clear as well.

Private and C#

In C#, private members of a Type are “truly” private. They are only visible within that Type. The member’s visibility is limited to the curly braces enclosing the Type’s implementation. That’s it. No subclass can see private members. No other Types can see those members, no matter which file those Types are defined in. Private is private.

Private and Swift

And then there’s Swift. Private takes on entirely different semantics in Swift, and herein lay my fundamental misunderstanding. It was obvious that I just didn’t “get it” if you read through the Nuances Article. [sigh]

In Swift, a private Type, or a public/internal Type’s private members are visible to anything else defined within the same file.

This isn’t a characteristic that’s limited to extensions. Anything defined in the same source file as something else can see everything. This is a shocker if you’re coming from C# or a similar language where the semantics of access control are used for encapsulation purposes.

Proof by example

So suppose you have a file named Types.swift, and within you have the following:

1private struct Person {
2    private let name: String
3}
4
5private struct Greeter {
6    private func greet(person: Person) {
7        println("Hi, I'm \(person.name)")
8    }
9}

If you’re a C# developer, you look at that code and immediately go, “Yeah, that’s not gonna work… name is private to Person and can’t be referenced outside that Type”.

But in Swift, this is totally legitimate. Even though Person is private, Greeter can see Person and initialize one, and it can see Person‘s private property, name.

Private in Swift simply limits visibility to Types and members within the same source file. Multiple Types defined in the same source file can see other private Types, as well as other Types’ private properties and functions. In other words, “private isn’t private”, if you’re thinking of private like a C# developer (or a developer familiar with other languages with access control modifiers similar to C#).

Wrapping up

There is a fundamental difference in the semantics of access control between C# and Swift.

In C#, we typically think of access control in terms of inheritance characteristics. The modifiers affect the Type and revolve around the Type and its interaction with other Types.

Swift, controls access to members in terms of source file and module. Types defined within the same source file see everything about each other, including private members. Internal Types and members expand visibility to anywhere within the same module. Finally, public access makes Types and their members visible everywhere, even to Types defined in other modules.

You might also enjoy…

3 Nuances of Swift Extensions

Wed, 22 Apr 2015 17:52:36 +0000

How often do we take an initial cursory look at some documentation, shake our heads and say, “Ok, sure! Got it!”, and then some time later get to the actual usage of that perceived understanding only to find out, “Woah – this is behaving differently than I expected! I wonder if the documentation says anything about this?!”

A few discussions I’ve had recently have prompted me to question what I thought I knew about Swift extensions. I have read documentation about extensions and I thought I understood them pretty thoroughly. However, these conversations, along with some experimentation done on my own revealed a few nuances that I didn’t pick up on before.

Update: Almost immediately after publishing this article, the Swift community chimed in and helped me figure out my fundamental hiccup which prompted the aforementioned experimentation in the first place. I’ve written a follow-up article called “Clarifying Swift Access Control”, describing that misunderstanding. I recommend giving that one a read to avoid making the same mistake I did!

Three nuances of extensions

In particular, the following three nuances challenged what I thought I knew about Swift extensions:

The visibility Swift extensions have into the Type they’re extending. Can they see things marked private, for example?
How that visibility is affected by where the extension is defined. If I have the source for a Type that I’m writing an extension for, does defining it within that same source file vs defining it in a separate file affect what it can “see”?
The default access modifiers of the extension’s “members” and how specifying them or not specifying them affect what an extension exposes as public API for the Type it’s extending.

Before I begin, suppose that I have a public struct called Person. It has some private properties, name, gender, and age. An enum encapsulates the idea of Gender. The struct looks something like this:

 1public struct Person {
 2    private var name: String
 3    private var gender: Gender
 4    private var age: Int
 5    
 6    public init(name: String, gender: Gender, age: Int) {
 7        self.name = name
 8        self.gender = gender
 9        self.age = age
10    }
11    
12    public func howOldAreYou() -> String {
13        return formattedAge()
14    }
15    
16    // private func, simply to show extension visibility traits in the analysis below...
17    private func formattedAge() -> String {
18        switch self.gender {
19        case .Male:
20            return "I'm \(self.age)."
21        case .Female:
22            return "Not telling."
23        }
24    }
25    
26    public enum Gender {
27        case Male
28        case Female
29    }
30}

Now, suppose that I wanted to extend Person and inspect the three nuances about the extension’s capabilities and behaviors that I introduced at the beginning of this article…

Extensions and visibility into extended Type

When I introduced that first nuance about visibility into the extended Type, I asked the question, “Can they see things marked private?” The answer surprised me at first: Yes…they can.

However, here’s where the second nuance comes in: It absolutely does matter where the extension is defined.

Defined within same file

Extensions defined within the same file as the Type they’re extending have access to private members of that Type.

For example, defining an extension to Person within Person.swift allows the extension to access private properties and functions! Who knew?!

1extension Person {
2    func getAge() -> Int {
3        return age // compiles, even though age is --private--
4    }
5    
6    func getFormattedAge() -> String {
7        return formattedAge() // compiles, even though formattedAge is --private--
8    }
9}

“What?? Why?”, I thought to myself…

My reasoning as to why extensions defined within the same file behave this way is because when it comes down to it, I could have just written the extension’s implementation as part of the Type itself and it would have had the same effect.

I’m in the source file of the Type I’m “extending”. So whether I write the additional functionality as an extension for the Type, or just define what would have been in the extension inside the Type, itself, the net effect is the same.

Therefore, the compiler essentially says, “I see this extension being defined, but there’s really no point. It’s in the same file that the Type is defined in… so the developer could have just written all this code within the Type itself… so I’ll let him/her refer to private code blocks.”

Update: My reasoning above reveals that I truly didn’t have an understanding of Swift access control. I recommend giving my followup article titled “Clarifying Swift Access Control” a read for more details!

Defined in a separate file

Moving the extension definition into a separate file, however, causes the extension to lose that visibility into the Type it’s extending.

Following the inverse of my previous reasoning about private visibility when the extension is defined within the same file, this behavior actually makes sense to me.

Most of the time, you’d be writing an extension for Types that you don’t have the source to. In that scenario, extensions would have the same visibility that any client of the Type’s exposed API would have, namely, the things marked public.

Default extension access control

The final nuance also yielded some semi-surprising results for me. Apple’s documentation says it, but until I experimented and saw it in action, I didn’t catch the nuance around the default access control modifiers applied to extensions.

Default access when no explicit access modifiers specified

In short, when you declare an extension but specify no explicit access modifiers (ie, you just use the default), the extension’s default access level depends on the access level of the Type it’s extending.

If the Type is public or internal, the extension’s implementation “members” will be internal by default. The “surprise” for me I think is that extensions for public Types have internal members by default, unless you specify otherwise.
If the Type is private, the extension’s implementation “members” will be private by default.

Here’s what the extension looks like if we analyze it from the perspective of using no explicitly declared access modifiers (note that to gain access to private properties and functions, I’m declaring the extension within Person.swift):

 1public struct Person {
 2    // ...
 3    
 4    // ...
 5}
 6
 7extension Person {
 8    func getAge() -> Int {
 9        return age
10    }
11    
12    func getFormattedAge() -> String {
13        return formattedAge()
14    }
15}

Using the default access modifiers as shown in the code snippet above exposes access to the extension’s new API to instances within the same module. However, it does not expose additional public API for the Type it’s extending to a client of that Type that’s in another module (for example, the unit test target, which is another Swift module).

Same Module

Different Module (test target)

For some reason, I had it in my head that if a Type that I’m extending is public, the extension’s members would default to public. I don’t know why I thought that, but thankfully my experimentation cleared up!

Default access when using default extension declaration, but specify public for implementation

Adding public access control modifiers to the extension implementation’s members makes those members visible everywhere (that is, both within the same module, and within the test target).

The location of the extension’s declaration, be it within the same source file as the Type it’s extending, or in a separate source file, does not matter in terms of what the extension exposes when adding public members… But only extensions declared within the same source file as the Type it’s extending can see private members of that Type, as we discovered previously.

Extensions declared in same and separate source files

Public extension members visible in different module (test target)

But notice that on the line where I’ve written extension Person { ... } that I haven’t specified an access control modifier for the extension, itself. I’ve only added public to its members. Even still, the new functions are visible to the test target which is a different module.

In other words, there’s no need to write public extension Person { ... }. Since Person is public, the extension just uses the Type’s access level for its own declaration.

Wrapping up

The three nuances about Swift extensions that were analyzed here were “surprising” enough to me to warrant some experimentation. My hope is that the analysis that was done will help clear up these subtleties for others who are struggling with understanding how Swift extensions behave!

You might also enjoy…

Testability Tip for Swift Developers – Public Over Private

Wed, 15 Apr 2015 18:52:11 +0000

Quite often in unit testing, especially when practicing Test-Driven Development, I find myself wanting to test every single line of code. When I run up against a private function, however, I often scratch my head and ask, “How am I supposed to test this??”.

Most experienced testers will tell you, “Don’t test private implementation – only public API”.

“Okay… But how, does that private function get tested?”, I always asked.

In this article, I intend to share a testability tip catered to the Swift developer community that helps alleviate this issue with testing private functions.

Testing and observability

Developers as clients of APIs

As developers, we are “clients” of APIs on a daily basis. We interact with other developers’ frameworks and libraries through the visible, observable, Application Programming Interface that they’ve exposed to us. It’s the way they’ve designed for us to interact with their code.

Notice three words that I chose in that introductory paragraph:

Visible
Observable
Exposed

If we are going to use another developer’s library, all we have as developers is the public interface that they’ve made visible to us… It’s the only observable thing we can look at and go, “Oh! Okay, to do this, I call that function”. The only thing exposed are the functions and properties that the developer intends for us to see.

Tests as clients of APIs

Have you ever viewed your unit test suite as a “client” of your code? It is!

And just like a developer, the unit tests in your test target interacts with your app’s API through the same visible, observable, interface that you’ve exposed to them.

If you start to personify your test target and think of it in terms of “just another client of your code”, you begin to see that it really doesn’t have any more visibility of your code than another developer would if he or she were consuming it.

All of this boils down to say, if it’s observable, it’s testable. Which means, the easiest and most natural code to test is public code.

Public over private (and internal)

So should everything be public instead of private or internal? Certainly not.

Object-oriented programming strives for data-hiding and encapsulation, so there are reasons to keep some things non-public.

Additionally, there are certain Swift compiler optimizations (which lead to run-time optimizations) that can be gained when you mark things in your Type as final. Using the private access modifier allows the compiler to infer that it is final because it’s narrowly scoped to the current Type only. These are handy things to know, but as is always the case with optimization, avoid premature optimization by measuring first to decide if you really need them.

Whenever possible, I prefer public over the other access modifiers to help enable testing for my apps.

So when is “whenever possible”?

Public when part of a Type’s reason for existence

Obviously, properties and functions that are part of a Type’s core purpose can be marked public. My practice is to decide, “Is this function why this Type exists?”. If so, I mark it as public.

Note also that the Type itself needs to be marked public if it’s going to be visible to your unit tests.

 1// Instead of this (default --internal-- access)...
 2class MyClass {
 3    func myFunc() {
 4        // Performs something essential to why MyClass exists
 5    }
 6}
 7
 8// Make things public...
 9public class MyClass {
10    public func myFunc() {
11        // Performs something essential to why MyClass exists
12    }
13}

Transition many private components to new Type

Having many private properties and functions can be an indication that there needs to be a new Type created to encapsulate those components. I’ve heard developers talk about this situation as one that “screams, ‘New Type!’”.

If we extract out sets of related private properties and functions into a new Type, those pieces of code are the reason that Type exists, and thus should be marked public. Testing, then, becomes a matter of writing unit tests for the new Type and its public API!

Even if you just have a few private code blocks in the Type you’re trying to test, it can sometimes make your testing life easier to transition them to a new Type as public components.

If I’m really uncomfortable marking functions public in the Type where they currently exist, creating a new Type and marking them public there is usually the better alternative, and it immediately enables testing for that set of code.

Testing non-public code

As I mentioned in the beginning, it’s not good to just haphazardly go through your code and “public all the things!!”. After appropriately marking fundamental functions public and transitioning sets of private functions to new Types where they can happily live as part of that Type’s public API, there will likely be a few private or internal things left over.

How do these get tested?

Well, ideally, these are small, simple, helper functions that are only useful when called within the Type you’re working on.

If these functions produce observable results in the places where they’re called, you end up testing these non-public components implicitly, that is, by testing the things that are public.

During the course of testing some public function which calls another non-public function, that non-public function’s logic will be executed. If the outcome of that function’s execution affects the Type’s state, or the output of its public parent function, those are the things that you’d be able to write unit tests for, because those are the “observation points”, so to speak.

Wrapping up

The bottom line is: observable == testable. Just like another developer, the suite of unit tests in your test target interacts with your app’s API through the visible, observable, interface that you’ve exposed to them. The more observable your API components are, the more testable your code becomes. Which is why I prefer public over private whenever possible!

You might also enjoy…

How Delegation Works – A Swift Developer’s Guide

Thu, 09 Apr 2015 01:43:55 +0000

Updated on October 11, 2016 – Swift 3.0

Delegation can be a difficult topic to wrap your head around. I found it easiest to break up posts on the topic to help readers who are new to the pattern grasp the concepts a little better. First, I analyzed what delegation is in “What is Delegation – A Swift Developer’s Guide”. If you’re looking for the “what is it?” behind the “how does it work?”, I recommend giving that first article a read.

Once the terminology is unpacked and a high-level overview of delegation as a design pattern is understood, the next logical place to turn is to the question, “How does delegation work?”. That is the focus of this article.

Introducing the players

For delegation to occur in software, you’d have a situation where one class (a delegat_or_ class) would give control or responsibility for some behavioral logic to another class called a delegate.

So how does one class delegate behavioral logic to another class? With iOS and Swift, the delegation design pattern is achieved by utilizing an abstraction layer called a protocol.

A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality.

Protocols as abstractions

I used the fancy term “abstraction layer” prior to the quote. What is that all about?

Protocols are an “abstraction”, because they do not provide implementation details in their declaration… Only function and property names. Like an outline, or as Apple puts it, a blueprint.

Protocols as blueprints

With a single blueprint, there can be many homes constructed. The fine details of their construction may differ, but in the end, houses of some similarity that satisfy the blueprint’s specifications are built.

So, too with a protocol: Many classes can be built that follow the protocol’s specifications. At the end of the day, the fine details of each class’ implementation (the stuff between the curly braces { ... }) may differ, but if they adopt the protocol, they’ll be similar in at least the fact that they provide the named behavior it specified.

Protocols as contracts

Another analogy from the legal world is popular for describing protocols: Protocols are similar to contracts. It’s this contractual idea that actually makes the most sense to me when it comes to delegation.

A contract is the “thing” in the middle of two parties who are trying to negotiate a deal. To one party, the contract is a guarantee of some terms that will be satisfied. To the other party, the contract is a set of obligations.

In the delegation design pattern, protocols serve the same kind middle-man role as a contract. To the delegat_or_ class, the protocol is a guarantee that some behavior will be supplied by the other party (the delegate). To the delegate class, the protocol is a set of obligations – things it must implement when it “signs the contract”, or in Swift terms, “adopts the protocol”.

While the person signing the contract probably gets something out of the deal, the focus in the analogy we’re making to protocols and the delegation pattern is on the person on the guarantee end.

That person, being guaranteed by the contract that certain terms will be executed by the person who signs the deal, is free to make decisions and take action based on that promise.

So, too with the class delegating to another class. The delegat_or_ class can make perform actions (call methods defined by the protocol) or make decisions (access properties defined by the protocol to use in its logic).

Listing the players

Stepping back from this description, we see three players involved:

A protocol defining the responsibilities that will be delegated
A delegat_or_, which depends on an instance of something conforming to that protocol
A delegate, which adopts the protocol and implements its requirements

Visualize the players

As you can see, there are a few moving parts to delegation. Sometimes it helps to visualize the players involved in the strategy. I created the following diagram for an analysis I wrote on NSNotificationCenter vs Delegation, but I think it gets the point across for this blog entry as well:

An example in code

Hopefully the explanation so far has provided some good groundwork to sort out how to accomplish the delegation design pattern in code. So how does it all get wired up?

Setting up the delegator

A delegat_or_ class typically defines a variable property with the word “delegate” somewhere in the name (oftentimes the property is simply named delegate if that’s explanatory enough). The Type of the variable property is the key to it all. The variable will be of Type whatever-you-named-your-delegate-protocol. So if I named my protocol MySpecialDelegate, I’d specify the Type of the delegate property to be MySpecialDelegate.

Setting up the delegate

The delegate class is what adopts the protocol and implements its requirements. In the class declaration, the name of the protocol(s) that the class intends to adopt are listed separated by commas after the name of the superclass (if the class inherits from a superclass):

class MyClass: SuperClass, Protocol1, Protocol2 { ... }

When the delegat_or_ class gets initialized, a second step is often to immediately assign an instance of the class that’s adopted the delegate protocol to its delegate property so that everything is “wired up”.

Delegation in practice

Working with the delegation pattern in practice usually involves interacting with the protocol from the delegate end of things. Most of the time, we’re working with Apple’s APIs (such as a UITableView or just about any other UI control they provide). We typically only require knowledge of the protocol’s definition so that the class we choose as our delegate can implement the right functions.

Complete example

There may be some situations where you may decide to follow Apple’s lead and use the delegation design pattern for your own code. Maybe you’re making a special UIView subclass or a special picker control (much like UIImagePickerController). Or maybe you’re into game development and would like to communicate from your SKScene back to the View Controller. These are just a few that came to mind, but they all present possibilities for utilizing the delegation strategy.

To give a simple example, suppose that we’ve decided to create a class to encapsulate all of the logic for a special rating picker control. We’d like to offer the ability to customize the picker some by allowing the user of our control to specify a preferred rating symbol. We’d also like to provide a feedback loop to notify the user of our control when certain events have occurred. Delegation is a great tool to provide both customization options and communication between classes. What would this example look like in code?

Create the protocol

First, the protocol:

1protocol RatingPickerDelegate {
2    func preferredRatingSymbol(picker: RatingPicker) -> UIImage?
3    func didSelectRating(picker: RatingPicker, rating: Int)
4    func didCancel(picker: RatingPicker)
5}

Notice how this protocol definition allows both the customization point and the feedback loop we were hoping for. It’s always nice for the delegate to have access to the public API of the instance calling its methods, so the RatingPicker (or UITableView or UIScrollView or whatever) is often passed along as an argument.

Create the delegator

With the protocol defined, our RatingPicker (the delegat_or_ in this case) can now set itself up to use that protocol:

 1// Disclaimer:  There is much more logic that would go into a real UIView subclass or a picker control in real life
 2// This example is contrived and is only meant to serve as a "shell" of what code could look like
 3// that uses a delegate within its implementation
 4
 5class RatingPicker {
 6    weak var delegate: RatingPickerDelegate?
 7    
 8    init(withDelegate delegate: RatingPickerDelegate?) {
 9        self.delegate = delegate
10    }
11 
12    func setup() {
13        let preferredRatingSymbol = delegate?.preferredRatingSymbol(picker: self)
14        
15        // Set up the picker with the preferred rating symbol if it was specified
16    }
17    
18    func selectRating(selectedRating: Int) {
19        delegate?.didSelectRating(picker: self, rating: selectedRating)
20        // Other logic related to selecting a rating
21    }
22    
23    func cancel() {
24        delegate?.didCancel(picker: self)
25        // Other logic related to canceling
26    }
27}

The delegate property is strongly typed to be a RatingPickerDelegate.

Since it’s optional here in this implementation, the delegate is not absolutely essential for the RatingPicker to work. If it were essential, we’d parameterize init and assign it during initialization.

I’ve used optional chaining to get at the delegate's methods if the delegate isn’t nil.

Choosing the delegate

Choosing the delegate class is the final decision to make. It’s not uncommon for a View Controller to take up the responsibility of being a delegate. In “Pick a Delegate, Any Delegate”, I attempted to show how it’s not necessary to use the View Controller as your one stop delegate shop. For this example, I’ll avoid giving the View Controller more responsibility than it needs and I’ll create a simple handler class to assume the delegated responsibilities:

 1class RatingPickerHandler: RatingPickerDelegate {
 2    func preferredRatingSymbol(picker: RatingPicker) -> UIImage? {
 3        return UIImage(contentsOfFile: "Star.png")
 4    }
 5    
 6    func didSelectRating(picker: RatingPicker, rating: Int) {
 7        // do something in response to a rating being selected
 8    }
 9    
10    func didCancel(picker: RatingPicker) {
11        // do something in response to the rating picker canceling
12    }
13}

Wrapping up

Once the terminology of delegation is unpacked, understanding how it works is the next logical step for grasping the design pattern as a whole. Here we explored all the players involved in the strategy and related protocols, which are integral to the strategy, to some real-world analogies. Finally, we took a look at how delegation works in practice, and demonstrated each role in delegation with code.

You might also enjoy…

Enums Instead of Booleans – An Example Implementation

Wed, 01 Apr 2015 12:00:52 +0000

This blog entry was inspired by Objc.io’s snippet titled “Enums instead of Booleans”. I really loved the clarity that using enumerations brought to even the simplest of examples that was presented in that snippet. If you haven’t seen it, check it out before continuing on!

Objc.io’s snippet focused primarily on the definition and consumption of the enumeration values. What I’d like to focus on here is the implementation of the thing that produces those values for the switch-case that will consume them later on.

Example scenario

To put an example before us, consider the following scenario:

Suppose that we’re building an app that utilizes a subscription-style service to deliver premium content.
Special things, such as providing access to the premium content, need to happen in the app if the user is a Subscriber in good standing.
Other things need to happen, such as denial of access to the premium content, if the user had a subscription, but it’s expired.
Finally, if the user has never had a subscription, we’d still like to deny access to the content, but perhaps offer them the opportunity to subscribe.

Using Objc.io’s idea as a springboard, we could program this in a couple of ways:

1 – We could define a few boolean properties throughout that would indicate the user’s subscription status:

isSubscriber
isSubscriptionExpired
isNonSubscriber

What I find interesting about this approach is that it’s not clear, from looking at the properties, that they’re all mutually exclusive. Can I be a subscriber whose subscription has expired? If my subscription expired, am I a non-subscriber?

It could be that I’ve chosen poor names for the properties, but if I wanted to make clear that the statuses are mutually exclusive, there’s a better way to encapsulate them. Objc.io helpfully pointed us in the direction of that better encapsulation method. Yep… you got it: enumerations!

2 – As the title of the blog entry signals, we could replace the booleans with an enumeration:

1public enum SubscriberStatus {
2    case CurrentSubscriber
3    case ExpiredSubscriber
4    case NonSubscriber
5}

Immediately, this clarifies the mutually exclusive part. Enumerations, by definition, expose mutually exclusive values. By defining the SubscriberStatus enumeration, I’ve made clear that my intent is to have someone be either a CurrentSubscriber, an ExpiredSubscriber, or a NonSubscriber, but not combinations of each.

Not only that, but rather than including complicated branching logic when I need to determine someone’s subscription status, I can simply switch-case over the enumeration possibilities and perform the appropriate behavior.

 1func checkSubscriberStatusForRegistrant(registrant: Registrant) {
 2    // We're coming to the definition of Registrant...
 3    // In fact, Registrant's implementation is the goal of this blog entry!
 4
 5    switch (registrant.subscriberStatus) {
 6    case .CurrentSubscriber:
 7        showPremiumContent()
 8    case .ExpiredSubscriber:
 9        alertExpiredSubscription()
10    case .NonSubscriber:
11        offerSubscription()
12    }
13    
14}

Producing the enumeration values

The one thing that left me scratching my head on at first was the part of the whole scheme that would produce the enumeration values. In my example above, I’ve left out what the implementation of Registrant looks like.

When I’m consuming the enumeration values, I’m riding on the fact that registrant.subscriberStatus has some way of producing a correct SubscriberStatus for the registrant. But what does that look like? Well… here’s one possibility:

 1public struct Registrant {
 2    public var subscriberStatus: SubscriberStatus {
 3        get {
 4            if (noSubscriptionOnFile()) {
 5                return .NonSubscriber
 6            }
 7            
 8            if (subscriptionOverdueForPayment()) {
 9                return .ExpiredSubscriber
10            }
11            
12            return .CurrentSubscriber
13        }
14    }
15    
16    private func noSubscriptionOnFile() -> Bool {
17        // Do what needs to be done to check if the registrant has a subscription on file or not
18    }
19    
20    private func subscriptionOverdueForPayment() -> Bool {
21        // Do what needs to be done to check if the registrant's subscription is overdue for payment
22    }
23}

So as you can see, the thing that produces the enumeration values does have some ifs and Bools in it. I couldn’t really think of another way to do this. To simplify the readability of the subscriberStatus property’s implementation, I’ve abstracted the more complicated computational logic for figuring out whether or not a subscription is on file or if the registrant is overdue for payment into functions.

Even though we do still have some Bools to deal with, what we’ve gained (in my opinion) is clarity on the consumption end. To me, it’s worth it to have the Bool logic buried in one spot so that throughout the rest of my app, I can deal with clear, understandable, enumeration values.

Announcing the Birth of……

Fri, 27 Mar 2015 13:00:27 +0000

My daughter, whom we codenamed Firefly, made her debut at 2:59 AM this morning! Being the nerd that I am, I built a small iOS app to reveal her name.

Introducing….

What is Delegation? – A Swift Developer’s Guide

Fri, 27 Mar 2015 03:29:01 +0000

Of the major design patterns that are prevalent in iOS development, delegation is one that appears quite often. For many developers entering app development for the iOS platform, dealing with delegates is a new concept. It certainly was for me.

In my analysis of NSNotificationCenter vs Delegation, I wrote some about delegation, but only in comparison to how NSNotificationCenter works. I haven’t yet given delegation dedicated time and analysis, but I intend to do so now.

My aim in this blog entry is to try and make some sense out of the question, “What is delegation?”. Explore with me…

What is the delegation design pattern?

To read that “delegation is a design pattern that [insert explanation here]” never really clicked with me. Many who are new to programming have not dealt extensively with “design patterns”, so it doesn’t always suffice to define delegation in those terms.

I suspect that since Swift has lowered the barrier to entry for iOS development, many who are new to the platform are also new to coding in general, so here’s my attempt to explain what clicked for me regarding what delegation is:

Design pattern

First, take the phrase “design pattern”.

Design implies architecture. It connotes a strategy for organizing something. Design conveys the method by which components will work together to accomplish an end.

Pattern implies that there is some repeatable process that has honed in around a common thread… a common practice… a predictable method for doing something. “Pattern” gives the impression that such a practice has converged over time into something that is now well-known, well-understood, and commonly used. I imagine a sort of “survival of the fittest” approach to process and practice. Things that didn’t converge or that were weaker in the real world fell away and the strongest survived into this thing we call “pattern”.

A design pattern in software terms, then, is a method for architecting, strategizing about, and organizing an application’s code in such a way that has been found to be commonplace, repeatable, and practically sound over time.

Delegation

Now take the word delegation. Three things come to my mind:

The verb, “to delegate”, meaning “to give control”
The noun, “a delegate”, meaning “a person acting for another”
The made-up noun, “a delegat_or_”, or more properly, a principal, meaning “a person who delegates to another”

In the real world, the word delegation encapsulates relationship and responsibility. A delegator/principal (noun) would delegate (verb) control or responsibility to another person called a delegate.

How could we map this to software? Well, it actually falls in line quite nicely.

Rather than people, we’re dealing with instances of classes (or other data structures like structs, but I’m just going to keep it simple and say “class” to encapsulate the idea). For delegation to occur in software, you’d have a situation where one class (a delegator/principal class) would delegate control or responsibility, here meaning behavioral logic, to another class called a delegate.

How is delegation used?

So yes… delegation is a design pattern. It’s a design pattern that exists on other platforms, but it is one that has been heavily adopted by Apple and is ubiquitous throughout the iOS APIs. It’s a design pattern that shifts responsibility from one class to another, thereby creating a separation of responsibilities and concerns. But what kinds of responsibilities and concerns? How is delegation used in practice?

Communication

In practice, delegation is most often used as a way for one class to communicate to another class. Observing some of the actions that delegates perform from Apple’s own APIs give us clues about this. Take the following samples from UITableViewDelegate as an example:

tableView(_:_will_SelectRowAtIndexPath:)
tableView(_:_did_SelectRowAtIndexPath:)
tableView(_:_did_HighlightRowAtIndexPath:)

Or how about a sampling from UIScrollViewDelegate:

scrollView**Did_Scroll**(:)
scrollView**WillBegin_Dragging**(:)
scrollView**WillEnd_Dragging**(:withVelocity:targetContentOffset:)
scrollView**DidEnd_Dragging**(:willDecelerate:)

My observation of Apple’s APIs indicates to me that one of the intended uses for delegation is to allow one instance to communicate back to some other instance that something will/did happen. The table view or scroll view delegates the opportunity to perform some action in response to some lifecycle event to another class, namely, its delegate.

It’s also worth noting the scope of the communication that delegation is intended to be used for. Whereas NSNotificationCenter fits the need for one instance to broadcast a message intended for more than one listening instance, delegation fits the scenario where an instance only needs to send a message to a single listener (the delegate).

Customization

Another common usage for delegation is to provide a delegate instance the opportunity to customize certain aspects of the delegat_ing_ instance’s internal state. Once again, clues from a few of Apple’s APIs shed some light on this usage scenario. Let’s look at UITableViewDelegate first:

tableView(_:heightForRowAtIndexPath:)
tableView(_:editActionsForRowAtIndexPath:)
tableView(_:indentationLevelForRowAtIndexPath:)
tableView(_:shouldHighlightRowAtIndexPath:)

These are all customization-points that a UITableView allows its delegate to have a say in. Some of the methods are so important that the table view can’t display itself unless it gets this information from its delegate. The point here is that the table view is shifting responsibility for the implementation of that logic off to its delegate, allowing for greater controlled flexibility and customization.

Wrapping up

With delegation being such a heavily utilized strategy for organizing an iOS application’s logic, understanding what it is becomes key concern. In this article we unpacked the terms “design pattern” and “delegation” to get a grasp of why those words were chosen to describe the strategy. Finally, we looked at how the delegation pattern is used in practice, observing that two common use-cases for delegation: class-to-class communication and customization.

You might also enjoy…

Basics of Pull to Refresh for Swift Developers

Tue, 17 Mar 2015 17:55:52 +0000

Updated on September 21, 2016 – Swift 3.0

Implementing “pull to refresh” is a common need that arises when working with table views. There are typically two scenarios that folks find themselves in when attempting to implement this feature:

They’re working with a UITableViewController
They’re working with a non-UITableViewController, but their view incorporates a regular UITableView, either taking up the whole screen, or a smaller portion of it

This entry will explore both scenarios to help you get up and running quickly with implementing pull to refresh for your Swift iOS app.

Example scenario

For this guide, suppose that we have a list of movies that we’d like to display in a table view. Pulling to refresh will fetch more movies and update the table view to show the new ones.

If you’re the type that likes to simply dive into a working example, both implementations are available to download from GitHub:

Example projects

Example implemented with UITableViewController
(Swift 2.3 | Swift 3.0)

<li>
  <i class="fab fa-github fa-lg"></i> Example implemented with regular view controller + UITableView <div>
    (<a href="https://github.com/andrewcbancroft/PullToRefreshExample_RegularViewController/tree/swift-2.3">Swift 2.3</a> | <a href="https://github.com/andrewcbancroft/PullToRefreshExample_RegularViewController/tree/master">Swift 3.0</a>)
  </div>
</li>

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example projects above.

Movies are represented by a simple struct:

1struct Movie {
2    let title: String
3    let genre: String
4}

The table view (regardless of whether we use a UITableViewController or a regular UIViewController) has the following setup…

Initial data source values:

1var movies = [
2    Movie(title: "Lion King", genre: "Animation"),
3    Movie(title: "Star Wars", genre: "Sci-fi")
4]

Setting up the table view’s data source protocol methods depends on whether you’re using a UITableViewController or a regular UIViewController with a table view as one of its content views, so we’ll cover those in the individual examples.

Implementing with UITableViewController

Finish example setup

When working with a UITableViewController, we simply override the data source method implementations. The following is how I’ve chosen to do it for this example:

 1override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 2    return movies.count
 3}
 4
 5override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
 6    let cell = tableView.dequeueReusableCell(withIdentifier: "cell")!
 7    
 8    cell.textLabel?.text = movies[(indexPath as NSIndexPath).row].title
 9    cell.detailTextLabel?.text = movies[(indexPath as NSIndexPath).row].genre
10    
11    return cell
12}

Enable refreshing in Storyboard

When you’re working with a UITableViewController, the solution is fairly simple: First, Select the table view controller in your storyboard, open the attributes inspector, and enable refreshing:

A UITableViewController comes outfitted with a reference to a UIRefreshControl out of the box. You simply need to wire up a few things to initiate and complete the refresh when the user pulls down.

Override viewDidLoad()

In your override of viewDidLoad(), add a target to handle the refresh as follows:

1override func viewDidLoad() {
2    super.viewDidLoad()
3    // Do any additional setup after loading the view, typically from a nib.
4    
5    self.refreshControl?.addTarget(self, action: #selector(ViewController.handleRefresh(_:)), for: UIControlEvents.valueChanged)
6}

Here are a couple of things to observe about the code above:

Swift’s new #selector feature helps with specifying which action will handle the refresh. Since I’ve specified ViewController.handleRefresh(_:) (note the underscore and the colon!) as the action argument, I need to define a function in this UITableViewController class with the same name. Additionally, the function should take one argument.
We’d like this action to be called for the UIControlEvent called ValueChanged.

Implement handleRefresh function

The handleRefresh: function may look something like the following:

 1func handleRefresh(refreshControl: UIRefreshControl) {
 2    // Do some reloading of data and update the table view's data source
 3    // Fetch more objects from a web service, for example...
 4    
 5    // Simply adding an object to the data source for this example
 6    let newMovie = Movie(title: "Serenity", genre: "Sci-fi")
 7    movies.append(newMovie)
 8    
 9    movies.sort() { $0.title < $1.title }
10    
11    self.tableView.reloadData()
12    refreshControl.endRefreshing()
13}

That should complete the pull to refresh implementation when you’re working with a UITableViewController!

Implementing with regular view controller + UITableView

Finish example setup

When working with a regular UIViewController, there are a few extra steps involved in getting things set up:

Create an IBOutlet from the storyboard to the view controller
Wire up the table view’s data source and delegate from the storyboard
Implement the required table view data source methods

Creating the IBOutlet is a matter of control+clicking and dragging from the table view in the Storyboard to the view controller code to create the outlet.

To wire up the table view’s data source and delegate in the Storyboard, control+click the table view and drag up to the yellow view controller icon:

The data source protocol method implementations may look something like this:

 1 Int {
 2    return movies.count
 3}
 4
 5func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
 6    let cell = tableView.dequeueReusableCell(withIdentifier: "cell")!
 7    
 8    cell.textLabel?.text = movies[(indexPath as NSIndexPath).row].title
 9    cell.detailTextLabel?.text = movies[(indexPath as NSIndexPath).row].genre
10    
11    return cell
12}

Set up UIRefreshControl

Whereas a UITableViewController comes pre-fit with a UIRefreshControl, a regular UIViewController does not. It’s simple enough to set one up though. Here is a snippet defining a lazily instantiated variable which creates and configures a UIRefreshControl:

1lazy var refreshControl: UIRefreshControl = {
2    let refreshControl = UIRefreshControl()
3    refreshControl.addTarget(self, action: #selector(ViewController.handleRefresh(_:)), for: UIControlEvents.valueChanged)
4    
5    return refreshControl
6}()

The most complicated thing about the code I just proposed is how the UIRefreshControl instance is assigned lazily by means of the closure expression denoted by = { // ...closure body with setup code... }() in the above snippet. Using this approach allows me to complete the setup all in one spot without the use of optionals. You may prefer doing this another way. The bottom line goal is to have a UIRefreshControl instance that we can add to the table view (coming up).

As for the body of the closure expression, we’re adding a target-action to the UIRefreshControl instance, just like we did when we were dealing with a UITableViewController.

As with the UITableViewController example, note:

Since I’ve specified “handleRefresh:” (note the colon!) as the action argument, I need to define a function in this UITableViewController class with the same name. Additionally, the function should take one argument.
We’d like this action to be called for the UIControlEvent called ValueChanged.

Override viewDidLoad

Assuming that there is an outlet to the table view in the Storyboard, the next step is to add the UIRefreshControl as a subview to the table view:

1override func viewDidLoad() {
2    super.viewDidLoad()
3    // Do any additional setup after loading the view, typically from a nib.
4    
5    self.tableView.addSubview(self.refreshControl)
6}

Implement handleRefresh function

The handleRefresh function is implemented exactly as it was when we were dealing with a UITableViewController:

 1func handleRefresh(refreshControl: UIRefreshControl) {
 2    // Do some reloading of data and update the table view's data source
 3    // Fetch more objects from a web service, for example...
 4    
 5    // Simply adding an object to the data source for this example
 6    let newMovie = Movie(title: "Serenity", genre: "Sci-fi")
 7    movies.append(newMovie)
 8    
 9    movies.sort() { $0.title < $1.title }
10    
11    self.tableView.reloadData()
12    refreshControl.endRefreshing()
13}

Wrapping up

Implementing “pull to refresh” is a common need that arises when working with table views. Here we’ve explored how to implement this feature using both a UITableViewController and with a regular view controller and a table view.

An (Almost) TDD Workflow in Swift

Wed, 11 Mar 2015 01:46:59 +0000

There are times when it feels paralyzing to write tests first before any production code is written. Even with good requirements documentation, I often find myself asking, “How am I supposed to write a test to verify x about some thing that doesn’t exist in actual code yet?” It can be crippling.

The following is a workflow that’s helped me grow in my test-first development skills. When I find myself staring at the screen, paralyzed because I’m “not supposed to write actual production code until the test is written”, I often turn to the workflow that I’m about to describe to help me break through to being productive. With practice and experience, I find myself needing this strategy less and less, but I’ve found it helpful to use this (almost) TDD workflow as a gateway into full test-first development.

Set up side-by-side view: Test on left | Code on right

My starting place is to always have a test file open on the left, and the actual production code file that I want to write tests for on the right. This does a couple of things for me:

It helps me avoid a lot of switching back and forth between tests and production code.
It helps me keep tests at the forefront of my mind. Without seeing them in front of me, I could more easily forget about them. Having the split IDE keeps me conscious of the need to prioritize testing.

I recently wrote about a technique to seed a Core Data database, and with that post, I included a project called “Zootastic” – a contrived app that modeled the storage and display of Zoos (along with Animals and their Classifications). I created a class called DataHelper which had several seed() methods. For the purposes of having an example before us, suppose that I wanted to test DataHelper. My screen might look something like this, with my tests on the left, and my DataHelper class on the right:

Write the actual production code

What I want is to insert 3 Zoo objects into the Core Data data store. But without the actual code before me, it’s hard to imagine what the test(s) for that code might look like.

When I get stuck in this way, I’ll go ahead and write the actual production code:

One important thing to remember is that you don’t want to write a ton of code in this step… just enough to spark your brain into figuring out what kinds of tests you can write. Write small increments of code. The more you write, the harder it will be to ensure you’ve covered the code and the various edge cases that may exist. Your goal is not to write the app. Your goal is to write a function, or a part of the function – just enough to get you going with tests.

Write a test that will exercise the code

Having some real code with real class names and real function names usually helps me see what I need to do in terms of testing.

In the example I have going, I’d like my seedZoos() function to insert 3 Zoo objects into my CoreData data store.

At this point, it’s pretty easy for me to think of the name of my first test. How about, testSeedZoosInserts3ZooObjectsIntoDataStore():

Comment out the production code so that the test will fail

Running the tests right now would produce a passing test. “Great!”, you say – but here’s my issue with simply running the test, seeing it pass, and moving on without ever having seen it fail:

There are many ways to produce passing tests without actually verifying the results of executing the app’s code.

I could write a test with no assert. That’d be silly, but forgetting that at the end would produce a green test – and it’s easier to do than you think as you get rolling with these things. Expecting the first time you run the test to produce a failing test would alert you if you ran it the first time and saw a passing one.
I could write a test that asserts the wrong thing and produces a false positive. Again, expecting “fail” at first would alert me if I saw “pass” at first.
Suppose I copied and pasted a test and intended to replace the implementation to test my new code. But I get distracted between when I pasted it and when I ran it for the first time. If I ran it, saw “pass” and moved on, the test wouldn’t be doing its job – it’d be testing something that I already tested, and not these new lines of code I just produced!

The point is this: There are too many ways to write a test that doesn’t truly test your code. Suffice it to say, you should always make the test fail so that you know it’s wired up to the right production code. Thus, this crucial step: comment out the production code. It’ll ensure you get a failing test on the first run (if you’re truly testing the right thing).

Run the test and verify that it fails

With the production code I just wrote commented out, I run the test. My expectation at this point is that it will fail, because the seedZoos() function does not currently insert any Zoo objects into the data store.

If the test doesn’t fail, something is wrong. Check the basics: Did you include an assert at the end of the test? Are you exercising the right production code? Continue troubleshooting and re-running the test until it fails.

Uncomment the production code so that the test will pass

Once I’ve been able to make the test fail, I uncomment the production code.

The idea here is that once the production code is now “live”, the test that’s currently failing should pass, now that production code is performing appropriate logic to meet the test’s assertion requirements. We know that the test currently fails, so if it passes after we uncomment the production code, the only reason it could pass is because the production code is doing the right thing for that particular test’s assertion. Nothing else about our work environment changed, so nothing else except the uncommented production code could have been the cause of the passing test.

Here’s a view of the IDE in the state right before I run the test again to watch it pass:

Run the test and verify that it passes

The last step in this (almost) TDD workflow is to run the test one more time. This time it should pass:

If the test doesn’t pass, then something is wrong. Check the basics: Does the test assert the right thing? Does the production code perform correct logic that would satisfy the test’s assertion? Continue troubleshooting and revise the necessary code until you have a passing test.

Rinse and repeat

You can perform this workflow as my times as you need. This is a stepping stone, so the hope is that eventually you’ll be able to write the tests first. It takes a little practice, but using this technique has, in my experience, been a gateway to true Test Driven Development.

Displaying Data With NSFetchedResultsController and Swift

Thu, 05 Mar 2015 15:14:53 +0000

The combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate Core Data with a user interface. The greatest benefits of using NSFetchedResultsController come when we use it to automatically update a table view when objects are added, updated, or removed from a Core Data data store. First things first, though…

With a Core Data data store seeded with data, the next logical step is to display that data somewhere other than the console. This post will be devoted to figuring out how to set up an NSFetchedResultsController to display data inside a UITableView.

A follow-up post has been published to help you keep the table view in sync with the data as it changes in your persistent store, so once you’re finished here, you might check out that next step!

Final goal

NSFetchedResultsController will help us accomplish two things:

It will fetch data from the Core Data data store
It will use some of the data we fetch to populate various pieces of the UI (table view section headers, cell “title” and “subtitle” text. Here’s what we’re going for:

Setup and resources

I’m continuing my “Zootastic” example that I used to write about using Swift to seed a Core Data database. In fact, I’ve simply branched the project on GibHub and added the things we’re exploring in this post.

Resources

Example Xcode Project

For this entry, we’ll still be dealing with our three primary NSManagedObject subclasses: Zoo, Animal, And Classification:

Storyboard

Zootastic is a single view application. The Storyboard contains one view controller with a table view filling the Scene.

The table view is using one prototype cell with an Identifier of “Cell” (for simplicity). The Style of the prototype cell is set to Subtitle.

MainViewController.swift

MainViewController.swift is where the action is happening. Here’s a quick outline of what we need to accomplish in this class:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // maintain a reference to NSManagedObjectContext instance

    // create and configure an NSFetchedResultsController instance

    // Implement UITableViewDataSource methods
}

As you can see, MainViewController is a class concerned with being the table view’s data source and delegate. Additionally, it will serve as the NSFetchedResultsControllerDelegate. For this post, we won’t actually need the fetched results controller delegate functionality to display data. Those methods are particularly useful for synchronizing things when data changes.

With the class declaration out of the way, we’ll investigate the class implementation one section at a time.

Maintain NSManagedObjectContext instance reference

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {
    
    public var context: NSManagedObjectContext!

    // ...
}

You may be asking, “Where will you set this NSManagedObjectContext reference?”. I’m employing a pattern that I’ve found successful in the past: I assign it when the finishes launching through the AppDelegate’s application:didFinishLaunchingWithOptions method. More on this, shortly…

For now, know that we’re counting on that later step to take place, since context is defined as an implicitly unwrapped optional.

Create and configure NSFetchedResultsController instance

Next, we need to create and configure an NSFetchedResultsController instance. Here’s a bit of code with comments to follow:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {
    
    // ...
    
    lazy var fetchedResultsController: NSFetchedResultsController = {
        let animalsFetchRequest = NSFetchRequest(entityName: "Animal")
        let primarySortDescriptor = NSSortDescriptor(key: "classification.order", ascending: true)
        let secondarySortDescriptor = NSSortDescriptor(key: "commonName", ascending: true)
        animalsFetchRequest.sortDescriptors = [primarySortDescriptor, secondarySortDescriptor]
        
        let frc = NSFetchedResultsController(
            fetchRequest: animalsFetchRequest,
            managedObjectContext: self.context,
            sectionNameKeyPath: "classification.order",
            cacheName: nil)
        
        frc.delegate = self
        
        return frc
        }()
    
    // ...

}

If you’ve not read Colin Eberhardt’s Swift Initialization and the Pain of Optionals post, I highly recommend it. His post is a fantastic analysis, and the final option of using lazy stored properties initialized by a closure expression is what I’ve chosen to do here. I won’t repeat his analysis here, so feel free to jump over to his post to figure out what’s going on there.

Within the closure expression, I’m setting up a fetch request with some sorting applied. All that’s left is to initialize the NSFetchedResultsController, set its delegate and return it.

viewDidLoad()

Once the view has loaded, the idea is to perform the NSFetchedResultsController instance’s fetch request so that it has data to use in our UITableViewDataSource methods. This is how to do it:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    override public func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.

            do {
                try fetchedResultsController.performFetch()
            } catch {
                print("An error occurred")
            }
    }

    // ...

}

UITableViewDataSource methods

The final step in implementing MainViewController is to set up the table view so that it pulls data from fetchedResultsController. I’m implementing the standard UITableViewDataSource methods here, along with tableView:titleForHeaderInSection. Take a look:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    // MARK: TableView Data Source
    public func numberOfSectionsInTableView(tableView: UITableView) -> Int {
        if let sections = fetchedResultsController.sections {
            return sections.count
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.numberOfObjects
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) 
        let animal = fetchedResultsController.objectAtIndexPath(indexPath) as! Animal
        
        cell.textLabel?.text = animal.commonName
        cell.detailTextLabel?.text = animal.habitat
        
        return cell
    }
    
    public func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.name
        }
        
        return nil
    }

    // ...

}

Apart from a bit of if let ___ = ___ syntax, there’s not an awful lot of surprising code here if you’re familiar with working with table views. I’ve highlighted the relevant code related to fetchedResultsController. Without using NSFetchedResultsController, you’d probably supply data to the table view from an array or a dictionary or both. The fetchedResultsController code simplifies the data display dilemma when you’re using Core Data.

Once the UITableViewDataSource methods are implemented, the implementation of MainViewController is complete for this example.

AppDelegate.swift

There’s one final thing we need to do in order to get things rolling. In the “maintain NSManagedObjectContext instance reference” section of this post, I mentioned the strategy for assigning the NSManagedObjectContext instance in the MainViewController. Here’s how I do it:

class AppDelegate: UIResponder, UIApplicationDelegate {

    // ...


    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        // Override point for customization after application launch.
        
        let dataHelper = DataHelper(context: self.managedObjectContext)
        dataHelper.seedDataStore()
        
        dataHelper.printAllZoos()
        dataHelper.printAllClassifications()
        dataHelper.printAllAnimals()
        
        let rootViewController = self.window!.rootViewController as! MainViewController
        rootViewController.context = self.managedObjectContext;
        
        return true
    }

    // ...

}

Note: With iOS 13, the code to assign the managedObjectContext to the root view controller needs to go in your app’s SceneDelegate.

The portion new to “injecting” the managedObjectContext into MainViewController is highlighted. I simply grab a reference to the rootViewController (which in our example is the MainViewController) and cast it to the appropriate type. Then I set the context property to the managedObjectContext that’s created in the AppDelegate via Xcode’s auto-generated Core Data stack setup.

Wrapping up

If you’re using Core Data in your iOS application, the combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate data from your data store into your UI. We’ve explored how to display data in a table view using NSFetchedResultsController. Feel free to grab the GibHub project for further investigation and to see Zootastic in action.

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Using Swift to Seed a Core Data Database

Thu, 26 Feb 2015 03:44:53 +0000

Designing an application’s UI can be difficult without actual data to present. Early on in the design process, data sourced from something like an array can suffice. Later on, however, our data sources become more dependent on actual data stores, such as what Core Data provides us.

During development, I’ve found that it’s often convenient to seed a Core Data database with sample data so that I can preview how it’ll look in my application. Along with that, it’s nice to start with a fresh copy of the data each time I run the app. Let’s explore how to accomplish this task in Swift!

Scenario setup

Resources

Example Xcode Project

I’ve created a fictitious Core Data app called “Zootastic”, which is intended to model zoos, and the animals that each zoo cares for. (I’ll give you one guess as to what kinds of shows and activities my two year old and I have been in to lately). :]

Specifically, I have the following Entities:

Zoo
- name
- location
- animals (relationship)
Animal
- commonName
- habitat
- classification (relationship)
- zoos (relationship)
Classification
- scientificClassification
- family
- order
- animals (relationship)

I’ve created NSManagedObject subclasses for each of my entities, to make it easier to set properties.

DataHelper.swift

Once a Core Data data model is set up, we’re ready to create what I called DataHelper. It serves the purpose of seeding the data store, and logging the data store’s contents back out to the console. It violates the single-responsibility principle, but wait! Don’t lynch me!

Knowing that this class is intended to be used solely for development, I didn’t put a lot of effort into separating concerns. I opted for a “here’s where I go to do all my seeding for manual testing purposes” approach.

Here are a few snippets from the class (grab the full Xcode project over at GitHub):

Initialization

 1public class DataHelper {
 2    let context: NSManagedObjectContext
 3    
 4    init(context: NSManagedObjectContext) {
 5        self.context = context
 6    }
 7    
 8// ...
 9
10}

The primary thing to take away from the initialization routine is that instead of calling out to the AppDelegate to get an instance of the NSManagedObjectContext, I’m choosing to require it to be passed in during the initialization of DataHelper. It’s a pattern I like to practice because it allows me to do unit tests in real-world applications that use Core Data.

seedZoos()

 1public class DataHelper {
 2
 3// ...
 4
 5    private func seedZoos() {
 6        let zoos = [
 7            (name: "Oklahoma City Zoo", location: "Oklahoma City, OK"),
 8            (name: "Lowry Park Zoo", location: "Tampa, FL"),
 9            (name: "San Diego Zoo", location: "San Diego, CA")
10        ]
11        
12        for zoo in zoos {
13            let newZoo = NSEntityDescription.insertNewObjectForEntityForName("Zoo", inManagedObjectContext: context) as! Zoo
14            newZoo.name = zoo.name
15            newZoo.location = zoo.location
16        }
17        
18        do {
19            try context.save()
20        } catch _ {
21        }
22    }
23
24// ...
25
26}

A few observations on the code above:

This function may look a bit interesting. I’ve chosen to create an array of tuples that I loop over and use to extract actual Zoo information when I call NSEntityDescription.insertNewObjectForEntityForName(). It just looked nice to me to have two chunks of code to analyze inside the function: One (the array of tuples) to see all of the zoo information I plan to insert, and another (the for-loop) to do the actual inserting into the data store. Adding more Zoos in the future would mean simply adding another tuple to the array. Convenient!
Since I’ve created NSManagedObject subclasses for my entities, I can cast the result of NSEntityDescription.insertNewObjectForEntityForName() to an actual Zoo, to work with the properties directly.

printAllZoos()

 1public class DataHelper {
 2
 3// ...
 4
 5    public func printAllZoos() {
 6        let zooFetchRequest = NSFetchRequest(entityName: "Zoo")
 7        let primarySortDescriptor = NSSortDescriptor(key: "name", ascending: true)
 8        
 9        zooFetchRequest.sortDescriptors = [primarySortDescriptor]
10        
11        let allZoos = (try! context.executeFetchRequest(zooFetchRequest)) as! [Zoo]
12        
13        for zoo in allZoos {
14            print("Zoo Name: \(zoo.name)\nLocation: \(zoo.location) \n-------\n", terminator: "")
15        }
16    }
17
18// ...
19
20}

printAllZoos() function utilizes a standard NSFetchRequest, along with an NSSortDescriptor. Check out my cheat sheet for more examples of common Core Data operations.

Once again, having the NSManagedObject subclass in place allows me to cast the result of the fetch request to a [Zoo].

seedAnimals()

 1public class DataHelper {
 2
 3// ...
 4
 5    private func seedAnimals() {
 6        // Grab Classifications
 7        let classificationFetchRequest = NSFetchRequest(entityName: "Classification")
 8        let allClassifications = (try! context.executeFetchRequest(classificationFetchRequest)) as! [Classification]
 9
10        let manatee = allClassifications.filter({(c: Classification) -> Bool in
11            return c.family == "Trichechidae"
12        }).first
13        
14        // Same pattern for monkey and bat
15        
16        // Grab Zoos
17        let zooFetchRequest = NSFetchRequest(entityName: "Zoo")
18        let allZoos = (try! context.executeFetchRequest(zooFetchRequest)) as! [Zoo]
19        
20        let oklahomaCityZoo = allZoos.filter({ (z: Zoo) -> Bool in
21            return z.name == "Oklahoma City Zoo"
22        }).first
23        
24        // Same pattern for San Diego Zoo and Lowry Park Zoo
25        
26        // Create an array of "animal" tuples, assigning
27        // whatever Classification and Zoo make sense
28        let animals = [
29            (commonName: "Pygmy Fruit-eating Bat", habitat: "Flying Mamals Exhibit", classification: bat!, zoos: NSSet(array: [lowryParkZoo!, oklahomaCityZoo!, sanDiegoZoo!])),
30            (commonName: "Mantled Howler", habitat: "Primate Exhibit", classification: monkey!, zoos: NSSet(array: [sanDiegoZoo!, lowryParkZoo!])),
31            (commonName: "Geoffroy’s Spider Monkey", habitat: "Primate Exhibit", classification: monkey!, zoos: NSSet(array: [sanDiegoZoo!])),
32            (commonName: "West Indian Manatee", habitat: "Aquatic Mamals Exhibit", classification: manatee!, zoos: NSSet(array: [lowryParkZoo!]))
33        ]
34        
35        // Create -actual- Animal instances and insert them
36        for animal in animals {
37            let newAnimal = NSEntityDescription.insertNewObjectForEntityForName("Animal", inManagedObjectContext: context) as! Animal
38            newAnimal.commonName = animal.commonName
39            newAnimal.habitat = animal.habitat
40            newAnimal.classification = animal.classification
41            newAnimal.zoos = animal.zoos
42        }
43        
44        do {
45            try context.save()
46        } catch _ {
47        }
48    }
49
50// ...
51
52}

seedAnimals() is the most complicated piece of the whole scenario because it depends on entities that have been previously inserted into the data store. An Animal, which is a member of some Classification lives in some habitat at a Zoo. So in order to get a complete Animal into the data store, we need to have a Classification and one or more Zoo to assign it.

I’ve chosen to go ahead and execute fetch requests for the entities I made in previous seed___() functions. Additionally, rather than deal with NSPredicate, I just grab all Classifications and all Zoos, and use array’s filter function to get the exact Entity I want.

The last thing I’ll mention / warn against, is that I am using explicitly unwrapped optionals in this function. I’ve gone ahead and “risked it”, trusting that I’m only using this technique during development time to help me see how things will look in my UI. In other words, this isn’t code that will end up in Production. It’s simply meant to help me while I’m developing, so I’ve gone ahead and done things the quick way here.

The rest of the function follows the same patterns that have already been used in this example.

AppDelegate.swift

 1func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
 2        // Override point for customization after application launch.
 3        
 4        let dataHelper = DataHelper(context: self.managedObjectContext)
 5        dataHelper.seedDataStore()
 6        
 7        dataHelper.printAllZoos()
 8        dataHelper.printAllClassifications()
 9        dataHelper.printAllAnimals()
10        
11        return true
12    }

Above is a peek at what my AppDelegate.swift file’s application:didFinishLaunchingWithOptions: function looks like. Nothing fancy going on here. I’m simply initializing a DataHelper instance with the NSManagedObjectContext instance that’s created in this class, and calling the seed and print functions I defined earlier.

Starting fresh every time

I’ve found that sometimes it helps to have a freshly seeded data store every time I the app while I’m in development mode. When I’m testing the UI, I may create new entities during my manual testing, but one of the convenient things about seeding the data store is that I don’t have to. And even if I did, it’s often quite nice to start fresh each run. To do this we’ll dive into some of the boilerplate code that Xcode generates for us when we choose to use Core Data when we create the project. Specifically, we’ll target the persistentStoreCoordinator closure:

 1lazy var persistentStoreCoordinator: NSPersistentStoreCoordinator = {
 2        // The persistent store coordinator for the application. This implementation creates and returns a coordinator, having added the store for the application to it. This property is optional since there are legitimate error conditions that could cause the creation of the store to fail.
 3        // Create the coordinator and store
 4        let coordinator = NSPersistentStoreCoordinator(managedObjectModel: self.managedObjectModel)
 5        let url = self.applicationDocumentsDirectory.URLByAppendingPathComponent("Zootastic.sqlite")
 6        
 7        do {
 8            try NSFileManager.defaultManager().removeItemAtURL(url)
 9        } catch _ {
10        }
11
12        
13        var failureReason = "There was an error creating or loading the application's saved data."
14        do {
15            try coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: url, options: nil)
16        } catch {
17            // Report any error we got.
18            var dict = [String: AnyObject]()
19            dict[NSLocalizedDescriptionKey] = "Failed to initialize the application's saved data"
20            dict[NSLocalizedFailureReasonErrorKey] = failureReason
21            
22            dict[NSUnderlyingErrorKey] = error as NSError
23            let wrappedError = NSError(domain: "YOUR_ERROR_DOMAIN", code: 9999, userInfo: dict)
24            // Replace this with code to handle the error appropriately.
25            // abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
26            NSLog("Unresolved error \(wrappedError), \(wrappedError.userInfo)")
27            abort()
28        }
29        
30        return coordinator
31        }()

I’ve highlighted the key line that I added (everything else was already in place, generated for me by Xcode). Adding that line removes the sqlite database. The lines that follow add it back in a fresh state.

Wrapping up

Designing an application’s UI can be difficult without actual data to present. During development, it’s often convenient to seed a Core Data database with sample data so that we can preview how it’ll look in our application. Along with that, it’s nice to start with a fresh copy of the data each time we run the app. We explored how to accomplish this task in Swift!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Core Data Cheat Sheet for Swift iOS Developers

Wed, 18 Feb 2015 18:20:59 +0000

Updated on July 27, 2016 – Additional Cheats

Having trouble recalling how to perform basic Core Data operations? This cheat sheet is a handy reference to keep you productive with Core Data and Swift!

The code snippets below are here to help jog your memory when it’s been a while since you’ve worked in Core Data. They could also be helpful for newcomers to iOS development, Core Data, and Swift.

One assumption I’m making in this post is that you’ve created NSManagedObject subclasses for your entities to make them easier to work with in a type-safe way. If you need help getting started with that, I’ve written a walk-through to guide you through that process.

Querying

Fetch all entities

// Assuming type has a reference to managed object context

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    // Do something with fetchedEntities
} catch {
    // Do something in response to error condition
}

Fetch maximum of N entities

// Assuming type has a reference to managed object context

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.fetchLimit = 10
do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    // Do something with fetchedEntities
} catch {
    // Do something in response to error condition
}

Insert a new entity

// Assuming encapsulating Type has a reference to managed object context

let newEntity = NSEntityDescription.insertNewObjectForEntityForName("MyEntity", inManagedObjectContext: self.managedObjectContext) as! MyEntity
// Set properties

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Update a single entity

// Assuming type has a reference to managed object context

// Assuming that a specific NSManagedObject's objectID property is accessible
// Alternatively, could supply a predicate expression that's precise enough
// to select only a _single_ entity
let predicate = NSPredicate(format: "objectID == %@", objectIDFromNSManagedObject)

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    fetchedEntities.first?.FirstPropertyToUpdate = NewValue
    fetchedEntities.first?.SecondPropertyToUpdate = NewValue
    // ... Update additional properties with new values
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Update multiple-entities

// Assuming type has a reference to managed object context

let predicate = NSPredicate(format: "MyEntityAttribute == %@", "Matching Value")

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    
    for entity in fetchedEntities {
        entity.FirstPropertyToUpdate = NewValue
        entity.SecondPropertyToUpdate = NewValue
        // ... Update additional properties with new values
    }
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Delete a single entity

// Assuming type has a reference to managed object context

// Assuming that a specific NSManagedObject's objectID property is accessible
// Alternatively, could supply a predicate expression that's precise enough
// to select only a _single_ entity
let predicate = NSPredicate(format: "objectID == %@", objectIDFromNSManagedObject)

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    if let entityToDelete = fetchedEntities.first {
        self.managedObjectContext.deleteObject(entityToDelete)
    }
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Delete multiple-entities

// Assuming type has a reference to managed object context

let predicate = NSPredicate(format: "MyEntityAttribute == %@", "Matching Value")

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    
    for entity in fetchedEntities {
        self.managedObjectContext.deleteObject(entity)
    }
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Migrate Core Data Model with Automatic Migrations

let model = // set up model

let pscOptions = [NSMigratePersistentStoresAutomaticallyOption : true, NSInferMappingModelAutomaticallyOption : true]
    
let psc = NSPersistentStoreCoordinator(managedObjectModel: model)
try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: pscOptions)

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Custom UITableViewCell for Text Input in Swift

Thu, 12 Feb 2015 13:00:50 +0000

The need to collect data via text input is a common in many applications. This walk-through showcases how to create a custom UITableViewCell for accepting text input within a UITableView.

Table Views for Data Entry?

Table views provide nice, built-in styles that present a form-like view for collecting data from your users. They also have inherent scrolling capabilities. Finally, there is some handy keyboard handling, such as auto-scrolling to avoid covering up a data entry cell, or hiding the keyboard when the user scrolls the Table View. Both of those are challenging to get right if you were to do implement a data entry form some other way.

Many of Apple’s own UIs utilize table views to collect data from the user (think Settings, Calendar, Reminders).

For those reasons, I think a table view is a really convenient choice for collecting data from a user.

Step by Step Walkthrough

Resources

Example Xcode Project

Drag a table view to Storyboard

Assuming that you have a View Controller already on the Storyboard design surface, drag a table view onto the Storyboard scene.

Wire up table view data source and delegate

For this step it’s helpful to have the document outline pane visible. Selecting the Table View from the document outline and subsequently Control + Click + Dragging to the View Controller icon on the Storyboard scene will allow you to link the table view’s dataSource and delegate properties to the View Controller.

Note that you’ll need to perform the Control + Click + Drag maneuver twice to set both the dataSource and the delegate.

Configure keyboard dismissal for table view

With the attributes inspector selected in the utilities pane, scroll down to the Keyboard option and set it to “Dismiss on drag”.

This can be helpful if you’d like the keyboard to automatically hide itself when the user scrolls the table view.

Set constraints, increase prototype cells count

Use the document outline to set constraints. With the attributes inspector selected in the utilities pane, select “Dynamic Prototypes” for the Content property, and set the Prototype Count property to 1 (or more, depending on your needs).

Configuring constraints on the table view will ensure that it displays properly on all device sizes and orientations.

In this particular example, there’s only one kind of prototype cell that I want the table view to display. If I had multiple prototypes, I’d increase the prototype cells count to match the number of prototypes I had.

Drag text field to cell, increase text field width

Drag a text field into the cell’s contents and use Xcode’s blue guides to adjust the width so that it takes up the whole cell.

Now comes the customization of the prototype cell itself. Since we’re designing it for text input, we’ll use a text field as the contents of the table view cell prototype.

Configure Text Field Constraints and Border

Use the document outline to set constraints for the text field. With the text field selected, and the attributes inspector selected in the utilities pane, set the Border Style property to the style you prefer.

Configuring constraints on the text field will ensure that it displays properly on all device sizes and orientations.

Depending on your taste / needs, you can change the border style from rounded to none, or whichever other border style is most appealing for your app.

Create new TextInputTableViewCell class

Add a new .swift file named TextInputTableViewCell to your project. Create a new class in that file called TextInputTableViewCell which inherits from UITableViewCell.

Create an IBOutlet between the text field and the TextInputTableViewCell class

Use the document outline to Control + Click + Drag and IBOutlet to the TextInputTableViewCell class.

Implement TextInputTableViewCell class

An example implementation with a function for configuring the text field’s properties might look something like this:

 1import UIKit
 2
 3public class TextInputTableViewCell: UITableViewCell {
 4    @IBOutlet weak var textField: UITextField!
 5    
 6    public func configure(#text: String?, placeholder: String) {
 7        textField.text = text
 8        textField.placeholder = placeholder
 9        
10        textField.accessibilityValue = text
11        textField.accessibilityLabel = placeholder
12    }
13}

Change cell class in Storyboard to TextInputTableViewCell

Use the document outline to select the Table View Cell. With the identity inspector selected in the utilities pane, change the Class property to your TextInputTableViewCell class.

Set reuse identifier

With the Table View Cell still selected in the document outline, select the attribute inspector in the utilities pane and change the Identifier property to “TextInputCell” (or some other string that’s easily remembered).

Implement table view data source and delegate methods

In the View Controller, specify that it adopts the UITableViewDataSource and UITableViewDelegate protocols. Implement the appropriate protocol methods.
I’ve written a cheat sheet for this, but I’ll also provide the following sample implementation of the mai ViewController class:

 1import UIKit
 2
 3public class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 4    public func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 5        return 1 // Create 1 row as an example
 6    }
 7 
 8    public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
 9        let cell = tableView.dequeueReusableCellWithIdentifier("TextInputCell") as TextInputTableViewCell
10        
11        cell.configure(text: "", placeholder: "Enter some text!")
12        return cell
13    }
14}

Lines 9 and 11 are of most importance. Notice that I’m dequeueing a TextInputCell, which is what I set the reuse identifier of my cell to be. I’m also casting the dequeued cell as a TextInputTableViewCell so that it can be configured (line 11)

Run in simulator

Wrapping up

In this walkthrough, my goal was to show how to take advantage of a table view’s inherent styles, scrolling capabilities, and keyboard handling to make form-like text input easier. We created a custom subclass of UITableViewCell to accomplish this task. Take a look at the example published to GitHub to dive in further and explore the walkthrough in more depth.

NSNotificationCenter vs Delegation – An Analysis

Thu, 05 Feb 2015 13:00:26 +0000

In Fundamentals of NSNotificationCenter in Swift, a commenter asked me to elaborate on a response I’d given to a dialog going on below the blog post. I had stated:

If you need a more structured environment around your [instance]-to-[instance] communication, delegates … are probably a better choice [than NSNotificationCenter].

I’ve been thinking for some time since I responded with that comment. What do I mean when I say “if you need a more structured environment”… What does that even look like? Why are delegates a better choice when I need such “structure”?

Structured environment? What’s that?

“Structured environment” may be a bit vague. Here’s what I was thinking when I wrote it: At the time of the comment, I was imagining what a solution implemented with NSNotificationCenter, and a solution implemented with a delegate look like….

Questions

First, I tried to step into the role of each instance, and in a role-playing sort of way, ask:

As a notifier / delegator instance: “What do I expect to happen as I send this notification or invoke this method on my delegate? What clues from my execution context inform that expectation?”
As a notifier / delegator instance: “What control do I appear to have over the sequence of events that happen as a result of sending this notification or invoking this method on my delegate?”
As a listener / delegate instance: “What impact does acting on this notification or executing this delegate method have on the system as a whole?”

And then shifting out of the role-playing mentality, stepping back and asking a question of clarity:

“Which strategy seems to provide greater clarity and structure to the entire application environment?”
“Which strategy would most help another developer who might see this code and try to trace the logic and impact of the code?”

The measurement of a more or less “structured environment”, then, would be influenced by the answers to the questions of expectations, perceived control, impact, and clarity.

Let’s explore some of those answers from the perspective of each communication strategy, starting with NSNotificationCenter.

Answers from the NSNotificationCenter Perspective

With NSNotificationCenter as an instance-to-instance communication strategy, we have the following environment:

Note that Listeners 1 to n may or may not exist. The graphic is assuming that 1+ Listener instances have “tuned in” to a particular notification key.

Expectations

What do I expect to happen? Well, the most reasonable thing I (as a “notifier instance”) can expect is for some other “listener instance” somewhere to tune in to the notification key I’m broadcasting. I have no way of knowing what would happen after that. It’s up to the listener to do something intelligent with the notification that [x event] occurred. I, as a notifier, can expect nothing more.

Perceived Control

It appears that I, as a notifier, have no control over the sequence of events that would occur as a result of my broadcast. That’s by design – the interaction between me and any listener is weak at best.

This can be a fantastic thing! There’s freedom in saying “Hey! This happened!” and then being done. But it’s also “less structured”, as I’m terming it.

Impact

The impact on the system as a whole has the potential to be significant. With NSNotificationCenter, it depends on how many listener instances there are and what each of them does in response to the notification. One could design the system to localize the impacts to the context of the listening instance. I’ve heard of and seen ugly situations that trigger cascading effects that make deciphering the impact of a notification much harder.

Clarity

We lose a good deal of clarity when heavy usage of NSNotificationCenter occurs in an application. There may be appropriate times to use NSNotificationCenter in your app. Keep in mind that it becomes much more difficult to sort out various interactions when more and more listener instances are responding a notification. Trying to reason about how the system as a whole arrived at its current state isn’t as easy when NSNotificationCenter enters the picture. Other developers with less knowledge of the app as a whole would suffer from this loss of clarity.

Answers from the Delegate Perspective

With a delegate, we have a significantly different strategy at hand. To put it before us:

Expectations

The delegation strategy deals with protocols. Protocols by nature give us reliable a way to…

Count on the implementation of needed/expected behavior, and
Predict what the behavior of the adopter of that protocol will be. By practicing good naming conventions, I, as a delegator, find it reasonable to expect that invoking a method on my delegate will do whatever the name of that method implies.

Perceived Control

It would appear that as a delegator, I can control the sequence of events that need to take place by choosing when to invoke methods on my delegate. A strategy using NSNotificationCenter can only send out a notification into the ether, and hope that something acts on it. A strategy using delegation has a delegate which adopts a protocol. Every method is at my disposal to call in whatever order makes sense.

Impact

The impact on the system as a whole still has the potential to be significant. Since there’s one-to-one communication going on between a delegator and its delegate, the determining factor on how broad the impact is tends to lean on the design of the system as a whole. Design patterns that minimize or eliminate global state reduce this potentially broad impact.

One advantage that the delegation pattern has is that the delegate conforms to a protocol and a protocol, along with its specified methods, have names. However small that knowledge is, it could give us clues about what impact of executing the delegate’s methods might have on the system.

Clarity

With the advantage of dealing with intelligently named protocols and clearly outlined method names, the delegation strategy would win the battle of clarity in my opinion. I can look at the delegator instance and say, “When execution of this instance’s logic gets to this point, reliance on the delegate kicks in and [x, y, and z] happens. I can jump over to the delegate’s implementation and say, “[x] does this, [y] does that, and [z] does this other thing.” Other developers with less knowledge of the app as a whole would enjoy this added clarity quite readily.

In Summary

Here, I’ve analyzed NSNotificationCenter, side by side with the delegation pattern, by imagining myself in the role of each instance (notifier, listener | delegator, delegate). I assessed each strategy in terms of expectations, perceived control, impact, and clarity, attempting to shed light on what it means for an environment to be “more structured” or “less structured”. My hope was to shed light on my use of the term “structured environment”, and to share my thoughts on some of the implications of using each strategy.

You might also enjoy…

Converting Complex Objective-C Macros to Swift Functions

Thu, 29 Jan 2015 13:00:51 +0000

The question of how to convert #define macros from Objective-C to Swift is explained fairly simply in the [Apple developer documentation on the subject][1]. For simple macros, it’s a matter of rewriting them as global constants. In fact, if you’re using the hybrid Objective-C — Swift approach to writing your app, Swift sees those simple macros and automatically makes them available to your Swift code. I also gave some tips on the [alternative to Objective-C macros][2] a while back.

Where we run into trouble is when we need to port complex Objective-C macros to Swift. According to the [same documentation from Apple][1],

Complex macros are used in C and Objective-C but have no counterpart in Swift.

Yikes!

Thankfully there is a silver lining after that scary first sentence:

[][3]

In Swift, you can use functions and generics to achieve the same results without any compromises.

That makes sense, actually! Complex Objective-C macros tend to look a lot like functions, so the transition to Swift was straightforward in a case I ran across recently.

Two Examples:

A simple example

What could we do in Swift to convert an Objective-C macro that looks something like this?

#define SQUARE_NUMBER(n) n * n
```

One thing we could do is write a function that produces the same thing:

```swift
func squareNumber(n: Int) -> Int {
    return n * n
}
```

### A little more complicated

An example situation that came to me on Twitter took the form of converting a macro that was a little more complicated than the simple example just presented. The input to the complex macro was a color, represented as a hexadecimal value, along with an alpha, represented as a float. The output? A `UIColor` instance based on some bitwise manipulations to that hex value.

I've created a GitHub example if you'd like to play around with everything. The relevant code is reproduced below…


  
    Resources
  
  
  
    
       Example Xcode Project
    
  


The macro form looked like this:

#define UIColorFromRGB(rgbValue, alphaValue) \
[UIColor colorWithRed:((float)((rgbValue >> 16) & 0xFF))/255.0 \
green:((float)((rgbValue >> 8) & 0xFF))/255.0 \
blue:((float)((rgbValue >> 0) & 0xFF))/255.0 \
alpha:alphaValue]
```

Rewriting it as a Swift function:

```swift
func UIColorFromRGB(rgb: Int, alpha: Float) -> UIColor {
    let red = CGFloat(Float(((rgb>>16) & 0xFF)) / 255.0)
    let green = CGFloat(Float(((rgb>>8) & 0xFF)) / 255.0)
    let blue = CGFloat(Float(((rgb>>0) & 0xFF)) / 255.0)
    let alpha = CGFloat(alpha)
    
    return UIColor(red: red, green: green, blue: blue, alpha: alpha)
}
```

The main thing to keep in mind is that the output of the macro/function is the focus. The internals could change to better-adapt to Swift's features if you desire. If the macro was ugly inside, make it nice in Swift!

### Where should the function go?

  * For organization's sake, you could create a new .swift file and place the function inside it at the global level. This would provide the most convenient transition for your Objective-C to Swift conversion, because `#defines` were available wherever you imported the Objective-C header file.
  * Alternatively, you could encapsulate the function in a class/struct/enum.

### Wrapping up

With the power of Swift functions and the ability to even declare and use them globally, converting complex macros to a better Swift alternative is much less daunting than you might expect.

 [1]: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-XID_20
 [2]: http://www.andrewcbancroft.com/2014/10/01/swift-alternative-to-objective-c-macros/
 [3]: http://www.andrewcbancroft.com/wp-content/uploads/2015/01/complex_macros.png

Conveniently Transforming Immutable Types in Swift

Tue, 20 Jan 2015 12:30:51 +0000

A few weeks ago I wrote about Immutable Types and Changing State in Swift, where I hoped to convey an “aha!-moment” that happened for me.

Since then, I’ve learned a bit more. For example, the technique I presented for transforming instances of a Type immutably actually come for free when you use a value Type, such as a Struct! Check out @NatashaTheRobot’s writeup on the subject, titled “Mutating Functions in Swift Structs”, for more information.

But let’s say, for whatever reason, you’d like to use a reference Type, such as a Class. In that case, the technique I presented in the aforementioned blog entry works out quite nicely. Until….

Many init parameters == Pain

… It works great right up until you have more than a few immutable properties that you need to transform.

I want to thank @Jarsen for his comment. He pointed out the exact pain point I was feeling, since I was actually using my own advice in a personal project. Not only that, he offers a solution in the form of a GitHub gist!

I’m bringing in his example so that we have it before us with a few minor modifications to make it relevant for this blog entry. However, I want to give 100% credit to Jarsen for his insight.

It’s all about convenience

The gist of Jarsen’s solution was to create a second helper initializer which would help setting the values for all the properties easier. Take a look:

 1class Scorekeeper {
 2    let runningScore: Int
 3    let climbingScore: Int
 4    // potentially more properties
 5    
 6    init(runningScore: Int = 0, climbingScore: Int = 0) {
 7        self.runningScore = runningScore
 8        self.climbingScore = climbingScore
 9    }
10    
11    // second helper initializer
12    init(scoreKeeper: Scorekeeper, runningScore: Int? = nil, climbingScore: Int? = nil) {
13        self.runningScore = runningScore ?? scoreKeeper.runningScore
14        self.climbingScore = climbingScore ?? scoreKeeper.climbingScore
15    }
16    
17    func incrementRunningScoreBy(points: Int) -> Scorekeeper {
18        return Scorekeeper(scoreKeeper: self, runningScore: self.runningScore + points)
19    }
20    
21    // other functions to transform Scorekeeper by incrementing other score properties
22}

Note the use of optionals, and the corresponding nil-coalescing operator (??) in the helper initializer’s implementation. It’s simple, and it’s concise. I like it!

The bottom line is that I couldn’t help but share Jarsen’s tip. I thought it deserved a little more attention than to be stuck down in the comment section where folks may or may not find it and be helped.

Unit Testing Model Layer with Core Data and Swift

Tue, 13 Jan 2015 13:00:37 +0000

Updated on November 19, 2015 – Swift 2.0

As I approached testing my Core Data model, I have to admit I was apprehensive. How in the world was I going to write unit tests for my model layer that depended on a database. Past experience with trying to write tests with databases was painful. I feared the same would be the case with Core Data.

To my surprise, unit testing my Core Data model layer has been… well… amazing. With little effort, I’ve been able to write the unit tests I’ve wanted. The process went something like this for me:

Create an NSManagedObject subclass of the Core Data entity that I need in my unit test. (This just makes things easier from an Xcode code-completion standpoint)
Write a helper function to set up an in-memory NSManagedObjectContext. Avoiding the need to use an actual sqlite database is pretty handy. It allows for quick-running tests and easy iterations over the data model itself.
Write unit tests using the in-memory NSManagedObjectContext.

I’ve already written about creating an NSManagedObject subclass, so I will unpack steps 2 and 3 in this blog entry.

Set up an in-memory NSManagedObjectContext

A Stack Overflow question+answer sparked some thoughts. The idea and the code both came from there. The answer uses Objective-C, so my contribution is that I’ve written it in Swift. In my project, I created a new Swift file called “CoreDataHelpers.swift” in my tests target. Here’s a look at the helper function:

 1import CoreData
 2
 3func setUpInMemoryManagedObjectContext() -> NSManagedObjectContext {
 4    let managedObjectModel = NSManagedObjectModel.mergedModelFromBundles([NSBundle.mainBundle()])!
 5    
 6    let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)
 7
 8    do {
 9        try persistentStoreCoordinator.addPersistentStoreWithType(NSInMemoryStoreType, configuration: nil, url: nil, options: nil)
10    } catch {
11        print("Adding in-memory persistent store failed")
12    }
13    
14    let managedObjectContext = NSManagedObjectContext()
15    managedObjectContext.persistentStoreCoordinator = persistentStoreCoordinator
16    
17    return managedObjectContext
18}

Observations

I’ll be honest, I’m only starting to put together the pieces involved in setting up the Core Data stack. Working through these unit testing techniques has solidified a lot. Analyzing the helper method from the bottom up has made some sense out of how to configure everything:

I need an NSManagedObjectContext whose NSPersistentStoreCoordinator property uses an in-memory store.
To get such an NSManagedObjectContext, I need to add a persistent store with a type of NSInMemoryStoreType to an NSPersistentStoreCoordinator instance. (note the line that’s highlighted)
Of course, in order to do that, I need an NSPersistentStoreCoordinator instance, and I can’t get one of those unless I initialize it with an NSManagedObjectModel.
To get an NSManagedObjectModel, I use the class method, mergedModelFromBundles() to grab it from my main bundle.
Fast-forwarding now: With a proper NSManagedObjectModel instance, I can create an NSPersistentStoreCoordinator instance with it and add an NSInMemoryStoreType to that persistentStoreCoordinator. Finally, I can initialize an NSManagedObjectContext, assign the configured persistentStoreCoordinator to the context, and return it.

Whew! This whole process felt a lot like reading If You Give a Mouse a Cookie, but that may be because I’ve read it a few hundred times to my 2 year old. :]

Writing the unit test(s)

With the ability to get an NSManagedObjectContext instance that’s using an in-memory store, the unit tests using Entities from my Core Data model are quite easy.

Here’s a sample test:

 1import CoreData
 2
 3class TestsUsingModelFromCoreData: XCTestCase {
 4    func testSomethingUsingCoreData() {
 5        let managedObjectContext = setUpInMemoryManagedObjectContext()
 6        let entity = NSEntityDescription.insertNewObjectForEntityForName("EntityName", inManagedObjectContext: managedObjectContext)
 7        
 8        // model setup
 9        
10        // XCTAssert    
11    }
12}

Conclusion

I was so surprised at how straightforward the test was. The helper function makes a world of difference for me. I hope it does for you, too!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Immutable Types with Changing State in Swift

Tue, 06 Jan 2015 12:00:50 +0000

Dabble in Swift for long and the functional programming paradigm will most certainly appear on your radar. From conferences to books to blog posts, I’ve seen a lot in the functional programming arena as it relates to Swift.

As I seek to improve my functional programming thought processes and to practice what I’m learning, I found myself struggling with a fundamental concept: immutability. Especially when I’m designing something that, at the very least, appears to require the ability to change state at some point in time.

Immutable changes – A contradiction in terms?

Immutability and changing state was a real struggle for me. The two seemed contradictory actually. How am I supposed to handle changes with things that can’t change??!

And then, with the help of Stack Overflow, a lightbulb came on. As I was perusing FP topics, I ran across a question that expressed exactly what I was feeling. “How can you do anything useful without mutable state?”, the questioner asked. The answer is what illuminated things for me. The key quote from the Stack Overflow answer:

In functional languages, rather than mutating the state of objects, we simply return a new object with the changes we want.

So… instead of thinking about state changes as mutations, think of them as reasons to create something new.

Getting practical with Swift

If I’m going to get pragmatic with this, I have some design decisions to make if I’m going to try and avoid mutating the state of my objects. Rather than design my Types with the intent to update stored properties in-place, I should think about designing them so that the state-change process would actually produce a whole new instance with the transformed (updated) value.

See it in action

I’m a visual person, so for those of you who need to see it in action like me, here’s a short example: Suppose that you’re designing a class that stores a counter (or a score or a total… something like that), and provides a function to let you increment that count.

The mutating way

We could design this class in one of two ways: declare a variable stored property to hold the count. The method would then reassign incremented values to it. This is the opposite of immutable changes:

class Scorekeeper {
    var runningScore: Int
    
    init (score: Int = 0) {
        self.runningScore = score
    }
    
    func incrementScoreBy(points: Int) {
        runningScore += points
    }
}

let scoreKeeper = Scorekeeper()
scoreKeeper.incrementScoreBy(5)
println(scoreKeeper.runningScore)
// prints 5

    <p></p>
    
    
    ### The immutable way
    
    
    OR, rather than mutating the existing variable, we could go an alternate route:  The second way to design the class is to declare a constant stored property.  The method would then produce _new_ instance that stored the new state:
    
    
        class Scorekeeper {
            let runningScore: Int
            
            init (score: Int = 0) {
                self.runningScore = score
            }
            
            func incrementScoreBy(points: Int) -> Scorekeeper {
                return Scorekeeper(score: self.runningScore + points)
            }
        }
        
        let scorekeeper = Scorekeeper()
        let scorekeeperWithIncreasedScore = scorekeeper.incrementScoreBy(5)
        println(scorekeeperWithIncreasedScore.runningScore)
        // prints 5

    <p></p>
    
    
    ### Observations
    
    
    As I look at the code I've just presented, I notice a few things as I contrast the two examples:
    
    
    
    
    
      * The first example uses var to declare the stored property of my Scorekeeper class.  It _has_ to be var so that the value of the property can be changed (mutated).
    
    
      * The second example uses let exclusively.  No in-place mutations occur, so constants are perfectly reasonable to use.
    
    
    
    * * *
    
    
    
    
    
      * The first example's design lends itself to produce interesting and unpredictable side-effects.  If multiple clients hold a reference to my scorekeeper instance, there are two ways for the runningScore to change out from underneath any of those clients:  First, I could simply reassign a value to the runningScore directly.  Second, I could call incrementScoreBy().  Either way, unintended consequences may arise because of the mutation.
    
    
      * In the second example, it's _impossible_ to cause those unintended consequences.  runningScore can't be changed directly (it's a constant), and incrementScoreBy() returns a whole _new_ instance, so all clients would be dealing with the instance that they expect to be dealing with.  No values can be changed out from underneath them.
    
    
    
    * * *
    
    
    
    
    
      * The first example's incrementScoreBy method has no return value.  While I can envision writing a unit test for this, it's not obvious at first glance what I should do.  The method produces a side-effect in my existing instance that I need to know about in order to get the XCTAssert right.
    
    
      * The second example's incrementScoreBy method returns a new Scorekeeper instance.  The unit test for this (to me) is a little more clear.  I simply inspect the value of runningScore of the new instance, and assert that it is [x] points higher than the old instance.  I still have both the old scorekeeper instance _and_ the new scorekeeperWithIncreasedScore, so everything I'd need to ensure the correct point increase occurred is at my disposal.
    
    
    
    ### Conclusion
    
    
    I hear so much benefit that comes from avoiding mutable state, so it was satisfying to finally let my mind reconcile how to manage the state of my own Types immutably.  With the iOS frameworks we have to work with, immutability is a challenge, and _total_ immutable state is not possible (think of the user interface layer where state is stored and updated out of necessity because of how _Apple's_ frameworks and tools are designed). Nonetheless, I found this discovery to be really exciting all the same.

Getting Started with Unit Testing in Swift

Mon, 29 Dec 2014 12:00:50 +0000

Getting set up to write unit tests in Swift, while not difficult, isn’t exactly intuitive. I’ve written several posts and gathered a few resources on unit testing in Swift, but I haven’t yet published a “getting started” guide until now.

Where does one get started with unit testing in Swift when they’ve never gotten started before? Here are 5 steps to help you successfully begin unit testing in Swift:

1 – Create your project

The obvious first step. If you don’t already have a project going, create a new one to organize the code for your app idea. Xcode 6 will automatically generate two “targets” for you. One will be your app’s main module and contains all the code which, when compiled, is meant to be run in the iOS simulator / on an iOS device.

The other will be your test target, which, as the name implies, is where you write your unit test code.

It’s important to note that there are two compilation targets that you’ll be working with as you unit test. Source code that’s part of one compilation target isn’t part of the other by default. This is important to at least know as we move forward in this walkthrough.

2 – Framework considerations: toggle “Defines Module” in your build settings

This step becomes especially critical if you’re using or plan to use a unit testing framework like Quick. It’s not required to use something like Quick, but it can enhance your testing experience if you prefer something other than the out-of-the-box XCTestCase setup.

When you’re working with frameworks, Apple recommends that you make sure the “Defines Module” build setting, found under Packaging, is set to Yes.

If you are relying on, or could be relying on “non-standard” .framework files for your app, make sure you toggle this flag in your Xcode build settings:

3 – Import your main project (module) into your test file(s)

In your test target, at the top of each of your .swift files that contain your XCTestCase classes, write an import statement to bring in your main project’s module. In normal scenarios, your app’s module is named the same as your Xcode project file.

4 – Access control: Public == Testable

Any classes/structs/enums/methods that you need to use in your tests must have a public access control modifier. Internal (default) and private Types and functions can’t be “seen” by your unit tests, so you need to go the public route if you want to test those things.

Previously I’d written on Swift access control and its implications for unit testing. There, I proposed simply adding your main project’s .swift source files to your test target, but it turns out that this can lead to some really obscure issues. An enlightening Twitter conversation also shed some light on the subject, and pointed to the solution of testing only publicly accessible behavior that your Types expose, rather than trying to test internal implementation. That probably deserves a blog entry of its own, but for now, I’ll leave it to say that I’d recommend not adding your .swift source files to your test target, but rather to adjust the access control modifiers of the things you want to test to public.

5 – Write tests!

With your main project imported into a test file, and your Types and functions declared with appropriate public accessibility, you’re all set to begin writing tests in Swift!

Summary

We’ve gone from 0 to ready-to-test in this getting started guide to unit testing in Swift. From here, you may be interested in pursuing other topics related to unit testing in Swift. Check out my ever-growing unit testing resource list for more information!

Swift Unit Testing – Verifying Method Calls

Mon, 22 Dec 2014 13:09:28 +0000

In this unit testing screencast for Swift developers, we explore how to use Test Driven Development to verify method calls.

Getting Started Guide

If you’re new to unit testing or are trying to get set up with unit testing in a Swift project, you might check out my getting started guide before jumping into the screencast.

Screencast

Large / Full-Screen Viewing

GitHub Example

GitHub repo of the example developed in the screencast.

Screencast Transcript

[0:01]

Hi, I’m Andrew from andrewcbancroft.com, and I’m bringing you a test driven development example for iOS in Swift.

The goal of this video is to teach you how to write a unit test to verify that a method was called.

[0:21]

I’ll begin in Xcode 6.1.1 with a side-by-side view of my TestCase class, and my primary View Controller class. This is what Xcode generated for me when I chose to create a new Single View Application.

[0:38]

Imagine a scenario with me: Suppose that as part of your application’s requirements, you mush show an Alert View after your primary view loads. How would we go about using Test Driven Development to implement this “feature”?

[0:53]

Well, we’d write a test, of course – I’ll name it something appropriate like “testUIAlertViewShowsAfterViewLoads”

[1:04]

Next, I need to create an instance of my ViewController class so that I can test it.
But immediately, I run into trouble. It seems that my TestCase class can’t “see” my View Controller class.

[1:17]

Thankfully, it’s a simple fix: Simply add the View Controller class to your Test target.

[1:26]

With everything compiling now, we can move to the next line of test code.

[1:32]

First off, in order to test my View Controller’s Alert View functionality, the Alert View has got to be visible to my test. The easiest thing for me to do at this point is to assume that there will be a property on my View Controller that I can set. This allows me to perform a kind of dependency injection known as “setter injection”. All it really means is that the property is dual-purpose. When the app runs on my iPhone, it’ll use a real UIAlertView. But when I run it in my tests, I can plug in a UIAlertView that I control the behavior of, so that I can verify what I need to in my tests.

[2:16]

The ability to swap in a kind of Alert View that I control really is the “magic sauce” to this whole test-driven operation. In order to know whether or not a UI element was “shown” in a unit test without actually showing something on the screen in a simulator or device, I need to invent something known as a test-double. A fake object, if you will.

[2:44]

My Fake Alert View will have some special capabilities that allow me to know whether the “show()” method was called on it. At the same time, it needs to be able to be substituted in my View Controller for a real UIAlertView.

[3:00]

Since Swift supports object-oriented design, we have inheritance at our disposal here.

[3:07]

I’ll create a nested class inside my test function called FakeAlertView. Notice that it’s a subclass of UIAlertView. What’s great about this is that it meets both of my testing requirements: I can control it’s behavior, and it can be substituted anywhere a UIAlertView is needed.

[3:28]

I’ll finish fleshing out this fake object in a minute. Now that Xcode isn’t complaining about not knowing what a FakeAlertView is, I’ll turn my attention to a new compiler complaint: I don’t have an alertView property on my View Controller yet, so I’ll add one.

[3:50]

There’s just a little more setup that’s needed in order to be able to verify that the show method was called. Since show() doesn’t return anything, we need some way to know that its logic was executed. I’ll do two things to expose this:

[4:06]

I’ll have a boolean property called showWasCalled on my FakeAlertView that is initially set to false.
I’ll override the show() method in this fake UIAlertView subclass. Inside the method body, I’ll reassign the value of showWasCalled to true. That will be enough for me to use inside an XCTAssert, which is coming up.

[4:35]

We’re nearing the finish line here. All that’s left is to call my View Controller’s viewDidLoad method, and write my assertion.

[4:44]

The only thing I’d tell you to make note of is that we need to cast the View Controller’s UIAlertView instance to a FakeAlertView so that we can access the showWasCalled property.

[4:57]

Running the test at this point should produce a failing test, which is exactly what we want (because there’s no code that calls the alertView’s show() method in viewDidLoad()).

[5:08]

The last step to this adventure is to write the production code to pass the test. In viewDidLoad, I call my alertView’s show method and re-run the tests.

[5:19]

And we’re green! Which means we’ve managed to successfully verify that a method was called.

[5:27]

Thanks for watching – I have other resources related to Swift and iOS development at andrewcbancroft.com.

Swift Unit Testing Resources

Fri, 19 Dec 2014 12:00:33 +0000

As I’ve researched Test Driven Development practices in general, and for iOS / Mac applications, I’ve been helped by several sources. I’ve also discovered a few things the hard way, so I’m combining and maintaining this list of resources to help point you in some helpful directions as you adventure in unit testing your iOS apps.

Pluralsight Courses

Play by Play: TDD with Brad Wilson – Awesome, awesome course. I learned some really great techniques from this one. The course is geared toward .Net development using Visual Studio, C#, and Moq, but you should still watch it if you’ve got a subscription – the techniques used can be done on other platforms. I’ve been practicing the techniques in Swift (minus the mocking framework).
TDD as a Design Tool – Geared toward web development with JavaScript / AngularJS, but has some useful patterns.

Blogs

How to write unit tests in Swift with XCTest – Josh Brown gives a nice overview of the unit testing capabilities offered in Xcode and how Swift can be used as the testing language of choice.
Swift: Unit Testing Tips and Tricks – @NatashaTheRobot offers some practical advice in a tips and tricks style blog post.
iOS Unit Testing – Some good introductory articles to browse. Offers a few things in Swift, but much of his content is in Objective-C.
Write your first Unit Test in Swift – Learn how to write the most basic, but still useful, Unit Tests in Swift with XCTest.

User Group Talks

Adam Leonard – Test-Driven Development in Swift using Quick (July 2014) – Talk given by @adamjleonard at a Brooklyn Swift Developers Meetup in July.

At andrewcbancroft.com

Don’t Write Legacy Swift – Motivations for testing your code.
TDD for iOS in Swift – What’s the Goal? – Before actually doing Test Driven Development (TDD) for your iOS / Mac app, it’s really important to ask a very fundamental question: What’s the goal? I discuss two goals for testing your iOS / Mac apps.
Improvements to Unit Testing in Swift with Xcode 7 Much of the pain involved in getting set up to write unit tests in Swift has been alleviated by improvements in Xcode 7. This article analyzes these improvements to ease your unit testing workflow.
Getting Started with Unit Testing in Swift – While getting set up to write unit tests in Swift isn’t difficult, it isn’t exactly intuitive. This 5-step guide will get your project set up to write unit tests in Swift.
An (Almost) TDD Workflow in Swift – When I find myself staring at the screen, paralyzed because I’m “not supposed to write actual production code until the test is written”, I often turn to the workflow that describe in this post, to help me break through to being productive.
Unit Testing Model Layer with Core Data and Swift – Exploration of testing when your project uses Core Data. This post provides a walk-through of setting up an in-memory data store to test with NSManagedObjects.
Swift Unit Testing – Verifying Method Calls – Screencast showing how to verify method calls in Swift unit tests.
Swift Access Control – Implications for Unit Testing – Pointer on how to make code from your main project visible in your Test project.
Creating “Mocks” and “Stubs” in Swift – Essentially a discovery I made about how to create fake objects and override those objects’ methods. You’d do this to isolate and control the object’s behavior in order to enable or ease the testing process.

TDD for iOS in Swift – What’s the Goal?

Tue, 16 Dec 2014 12:00:10 +0000

Before actually doing Test Driven Development (TDD) for your iOS / Mac app, it’s really important to ask a very fundamental question: What’s the goal? What am I aiming for when I say I want to drive my iOS development with tests?

2 Goals of TDD in iOS

A recent course I watched on Pluralsight called TDD as a Design Tool gave me some insight on two goals for doing Test Driven Development:

Make sure my code is in the right place
Make sure my logic is correct

Let’s take them one at a time…

A place for everything, and everything in its place

Believe it or not, Test Driven Development is an extremely powerful tool for ensuring that code is written in the right place. But what do I mean by “the right place”?

In the object-oriented world, “places” are data structures, such as classes and structs, and their publicly accessible methods.

When I employ TDD in a project, I will tend to be driven to making sure my code ends up in the right place. I’ll give you an example:

Starting Places

When I create a new iOS project, Xcode sets me up with a Storyboard, a blank Scene, and a View Controller. Xcode also generates a Test target for me… BUT a what am I most aware of right from the onset? The Storyboard and the View Controller.

The natural inclination, then is to start dragging things onto the design surface and wiring them up to the controller as Outlets and Actions, and off I go!

It’s like I’m lead to the ever-common temptation to put all my code for a given screen in the application inside its corresponding View Controller.

TDD Tension

While I may be led there, and while it may seem convenient, it would seem that TDD wants to start me off in a different “place” altogether. Since TDD asserts that I should not write any code unless there’s a test requiring it to be written, I’d be driven away from my main project into my Test project. My canvas at that point is a fresh XCTestCase class.

UI at this point is not on my mind. Here, I care more about the foundations of the app itself. I begin to consider the application’s domain, and its behavior apart from its user interface. This is very important if I want to truly write decoupled, modular, maintainable code.

Rather than weigh down my View Controller with tons of responsibility, TDD drives me to try and build separate classes to steward small bits of my application. Those small classes can be tested much more easily than trying to get an enormous View Controller instantiated and configured in my test suite.

This is just one small example of how TDD can get you off on the right track to putting code in its proper place.

Your logic was impeccable, Captain

The second goal of TDD in iOS is making sure my logic is correct, or, as Spock would say, “impeccable”.

Does my application’s code do what it should do? Can I write my code in such a way that I can easily verify it? TDD, by nature, pushes me in the direction of being able to verify the accuracy of my code’s logical outcomes… that is, how it behaves.

Fascinating is a word I use for the unexpected

Testing has this way of setting expectations. One thing I’ve really enjoyed about TDD’s notorious red-green-refactor cycle is that I know certainly and immediately when I’ve messed up (ie, run across a “fascinating” situation in Spock terms).

When I write the test, it should fail the first time. If it doesn’t, I’ve messed up.
When I write the code to pass the test and the test fails, I also know I’ve messed up.

Next Steps

With the fundamental goals of TDD in place, I feel more prepared from a foundational standpoint to venture into actuall test-driven practices for iOS.

I am learning so much in the area of testing – it’s a technique I’m practicing regularly, both in Swift and in C# (for fun and for work, respectively), so as I grow and discover ways to optimize the TDD experience in Xcode / Swift, I’ll be sharing them. Stay tuned!

Don’t Write Legacy Swift

Wed, 10 Dec 2014 12:00:51 +0000

“Legacy Swift”. Is that an odd phrase to you, too?

“Legacy” has connotations such as “old”, “difficult-to-change”, “outdated”, etc. Juxtaposing “legacy” and “Swift” would never have crossed my mind until I read Michael Feathers’, Working Effectively With Legacy Code, where he asserts,

Legacy code is simply code without tests.

What an impact those words had on me as I’ve transitioned over to Swift from Objective-C. If it’s true that legacy code is code without tests, it’s easy to see how you and I could be writing legacy Swift, even though Swift is a brand new language!

And whether you agree with Feathers’ definition of “legacy code” or not (he readily admits the potential for controversy with the definition), I think we can all concede that unit testing our code has many benefits and leads to the ability to consistently, objectively verify the quality of our code at the end of the day.

Legacy Swift == Bad Swift

Unashamedly, Feathers writes,

Code without tests is bad code…With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

My take-away from that quote is this: The only way to consistently, objectively verify whether my code is getting better or worse is to execute it and see if the results are what I expected. I can do this in the Simulator / on my device, over and over and over, opening myself up to a never-ending, time-consuming, error-prone testing cycle, OR I can write automated unit tests and run them every time as I make incremental changes to my software.

Testing is hard (for me)

I have not always been the most successful at writing unit tests. Test-driven development (TDD) is difficult for me at times. I often find myself sitting, staring at the screen as if looking into an abyss, unsure of what I’m supposed to do next. (Any of you TDD-ers who’ve figured out how to imagine the structure of your production code prior to it being written so that a test can be crafted first, let me know your tricks!)

I’m growing in this area of writing testable code, and the tests that go along with it. Admittedly, I’m still in the stages of “this is hard”, sometimes.

I have noticed, though, that coding and testing patterns are emerging in my toolbox that are making this process more and more fluid for me.

Testing is worth it

However difficult it is for me, I’m on board with believing that the effort put in to writing tests is worth it in the end. I wrestle with my code to tame it with tests from the start.

If I’m unable to figure out test-first development on a particular problem, I strive to write the tests as jointly with my production code as possible. At all costs, I try to avoid writing the code and saying to myself, “I’ll come back to the tests later”, because I don’t trust myself to keep that promise.

With every product I’ve written and tested, I can testify to the fact that I feel good about that code. I know it works how I intended it to work. I rest assured that when I make changes, I haven’t broken anything I programmed in another session. The tests help me remember what I intended for my software to do. I’m confident that the patterns that evolved out of the tested code are better than what I’d have implemented if I did without the tests. It’s worth it.

What kind of Swift will you write?

The main goal of this post was to get you thinking. Feathers got me thinking, so I thought I’d pass along the challenge: Don’t write legacy Swift!

The good news is that, as Feathers writes,

[Legacy code is code without tests] is a good working definition, and it points to a solution.

And that solution is straightforward: Begin writing tests for your code, and you’ll avoid writing legacy Swift.

Send a Type to Obedience School – Using Swift Extensions for Additional Protocol Conformance

Tue, 02 Dec 2014 19:15:33 +0000

Did you know that you can make any Type (here meaning Class, Enumeration, or Struct), even already-existing ones that you don’t have the source code for, adopt a protocol that it doesn’t normally conform to out of the box?

You can – even if you don’t have the original source code for that Type! It’s a powerful and intriguing proposition. Let’s explore how this is possible.

How, you ask?

Well, as the title of this article suggests, Swift extensions are the way to do it. To demonstrate this capability, consider the following scenario:

You’re using a library that lets you create instances of Bird , and you don’t have access to the source code for the library.
Bird has a property called species and a property called commonName .
You’d like Bird to conform to the Printable protocol, defined in the Swift standard library, so that you can call println(_:) on Bird instances, and have it log something useful to the console.
When println(_:) is passed a Bird instance, you’d like it to print out something like “[species] (ie, [commonName]).”, and have [species] and [commonName] be replaced by the Bird‘s real values.

Remember that you don’t have access to the original source code of Bird . Without Swift extensions, there would be no way for you to tell the compiler that you’d like Bird to adopt and conform to the Printable protocol.

Thankfully, extensions do exist, and we can teach a Bird new tricks, enabling its conformance to Printable .

Protocol Conformance Extension

As stated in the Printable protocol documentation, a Type adopting the Printable protocol must implement a single, read-only property named description .

The extension, then would be implemented as follows:

1// Explicitly specify protocol adoption
2extension Bird: Printable {
3
4    // Implement the required property to make Bird conform to the protocol
5    var description: String {
6        return "\(species) (ie, \(commonName))"
7    }
8}

The magic line in the code above is highlighted. This tells the compiler that Bird will be extended to adopt the Printable protocol.

Of course, the remaining requirement then, is to implement the specification of the protocol so that Bird conforms to it, which is what the body of the extension contains.

Note that simply extending Bird to have a read-only description property will *not suffice for making the Type adopt the protocol. There is no “implicit” protocol adoption in Swift, so you must specify in the extension declaration that you intend for the Type to adopt the protocol.

Conclusion

With this little example, you’ve seen how using an extension can enable a Class, Enumeration, or Struct to adopt and conform to a protocol that it normally wouldn’t out of the box. It’s especially neat that you can do this for any such Type, whether you have control over its original source code or not.

Swift UITableViewDataSource Cheat Sheet

Mon, 24 Nov 2014 22:04:28 +0000

iOS developers will quickly recognize that there are a set of methods that always tend to get implemented when dealing with UITableViews . The problem I consistently face is remembering that set of methods that belong to the UITableViewDataSource (and UITableViewDelegate ) protocols. I find myself option-clicking the protocol name to remember the method signatures I need, since Xcode doesn’t have a way to stub out the methods involved with a protocol (C# developers working in Visual Studio like myself are spoiled!).

I’m sure cheat sheets like this already exist, but I thought, “Why not have one that I can reference from my own blog?”… In fact, I’ve gone ahead and turned the code below into a snippet in Xcode, but just in case I ever lose that, I’ve got this post, which stubs out dummy implementations of the three most common UITableViewDataSource protocol methods.

I’d be delighted if it helped my readers as well, so without further ado, here’s my UITableViewDataSource cheat sheet, which should allow you (and me) to copy and paste directly into our UITableViewDataSource class for a quick start:

 1func numberOfSectionsInTableView(tableView: UITableView) -> Int {
 2    return 1 // This was put in mainly for my own unit testing
 3}
 4
 5func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 6    return dataSourceArray.count // Most of the time my data source is an array of something...  will replace with the actual name of the data source
 7}
 8
 9func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
10    // Note:  Be sure to replace the argument to dequeueReusableCellWithIdentifier with the actual identifier string!
11    let cell = tableView.dequeueReusableCellWithIdentifier("ReplaceWithCellIdentifier") as! UITableViewCell
12    
13    // set cell's textLabel.text property
14    // set cell's detailTextLabel.text property
15    return cell
16}

Distinguishing Between Multiple UIActionSheets with Swift

Mon, 17 Nov 2014 04:17:39 +0000

The challenge when dealing with the presentation and handling of more than one UIActionSheet in a single View Controller is made clear by asking, “How am I going to tell which action sheet I’m dealing with so that I can handle the user’s choice appropriately?”

Presumably, the user’s interaction with one of the action sheets will be different than the other(s), so you’ll need to think through how to distinguish between them, in order to respond to that interaction appropriately.

I faced such a scenario in a recent project, and I thought I’d share my solution. Check out my GitHub example to dive in if you prefer learning by exploration!

Using UIView Tags

Essentially, I chose to make use of the tag property, which all UIView subclasses inherit. The UIView Class Reference documentation specifies that the tag property can be used to identify the view at runtime:

You can set the value of this tag and use that value to identify the view later.

Example

Here’s a quick example showing the setting of this property so that the action sheet can be differentiated when it comes time to handle the user’s choice:

1let actionSheet1 = UIActionSheet()
2        actionSheet1.tag = 0
3        // set other properties, such as delegate, as well as buttons...
4        
5        let actionSheet2 = UIActionSheet()
6        actionSheet2.tag = 1
7        // set other properties, such as delegate, as well as buttons...

Better Solution in Swift?

Simple enough, right? Here’s my only problem with the above implementation if I’m using Swift: We have language features available to us that allow us to avoid setting the tag property to the integer value in-line like I did in this code snippet.

Here, instead of assigning in-line, I’m going to refactor and employ a Swift enumeration to help name the tag. Underneath, there will still be integers involved, but my goal in using an enumeration is two-fold:

Identify the action sheet in code with a name. This should help my code be more coherent and readable.
Encapsulate a single source of truth for the tag values and avoid “magic integers” in my code. While the integers assigned to the tags can be arbitrary, if they ever do need to be changed, I change the enumeration, rather than changing each place where the tag is set or checked to perform branching logic.

The arguments are fundamentally the same as those I made when I wrote about replacing magic strings in Swift and implement precisely the same strategy.

Refactored Example

The refactored version of the code snippet previously presented could look like this, then:

 1enum ActionSheetTag: Int {
 2            // Integer values will be implicitly supplied; you could optionally set your own values
 3            case ActionSheet1
 4            case ActionSheet2
 5        }
 6        
 7        let actionSheet1 = UIActionSheet()
 8        actionSheet1.tag = ActionSheetTag.ActionSheet1.toRaw()
 9        // set other properties, such as delegate, as well as buttons...
10        
11        let actionSheet2 = UIActionSheet()
12        actionSheet2.tag = ActionSheetTag.ActionSheet2.toRaw()
13        // set other properties, such as delegate, as well as buttons...

It’s worth noting that rather than using an enumeration, I could have chosen to define a couple of constants at a scope visible to both my setting of the tag, and the conditional logic I’d use in my UIActionSheetDelegate callback. The end goal and result would be the same: Clarity, achieved by assigning names to the tags, and the avoidance of “magic integers” appearing in my code.

Wrapping Up – UIActionSheetDelegate Implementation

To see how to perform the conditional logic needed in the UIActionSheetDelegate callback method, take a look at this final code snippet:

 1func actionSheet(actionSheet: UIActionSheet, clickedButtonAtIndex buttonIndex: Int) {
 2        if let tag = ActionSheetTag.fromRaw(actionSheet.tag) {
 3            switch tag {
 4            case .ActionSheet1:
 5                handleActionSheet1Interaction() // Function definition omitted for brevity, but ideally you'd implement a function to do something in response to the user's interaction with ActionSheet 1
 6            case .ActionSheet2:
 7                handleActionSheet2Interaction() // // Function definition omitted for brevity, but ideally you'd implement a function to do something in response to the user's interaction with ActionSheet 2
 8            default:
 9                println("Unknown action sheet.")
10            }
11        }
12    }

Summary

I’ve done it before, but by using Swift enumerations again in a new context, I was able to provide better clarity to the intention of my code when I had multiple UIActionSheet instances that I needed to handle in a single view controller. In addition to this clarity, I also encapsulated a single source of truth for identifying my UIActionSheet instances, rather than placing “magic integers” throughout my code. Have a look at (and play with) the example I’ve put up on GitHub for further study and improvement!

The 5 W’s of Swift Extensions

Mon, 03 Nov 2014 19:04:19 +0000

For newcomers to Swift, the concept of extending a Type may be new, so I thought I’d share a high-level overview of Swift extensions in the style of asking the 5 W’s: Who? What? When? Where? Why?

Who

“Swift developers” is a pretty obvious answer, but here are a scenarios to ask yourself about to see if you could make use of Swift extensions:

“I am relying on Types that are found in 3rd party frameworks or libraries and I wish I could add a little bit of functionality that isn’t there out of the box. Can I do that easily?”
“In utilizing Apple’s frameworks I find that a Type could be more powerful if it could just do [x]. Can I add that power to the Apple framework Type?”
“I have written a framework for myself / my team that is used in multiple apps, but I desire to add behavior to one of the framework’s Types that is only relevant in a specific area of one particular app. Can I add that special functionality without changing the framework source?”

If you related to any or all of those scenarios, you could potentially make use of Swift extensions to speed your workflow and make your more organized and clean. Read on for more!

What

Extensions add new functionality to an existing class, structure, or enumeration type.
– Apple Swift Developer Reference

The key word is existing. Hopefully the scenarios listed under “Who” make a little more sense with this information in mind. In all of those cases, you wish to add functionality to Types that have already been designed and implemented.

What I have found to be amazing about Swift extensions is that the word “existing” also applies to Types for which you don’t have access to the original source code. That is powerful!

So extensions are especially useful if you want to add behavior to a Type found in any of the Cocoa / Cocoa Touch frameworks, or a 3rd party’s framework. Additionally, if you’ve created your own libraries and frameworks and you’d like to add behavior without modifying the original source, extensions are a good choice for adding that behavior, especially if what you’re adding doesn’t apply to every single usage of the Type you’re extending.

When

The most logical time to use Swift extensions is when you have a piece of functionality that you want to be able to reuse, and the most reasonable place to put that code is within an already-existing Type. Ideally, the piece of functionality is so closely related to that Type that it just makes sense to extend that Type’s behavior to include your new functionality… “If only I could peek inside that Type’s implementation to inject my new code”, you think to yourself.

If you’re pondering along those lines, then chances are, Swift extensions will aid you in your effort to create more reusable, clean, and organized code.

Perhaps a good question to ask here is, “When not?”. When I see phrases like, “most reasonable place to put that code”, it begs the question, “What does ‘most reasonable’ mean?”. The answer isn’t black and white. I’ll offer what I’ve done in the past as general advice:

As a general rule of thumb, extensions are great for small, simple additions to a Type, rather than long, complex functionality.

If you’re implementing a set of behavior (more than a handful of methods or computed properties), creating a new Type to encapsulate that behavior is most appropriate. After all, that’s what classes and structs do. When deciding on extension vs new Type, they key word that comes to my mind is relatedness. How related is this behavior to the Type I think I want to extend?

Additionally, extensions are limited in the area of maintaining state. Extensions cannot add new stored properties (only computed ones). Creating a new Type to encapsulate the stored properties and the behavior that utilizes them is your alternative solution in this case.

Where

So you’ve decided that you want to create an extension to some class, struct, or enumeration. Where do you put it? My thought on this has always been to create a new .swift file, give it a name that indicates which Type you’re extending, and create the extension inside that file.

So if I want to extend, say, String to have a new method called “sayHello” which printed “Hello” when invoked, I would create a new .swift file called StringExtensions.swift. I’d then place my extension inside:

1extension String {
2    func sayHello() {
3        println("Hello")
4    }
5}

Hey, awesome – you got a bonus How with that quick example! Creating an extension in Swift is that easy.

Why

Swift extensions are powerful. They empower you to add behavior to any class, struct, or enumeration, even if you don’t have access to the original source code.
They are simple and convenient to create.
They encourage code re-use by encapsulating behavior that will be used more than once in your project in a single location.
Additionally, they promote good code organization, leading to cleaner and more readable code when used to add behavior that’s closely related to the Type they’re extending.

Summary

We’ve just explored Swift extensions by analyzing who should use them, what they are, when they’re appropriate, where to put them, and why they’re useful to your development efforts. As a bonus, how to program an extension was given as a simple example.

If you’ve found Swift extensions to be useful to your development efforts, sound off in the comments below! I’d love to hear how you’re utilizing this feature of Swift.

Send Text Message In-App – Using MFMessageComposeViewController with Swift

Tue, 28 Oct 2014 11:00:37 +0000

In a previous walkthrough on sending e-mails in-app, I explored how to use MFMailComposeViewController to allow a user to compose an e-mail without ever leaving your app. I then followed up with a proposal for better-segregating the responsibilities of composing an e-mail and responding to the delegate callbacks out of the View Controller.

I say all this because today, I’d like to walk you through sending a text message in-app using the same pattern as the second article. This walkthrough should be fairly straight-forward on its own, but if you’d like to reference my previous post on clean view controllers, it could be helpful in understanding why I’m not just shoving everything into the View Controller and calling it good.

The Gist

Here’s the gist of the components we’ll need in order to accomplish the task of using MFMessageComposeViewController to send text messages in-app. Presumably, you’d like to allow your users to send a text message to a pre-defined recipient, or maybe you want to pre-populate a message and allow your users to text it to whomever they desire. Any and all of this can be accomplished by implementing this general outline:

Create a class (I’ll call it MessageComposer) that will handle the responsibility of creating/configuring a text message composer.
MessageComposer will also handle the MFMessageComposeViewControllerDelegate callback method (
messageComposeViewController:didFinishWithResult:).
Finally, I’ll program a View Controller to create an instance of this MessageComposer class and present it based upon some user action, such as tapping a button.
Note that to see the example in action, you’ll have to run it on an actual device, because the Simulator is unable to send text messages…

For those who just like to dive in and explore, feel free to head over to GitHub and grab the example project now!

The Details

With the general idea in mind, let’s jump in to discover how to implement the solution…

MessageComposer

While it’s possible to simply put all of this code inside the View Controller, I’d recommend doing your best to avoid it. While this simple example doesn’t add a ton of complexity if you just write it all into your View Controller, a real-world app will undoubtedly be more complex.

In my experience, it’s best to try and segregate out as many responsibilities of functionality from the View Controller where it’s possible. Thankfully, simple examples like this highlight the ease of segregating these responsibilities so that you can begin to employ the pattern for other components that you use within your app.

So in keeping with this idea of nurturing a clean View Controller, I’ve decided to create a new custom class called MessageComposer. Take a look:

 1import Foundation
 2import MessageUI
 3
 4let textMessageRecipients = ["1-800-867-5309"] // for pre-populating the recipients list (optional, depending on your needs)
 5
 6class MessageComposer: NSObject, MFMessageComposeViewControllerDelegate {
 7    
 8    // A wrapper function to indicate whether or not a text message can be sent from the user's device
 9    func canSendText() -> Bool {
10        return MFMessageComposeViewController.canSendText()
11    }
12    
13    // Configures and returns a MFMessageComposeViewController instance
14    func configuredMessageComposeViewController() -> MFMessageComposeViewController {
15        let messageComposeVC = MFMessageComposeViewController()
16        messageComposeVC.messageComposeDelegate = self  //  Make sure to set this property to self, so that the controller can be dismissed!
17        messageComposeVC.recipients = textMessageRecipients
18        messageComposeVC.body = "Hey friend - Just sending a text message in-app using Swift!"
19        return messageComposeVC
20    }
21    
22    // MFMessageComposeViewControllerDelegate callback - dismisses the view controller when the user is finished with it
23    func messageComposeViewController(controller: MFMessageComposeViewController!, didFinishWithResult result: MessageComposeResult) {
24        controller.dismissViewControllerAnimated(true, completion: nil)
25    }
26}

Taking a close look through the comments, you’ll notice the following:

You need to import the MessageUI module.
Rather than hard-code the recipients list, I’ve declared a constant at a global scope for easy access/changeability in the future. It’s actually optional to even supply a recipients list to your composer… it’s just dependent on how you want to use it. Notice that it’s an array of Strings.
MessageComposer inherits from NSObject. This is a requirement of the MFMessageComposeViewControllerDelegate protocol, which MessageComposer conforms to.
There’s a function in there called canSendText that becomes important later on for testing whether or not sending a text message is even possible at the moment on the user’s device. It wraps MFMessageComposeViewController‘s canSendText method to avoid needing to import the MessageUI module in other places (like the View Controller that uses instances of this class).
configuredMessageComposeViewController does what it says it does – it returns an instance of a MFMessageComposeViewController that’s been configured with a list of recipients and a body.
messageComposeViewController:didFinishWithResult: is what gets called with the user either sends the text, or cancels sending a text from the message composer. I’ve written code in that method’s body to simply dismiss the instance of the view controller that called the method.

We’re now ready to head to the View Controller and wire up the components allowing a user to display a MessageComposer!

View Controller

The View Controller is very simple for this example:

 1import UIKit
 2
 3class ViewController: UIViewController {
 4    // Create a MessageComposer
 5    let messageComposer = MessageComposer()
 6    
 7    @IBAction func sendTextMessageButtonTapped(sender: UIButton) {
 8        // Make sure the device can send text messages
 9        if (messageComposer.canSendText()) {
10            // Obtain a configured MFMessageComposeViewController
11            let messageComposeVC = messageComposer.configuredMessageComposeViewController()
12            
13            // Present the configured MFMessageComposeViewController instance
14            // Note that the dismissal of the VC will be handled by the messageComposer instance,
15            // since it implements the appropriate delegate call-back
16            presentViewController(messageComposeVC, animated: true, completion: nil)
17        } else {
18            // Let the user know if his/her device isn't able to send text messages
19            let errorAlert = UIAlertView(title: "Cannot Send Text Message", message: "Your device is not able to send text messages.", delegate: self, cancelButtonTitle: "OK")
20            errorAlert.show()
21        }
22    }
23}

You’ll notice that I create an instance of MessageComposer (the custom class we just defined in previous steps). It’s declared at a scope that can be seen throughout the lifetime of the View Controller (so that the delegate callback can be invoked when appropriate).
sendTextMessageButtonTapped is wired up to a button on my storyboard, and will be executed when the user taps the button.
Checking to make sure the device can send a text message is critical – Note that running the example in the Simulator will execute the else block, because the Simulator cannot send text messages.
If the device can send texts, a configured MFMessageComposeViewController is obtained from the MessageComposer instance. It’s then displayed.
If the device can’t send texts, it’s probably a good idea to alert the user somehow… I’ve chosen a simple UIAlertView.

Summary

In this walkthrough, I’ve demonstrated the mechanics of configuring, displaying, and dismissing a MFMessageComposeViewController, which enables your users to send a text message in-app. Additionally, I’ve attempted to show how to keep the View Controller from handling more than it really should, by segregating out the MFMessageComposeViewController configuration and delegate protocol conformance to another class.

Happy texting!

7 Reasons You Should Write About Swift

Thu, 23 Oct 2014 12:00:13 +0000

If Swift is your iOS/Mac development language of choice, my goal in this post is to persuade you that you should not only write Swift… you should write about Swift. Here are 7 reasons (in the order in which they flowed out of my brain):

1. Swift will never be new again.

How amazing is it that every single Swift developer (besides the ones at Apple) had the opportunity to become a Swift developer simultaneously when Apple announced the new language at WWDC in June of 2014. What an incredible opportunity!

Swift is young, but it’s growing up fast! The content that’s published about Swift today is, in many cases, the first of its kind. You could be that first publisher, helping newcomers to the language and to iOS/Mac development along. You could be contributing the first thoughts, the first guides, the first perspectives to this new world.

Has someone already beat you to the punch on something you’ve thought of writing about? Write it anyway! They didn’t share it the same way you can share it with your unique writing style, background, illustrations, examples, etc. I can’t tell you how often I’ve read something on someone’s blog and it just didn’t click… But two or three blogs later, someone else had the perfect illustration that made total sense in my brain. You can be that someone else! If you write, that is.

2. You know something I don’t know.

Think you have nothing to share? Wrong. You do. You know something I don’t know about Swift. You may know a lot of somethings I don’t know about Swift. I want to learn from you! Many others would join me in that sentiment. The greater the variety in terms of difficulty-level, content, and style, the better (in my opinion).

Contribute to the learning of others – you’ll be glad you did (and we will, too)!

3. Writing leads to better understanding.

When you write about Swift, especially in the op-ed realm, you put yourself out there in what feels like a very vulnerable position. In some cases, you’ll be off-target. I have been before. What I found is that folks were not hateful or insulting to me (after all, I’m just sharing bits of what I’m learning). Comments led to very huge lightbulbs going off in my brain and I wrote about those lightbulbs in a second post. I understand things better now that I’ve written, showed my lack of understanding, and written more, once I received constructive feedback that I needed from those who knew better than I.

In other cases, you’ll write about Swift, and the very act of writing to help others solidifies the concept you’re explaining in your own mind. It’s astounding to me how the attempt to educate another illuminates things that could have never been illuminated any other way.

Write what you know – it’s good for us, and it’s good for you.

4. Writing shapes the Swift developer community.

The Swift developer community is the first community that I’ve ever gotten involved in, and it’s truly been amazing to connect with other Swift developers. From Twitter and from direct contact through e-mail, I’ve had the opportunity to brainstorm with and learn from others who are also programming in Swift.

The Swift developer community is new… it’s vibrant… and it’s active and waiting for one more contributor. Will you be that new Twitter handle tweeting about Swift? Will you be that new blogger sharing your thoughts and ideas with the community? Join us. Shape us.

5. Great opportunities may lie around the corner.

Swift has brought me several great opportunities in terms of building business and building friendships. Who knows what’s next?

Objective-C isn’t going anywhere, but neither is Swift! Employers, while not yet able to legitimately request Swift devs with 5+ years of experience (though some will undoubtedly try), will inevitably desire Swift developers. The sooner you embrace Swift, the more experience you’ll be able to report.

But how amazing would it be to say to a future potential employer, “I’ve been writing Swift since June of 2014, but I’ve also been writing about Swift at www.myBlog.com for nearly as long.”?

In my experience, Swift has also brought me new friendships and an expanded network. I “know” more Swift developers than I do developers of all other languages combined. I follow more Swift bloggers than any other language’s bloggers. I’d love to follow your blog and engage with / share thoughts about what you’re learning.

Who knows what else awaits? The potential for great opportunities are ripe right now. Join in!

6. Reading is more time-efficient for many. Write!

I love screencasts. I listen to podcasts every time I’m in the car alone. But you know what? I can read a blog post or a transcript faster than I can watch a screencast or listen to a podcast. Written content about Swift has the potential to greatly increase the speed and efficiency at which others can solve their problems.

Screencast – do it! Podcast – you bet!

But don’t forget to write, too!

7. Your written words will outlast you

Not a shocker, obviously. This is the “leave a legacy” argument. One way to make a lasting impact is to write what you’re thinking and learning about this language that you’re intrigued by or maybe even passionate about.

Scott Hanselman is one of my favorite people in the developer / educator world. He’s written about writing and impact, and he’s said it way better than I can. Essentially, his argument is that you’ve only got a finite number of keystrokes left in your life before you die. And he’s right. The point of the linked-to article is that if you desire your precious, remaining keystrokes to have the furthest reach and the highest potential impact, you should write… and not just write, but write on the web.

Some love Stack Overflow. Others love forums, or Reddit, or whatever. I prefer blogging. Whatever you favor, your writing on the web travels far and impacts many. I’ve received e-mails that have spawned blog posts and replies with link to the blog post, rather than a direct reply. Why? Well, if one person is asking, others probably are too – why not put it out there for others to benefit from as well?!

In Closing

I love reading about Swift and I’ve benefited from many in the community who are working hard to make programming in Swift a great experience for everyone.

I enjoy writing about Swift, myself. I write about other things too, of course (see the right-hand sidebar). But for the 7 reasons just mentioned, I’ve been writing a lot on Swift these days, and I’ve really had a great time doing it.

My hope is that this post has sparked some ideas in you, or perhaps even motivated you to get in the game and start contributing your share of bytes to the Swift conversation. Holler at me on Twitter if you’re currently publishing about Swift – I’d love to connect with what you’re creating!

Resolving “Variable used within its own initial value” Error in Swift

Mon, 20 Oct 2014 13:50:52 +0000

While experimenting with a few things today, I experienced this compiler error:

Variable used within its own initial value

Let me describe the situation I was in…

I was playing (in a playground, no less) with closures, trying to mimic some behavior that I’ve recently learned about in Scala. Essentially, I was trying to implement a factorial function as a closure, and I was trying to do it recursively (that is, without using a for/while loop). Here’s what I wanted to do:

1let factorial = {
2    (n: Int) -> Int in
3    if (n == 0) {
4        return 1
5    } else {
6        return n * factorial(n - 1)
7    }
8}

If you’ve seen factorial before, the above implementation isn’t new. The “base case” that will let the recursion stop is the expression if (n == 0), and the recursive case is in the else block, where factorial gets called again within its own body’s definition. Only problem is… this doesn’t work in Swift 1.0.

Apparently, the closure (which is being initialized and assigned to the constant named “factorial”) hasn’t had a chance to fully initialize itself before the name factorial is used within the body.

The frustrating part is that I really didn’t want to type the letters v-a-r to implement my solution. But alas, as Stack Overflow says, the following solution to the “initial value” error works:

 1var factorial: (Int) -> Int
 2factorial = {
 3    (n: Int) -> Int in
 4    if (n == 0) {
 5        return 1
 6    } else {
 7        return n * factorial(n - 1)
 8    }
 9}
10
11factorial(5)
12// Produces the correct result of 120

Of course, there’s absolutely no reason for the implementation to be a closure – I was simply experimenting. Here’s the solution that I actually prefer… a good ole named function definition:

 1func factorial(n: Int) -> Int {
 2    if (n == 0) {
 3        return 1
 4    } else {
 5        return n * factorial(n - 1)
 6    }
 7}
 8
 9factorial(5)
10// Produces the correct result of 120

Rotate Animation in Swift

Thu, 16 Oct 2014 02:57:24 +0000

Updated on December 14, 2015 – Swift 2.0 + new examples

With this post, I intend to wrap up my series on animations as UIView Extensions in Swift… for now. Truthfully, these ideas flowed out of a real-world app that I was working on, which required various simple animations (fading in/out, sliding text, and now, rotating a view 360 degrees).

Since I’ve given two other detailed walk-throughs on the topic, I’ll try to be to-the-point on this one.

As with the others, I’ve created a GitHub project for you to see the animation in action, and even modify to your liking.

Resources

Rotate Animation Example Project

The Extension

The following code adds a method to any UIView instance called rotate360Degrees. The code can be placed in a Swift file called “UIViewExtensions.swift”:

 1import UIKit
 2
 3extension UIView {
 4    func rotate360Degrees(duration: CFTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
 5        let rotateAnimation = CABasicAnimation(keyPath: "transform.rotation")
 6        rotateAnimation.fromValue = 0.0
 7        rotateAnimation.toValue = CGFloat(M_PI * 2.0)
 8        rotateAnimation.duration = duration
 9        
10        if let delegate: AnyObject = completionDelegate {
11            rotateAnimation.delegate = delegate
12        }
13        self.layer.addAnimation(rotateAnimation, forKey: nil)
14    }
15}

The only critical thing to notice in the above code snippet is the value passed to the CABasicAnimation constructor. The "transform.rotation” string is what sets things up to go spinning, and the string must be typed exactly as-is for the animation to work.

As in my previous animation posts, I provide myself a couple of parameters to set for a little bit of customization if I want it. Since the parameters have default values, the method can be invoked by writing someUIViewInstance.rotate360Degrees() for simple cases. For more “advanced” scenarios where you need to adjust how long the animation takes, or to perform some logic after the animation completes, you can pass in a duration value other than 1.0, assign a completionDelegate, or both, depending on your needs.

Check out the GitHub example for details on how to configure things for the completionDelegate. I’ll be walking through that more “advanced” case shortly as well.

Example

Perhaps you’re asking, “Why spinning UIViews?”…

In my example, I’ve proposed a simple button that would be used to refresh the view / data in a real-world scenario. When the button is tapped, I want the button to rotate 360 degrees.

In the “advanced” example, I want it to rotate continually until a process of some sort finishes, at which point the animation stops until initiated again. Take a look:

Simple Case – Rotate Once

Once the UIView extension is in place, the simple use case is… well… pretty simple:

1class ViewController: UIViewController {
2    @IBOutlet weak var refreshButton: UIButton!
3    
4    @IBAction func refresh() {
5        self.refreshButton.rotate360Degrees()
6        // Perhaps start a process which will refresh the UI...
7    }
8}

“Advanced” Case – Rotate Until Process Finishes

In my example, I decided to simulate a long-running process by using a custom-built Timer class, heavily inspired by Samuel Mullen’s implementation (with a few modifications to fit my needs). If you’re looking through the GitHub example, try not to get too bogged down in the details of the Timer, unless it just intrigues you. In real life, you may decide perform a web service call to refresh your data model, or refresh your UI (or both). Whatever the case may be, you’ll likely end up with similar logic:

Refresh button is tapped
If the button isn’t already rotating, make it start
Kick off a process that may take some time
The animationDidStop callback is going to be invoked after the view has spun a full 360 degrees. If the longish-running process is finished, the button can stop spinning. Otherwise, it needs to spin around another time. This will be repeated until the longish-running process is complete.

Confession: I’m not entirely thrilled with the rampant mutability in my implementation, but I couldn’t figure out a way to do what I wanted in an immutable way. It does work, however. Just be aware that if you’re really a stickler for immutability in your classes, you’re going to hate this implementation (and I’d love to hear constructive feedback on how I could improve it!). Here’s the code for the bullet-pointed process just outlined:

 1class ViewController2: UIViewController {
 2    @IBOutlet weak var refreshButton: UIButton!
 3    // var, var, var!  So much for immutability :/
 4    var isRotating = false
 5    var shouldStopRotating = false
 6    var timer: Timer!
 7    
 8    @IBAction func refresh() {
 9        if self.isRotating == false {
10            self.refreshButton.rotate360Degrees(completionDelegate: self)
11            // Perhaps start a process which will refresh the UI...
12            self.timer = Timer(duration: 5.0, completionHandler: {
13                self.shouldStopRotating = true
14            })
15            self.timer.start()
16            self.isRotating = true
17        }
18    }
19    
20    override func animationDidStop(anim: CAAnimation!, finished flag: Bool) {
21        if self.shouldStopRotating == false {
22            self.refreshButton.rotate360Degrees(completionDelegate: self)
23        } else {
24            self.reset()
25        }
26    }
27    
28    func reset() {
29        self.isRotating = false
30        self.shouldStopRotating = false
31    }
32}

Summary

I tried to strike a balance between making these simple animations easy to call on my labels, buttons, and other UIView subclasses, and just shoving everything into a UIViewExtensions.swift file. The related set of animations just seemed like a really nice use case for Swift extensions, and the strategy served me well in a recent project. Hopefully the series has sparked some ideas in your mind for how to employ extensions to enhance the capabilities of a class so that your code is easier and cleaner to write.

As always – thanks for reading!

You might also enjoy…

Fundamentals of NSNotificationCenter in Swift

Wed, 08 Oct 2014 18:27:47 +0000

Updated on September 19, 2016 – Xcode 8 & Swift 3.0

The goal of this post is to help you grasp the fundamentals of using NSNotificationCenter in your Swift iOS app. The topic isn’t necessarily new, and there’s no difference except syntax between Objective-C and Swift implementations involving NSNotificationCenter. Even still, I’m hoping to add to the understanding of this useful tool by giving a fully-working example on GitHub (Swift 2.3 and Swift 3.0), and by sharing the insight that’s clicked in my own brain as I explain the example.

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

First things first: What is this thing?

When I first heard NSNotificationCenter, I thought “push notifications”. However, NSNotificationCenter has nothing to do with sending or receiving push notifications in iOS. Rather, it is a communication tool internal to your app. It provides a way for one instance of a class/struct to notify one or more other class/struct instances about something. The goal in doing this is to enable those 1+ other class or struct instances to take appropriate action based the communication they receive. An common analogy comes to mind: think “radio tower”. NSNotificationCenter is the central hub that acts as a broadcaster of notifications. If that still seems vague, hang tight – seeing the example below should help it all come together for you.

Should I use it?

Before diving into the basic workflow, it’s worth asking, “Should I use NSNotificationCenter, or is there some other option that’s more appropriate for my app’s internal communication needs?”

It is often the case that there is more than one way to solve a problem in software development, and it’s no different with NSNotificationCenter. There is more than one way to accomplish instance-to-instance communication at run-time. I’ve written about two such forms of communication in my post titled NSNotificationCenter vs Delegation – An Analysis. It may be worth reading up on, just to make sure you’re using the right tool for the right kind of communication.

Basic Workflow

NSNotificationCenter.default is at the center of it all when it comes to this discussion.

The basic workflow of using NSNotificationCenter goes something like this:

Since `NSNotificationCenter` is in the business of broadcasting notifications, the first thing to do is to specify a way to uniquely identify a notification. This is most easily accomplished by defining a constant string value (using `let` syntax in Swift) at a globally-visible scope. The string constant you define here will serve as a “notification key”. If you have several notification keys that you need to define, perhaps creating a new .swift file called “NSNotificationCenterKeys.swift” is a clean way to do this.
Steps 2 and 3 of the workflow go hand-in-hand. Without implementing the one, implementing the other doesn’t make much sense… Step 2 is to post a notification to `NSNotificationCenter.default` identified by the key that was created in step 1. In radio terms, the class or struct instance desiring to post a notification asks the default notification center to broadcast the notification key defined in step 1… this class or struct instance chooses the right situations to request that the notification key be sent out based on business logic specific to the project’s requirements.
Step 3 is to set up 1+ class or struct instances to be listeners, or more properly, observers of a particular notification. Such an observer will be able to tell that it’s “heard” the notification, because it will be “listening for” a notification that uses the same key that was created in step 1, which is the key used in step 2 to post the notification. In radio terms, the listener is tuned in to the default notification center’s station that’s identified by that special key defined in step 1 and posted in step 2. So you see now why steps 2 and 3 go hand-in-hand. With no posts to the notification center on that station, tuning in will do no good. Likewise, posting a notification but having no listeners accomplishes nothing.
Finally, what should the observing instance do once it’s detected the notification? Well, when signing up to be an observer, the instance must also specify the name of a function that will be called upon receipt of the notification it’s listening for. Whatever action or routine is appropriate to perform at that time is what that function’s implementation should contain.

Visualizing NSNotificationCenter by Example

If you’re like me, you need less talk and more example, so I’ve created a simple Xcode project that you can grab over at GitHub (Swift 2.3 and Swift 3.0). Running the project will allow you to click through a series of tabs in a tab view controller, post a notification, and see the results. It looks much like this:

Working back through the basic workflow with this example you can find the following key aspects of implementing a NSNotificationCenter solution (lines of code to pay special attention to will be highlighted).

Steps 1 and 2:

I’ve chosen my FirstViewController class to be the one that defines the global constant with a unique notification key and tells the default notification center to post that notification when the “Notify!” button is tapped:

 1// 1. Globally define a "special notification key" constant that can be broadcast / tuned in to...
 2let mySpecialNotificationKey = "com.andrewcbancroft.specialNotificationKey"
 3
 4class FirstViewController: UIViewController {
 5    @IBOutlet weak var sentNotificationLabel: UILabel!
 6    
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9        NotificationCenter.default.addObserver(self, selector: #selector(FirstViewController.updateNotificationSentLabel), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
10    }
11
12    // 2. Post notification using "special notification key"
13    @IBAction func notify() {
14        NotificationCenter.default.post(name: Notification.Name(rawValue: mySpecialNotificationKey), object: self)
15    }
16    
17    func updateNotificationSentLabel() {
18        self.sentNotificationLabel.text = "Notification sent!"
19    }
20}

Steps 3 and 4:

Both of these steps are implemented in very similar ways in my SecondViewController and ThirdViewController classes. The code should speak for itself:

 1class SecondViewController: UIViewController {
 2    @IBOutlet weak var notificationLabel: UILabel!
 3    
 4    override func viewDidLoad() {
 5        super.viewDidLoad()
 6
 7        // 3.  Observe (listen for) "special notification key"
 8        NotificationCenter.default.addObserver(self, selector: #selector(SecondViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
 9    }
10
11    // 4.  Implement function to act on that notification
12    // The name of this function must match the selector argument you specified when you called addObserver()
13    func actOnSpecialNotification() {
14        self.notificationLabel.text = "I heard the notification!"
15    }
16}
17
18
19class ThirdViewController: UIViewController {
20    @IBOutlet weak var notificationLabel: UILabel!
21    
22    override func viewDidLoad() {
23        super.viewDidLoad()
24        NotificationCenter.default.addObserver(self, selector: #selector(ThirdViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
25    }
26    
27    func actOnSpecialNotification() {
28        self.notificationLabel.text = "I heard the notification, too!"
29    }
30}

Finally, to reiterate the explanation in visual form and for easy reference, I’ve annotated a screen shot taken from the project’s code:

Removing an observer

One final requirement for working with NSNotificationCenter is to remove an observer when it no longer needs to listen for notifications. When might this situation arise?

When the observer is no longer referenced and thus deallocated from memory, it should tell the default notification center that it can be removed
When some condition occurs in your application that renders it no longer relevant for an instance to listen for notifications

The first situation is the most common, and is for sure the scenario that we want to protect against, so that the default notification center doesn’t continue to manage observers that are no longer capable of actively listening. To satisfy the requirement of removing an observer when an instance is deallocated, we could provide something like the following deinit method:

1deinit {
2    NSNotificationCenter.default.removeObserver(self)
3}

For the second bullet point, you can simply write the same line of code that’s highlighted in the above snippet, wherever it makes sense for you to tell the default notification center when it’s appropriate to stop sending messages to the instance in question.

Summary

NSNotificationCenter is particularly useful when there are multiple class or struct instances that need to take action based on something that happens elsewhere in your application. For this type of scenario, NSNotificationCenter can be a great tool to wield as you develop apps in Swift for iOS.

You might also enjoy…

NSNotificationCenter vs Delegation – An Analysis

Swift Alternative to Objective-C Macros

Wed, 01 Oct 2014 17:58:46 +0000

I’ve previously written about using enumerations in Swift to encapsulate special values that could end up falling into the “magic string” category if they were to simply be scattered in-line throughout your code. The primary example I proposed for such a “magic string” replacement was Storyboard Segue Identifiers. These special identifiers have such a specific purpose that felt to me like a natural fit to create a Type in the form of an enumeration (which I called SegueIdentifier) to group them all together in one place so that I could easily find them and modify them, should I ever need to do so.

I still like that solution for groups of things, but it’s a lot of “ceremony” to use enumerations for encapsulating everything that may have been implemented as a macro expression or a static global constant in Objective-C.

I ran across this in the Swift developer documentation that I think will be of help to folks who want to avoid “magic values” throughout their code, but don’t want to employ enumerations where they’re not the best fit. Here’s a snippet:

So there you have it, folks! One easy alternative to your former #define habits when you’re working in Swift is to simply declare a constant (using the let keyword) instead. The word “constant” is key – the last thing you want to do is declare a variable in some global scope (using the var keyword) where the value of the identifier could be changed somehow, if even by accident.

Organizing #define Replacement Constants

The question that naturally comes next is, “Where do I declare a constant that I’m using to replace a #define?”

The answer is not black and white – a few factors play into your decision of where to declare them.

In general, I would probably declare such a constant in the location that’s closest to the context in which it is used. Here are a few examples to consider:

If it's only going to be used in a single function, it's reasonable to declare the constant locally at the top of that function, or anywhere near where it will be used.

If it's only used in a single class/struct, perhaps declaring it at the top of that class/struct is a good idea.

If it's going to be a value that's used in multiple classes/structs, it may be time to create a new .swift file and place it there so that you can find it again.

Start with a very small scope, and as that constant broadens in its usage throughout your project, gradually move it to more and more globally visible locations.

Using a globally-defined constant is exactly what I did for checking the iOS version number of a user’s device. I simply created a new file called “iOSVersions.swift”, placed my global constant definitions in it, and was able to reference those constant names everywhere in my project that I needed to perform conditional logic based on the iOS version number.

Summary

A simple Swift alternative to a #define macro in Objective-C it to define a constant at a scope that’s appropriate for where you plan to use that constant.

Slide In Animation in Swift

Wed, 24 Sep 2014 18:25:52 +0000

In a previous post about fade animations in Swift, I demonstrated how to use a class extension to add the ability for any UIView instance to easily call fadeIn() or fadeOut() on itself. This strategy was nice – the animations, while simple, would have cluttered my code each time I used them, had I not encapsulated them somewhere. Employing class extensions in Swift seemed a natural way to provide this functionality to UIViews.

Well, I liked the idea so much that when it came time for me to implement a slide animation, I kept the same strategy, and I’d like to share my implementation with you today.

Animation demo

To start off with, here’s a sample of what the animation does:

The easiest way to get the gist of what I’ve done is to head over to GitHub and download the example Xcode Project. In real life, I’ve combined the fade animations and the slide animation into the same UIView extension, but for education’s sake, I’ve split them out so you can easily see the moving parts.

Implementation overview

There are three major parts to this example implementation, which I’ll explain in detail shortly. Here’s the overview:

1 – Create the UIView extension

 1import UIKit
 2
 3extension UIView {
 4    // Name this function in a way that makes sense to you... 
 5    // slideFromLeft, slideRight, slideLeftToRight, etc. are great alternative names
 6    func slideInFromLeft(duration: NSTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
 7        // Create a CATransition animation
 8        let slideInFromLeftTransition = CATransition()
 9        
10        // Set its callback delegate to the completionDelegate that was provided (if any)
11        if let delegate: AnyObject = completionDelegate {
12            slideInFromLeftTransition.delegate = delegate
13        }
14        
15        // Customize the animation's properties
16        slideInFromLeftTransition.type = kCATransitionPush
17        slideInFromLeftTransition.subtype = kCATransitionFromLeft
18        slideInFromLeftTransition.duration = duration
19        slideInFromLeftTransition.timingFunction = CAMediaTimingFunction(name: kCAMediaTimingFunctionEaseInEaseOut)
20        slideInFromLeftTransition.fillMode = kCAFillModeRemoved
21        
22        // Add the animation to the View's layer
23        self.layer.addAnimation(slideInFromLeftTransition, forKey: "slideInFromLeftTransition")
24    }
25}

2 – Set up the storyboard

From the Utilities panel, drag over a regular View to act as a wrapper for the sliding text (use a regular View, not a Container View)
From the Utilities panel, drag a Label into the wrapper view and create an IBOutlet to your View Controller for the Label
Set up auto layout constraints for both the wrapper and the Label
Set the wrapper view’s Clip Subviews property to checked in the Attributes Inspector

3 – Code the View Controller – initiate slide animation.

In my example, I wired the trigger up to a button’s touchUpInside action. For you, it may be something different that triggers the animation to begin. Whatever it may be, call slideInFromLeft() on your UIView instance (in my case, the UILabel).

1@IBAction func slideTextButtonTapped(sender: UIButton) {
2        self.slidingTextLabel.slideInFromLeft()
3        self.slidingTextLabel.text = "Sliding Text!"
4    }

Notice that directly after the call to slideInFromLeft(), I change the label’s text property to contain the new text that I want to slide in.

Implementation details

The real work all happens inside the UIViewExtensions.swift file where I add the slideInFromLeft() function to a UIView’s arsenal.`

UIViewExtensions.swift

First to note is that I’ve provided a few default values in the function’s signature so that the animation can be initiated as simply as writing viewInstance.slideInFromLeft(), or as “complicated” as providing argument values to both duration and completionDelegate:

1extension UIView {
2    func slideInFromLeft(duration: NSTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
3    // Implementation...
4}

Next, I create a CATransition instance, and set its delegate property if a completionDelegate is passed when the function is called:

1extension UIView {
2    func slideInFromLeft(duration: NSTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
3        let slideInFromLeftTransition = CATransition()
4        
5        if let delegate: AnyObject = completionDelegate {
6            slideInFromLeftTransition.delegate = delegate
7        }
8            // Remaining implementation...
9}

I then go about configuring the animation’s properties. To achieve the “slide in from left” animation, I set the type and the subtype properties to kCATransitionPush and kCATransitionFromLeft, respectively. These two combined create the “slide in” effect. Other properties that I set are duration, timingFunction, and fillMode:

 1extension UIView {
 2        // ...
 3        slideInFromLeftTransition.type = kCATransitionPush
 4        slideInFromLeftTransition.subtype = kCATransitionFromLeft
 5        slideInFromLeftTransition.duration = duration
 6        slideInFromLeftTransition.timingFunction = CAMediaTimingFunction(name: kCAMediaTimingFunctionEaseInEaseOut)
 7        slideInFromLeftTransition.fillMode = kCAFillModeRemoved
 8        
 9        // ...
10    }
11}

To keep things simple, I only allow myself to customize the duration property, and optionally provide a completionDelegate when I call the function… the other properties are more fundamental to how the animation should perform, so I encapsulate the implementation here so that it’s an abstraction when I actually call slideInFromLeft() later in my View Controller.

The last thing I do is add the animation that I just created and configured to the view’s layer property. “The view” here would be the instance of UIView that has calls slideInFromLeft():

1extension UIView {
2        // ...
3        self.layer.addAnimation(slideInFromLeftTransition, forKey: "slideInFromLeftTransition")
4    }
5}

Storyboard setup details

This is probably the more challenging piece, just because it takes some tweaking to get the auto layout constraints just right.

My general setup in this example is a Label wrapped inside a containing UIView. I made sure to simply drag over a regular View (not a Container View) from the utilities pane on the right. I then dragged a Label inside the “wrapper” view.
I set wrapper view’s width to a value that was less than the entire screen’s width. This was so that the sliding view didn’t appear to slide in from off-screen and slide out off-screen. Instead it appears to slide in from underneath the wrapper view… You’re welcome to customize this how you want (or avoid the containing view altogether if you find it’s not needed for your specific implementation).
For the wrapper view, I’ve set constraints for
- Center Horizontally in Container
- Top Space to Top Layout Guide
- Width
- Height

Next, I made sure that my label that will be sliding is inside the wrapper view. I set its constraints to

Center Horizontally in Container
Center Vertically in Container
Equal Widths
Equal Heights

The last thing I do in the storyboard before wiring things in the View Controller is to select the wrapper view and make sure it’s Clip Subviews property is checked. As an experiment, toggle this option and watch the effect it has on the animation’s appearance:

View controller implementation

The final piece of the setup is to wire things up to the View Controller and animate the Label.

Since I needed to reference the Label containing the text that I’d like to animate, I created an IBOutlet from my storyboard to my View Controller:

1class ViewController: UIViewController {
2    @IBOutlet weak var slidingTextLabel: UILabel!
3    // ...
4}

Next, I needed a way to initiate the slide in animation – I decided that wiring it to a button’s touchUpInside action would be sufficient for the example, so I created an IBAction from my Storyboard to my View Controller for that purpose.

Within the body of that IBAction, I wrote the call to slideInFromLeft() on my slidingTextLabel instance:

 1import UIKit
 2
 3class ViewController: UIViewController {
 4    // ...
 5    @IBAction func slideTextButtonTapped(sender: UIButton) {
 6        self.slidingTextLabel.slideInFromLeft()
 7//      self.slidingTextLabel.slideInFromLeft(duration: 1.0, completionDelegate: self) // Use this line to specify a duration or completionDelegate
 8        self.slidingTextLabel.text = "Sliding Text!"
 9    }
10    
11    // ...
12}

If you have need to specify a duration or a completionDelegate, there’s a commented out line of code there that shows an example of passing those arguments to the slideInFromLeft() function.

If you specify a completionDelegate to the slideInFromLeft() function, a method called animationDidStop() will be called when the animation finishes. Inside this callback function, you can write code to perform any action you’d like to have happen after the animation has finished. If you don’t set a completionDelegate, there’s no need to have this method override in your code:

1override func animationDidStop(anim: CAAnimation!, finished flag: Bool) {
2        println("Animation stopped")
3    }

That’s a wrap, folks! Hope this strategy is helpful for you as you think about where to place code for your UIView animations.

You might also enjoy…

Swift iOS Version Checking

Thu, 18 Sep 2014 04:44:36 +0000

While iOS 8 is now officially in the wild, it may take a bit of time to reach the level of user adoption that iOS 7 had accumulated over the past year. If you plan to target the widest number of users for your app (at least in these early days of the iOS 8 roll-out), it’d probably be wise to include iOS 7 in your target audience.

When accommodating iOS 7 users, you’ll inevitably run into instances where you need to check which iOS version the device is running, so that you can implement a fall-back plan for older versions of iOS.

In Objective-C, I’ve seen this accomplished by using pre-processor directives, or with introspection. Swift, however, has no pre-processor directives in v1.0, and only objects which conform to the NSObject protocol can utilize the respondsToSelector: method call. What to do?

As it turns out, Apple has guidance that would actually work for both Objective-C and Swift – It involves simply checking the NSFoundationVersionNumber of the device against one of the pre-defined values defined in NSObjCRuntime.h.

To accomplish this in Swift, you can create a new Swift file (I called mine “iOSVersions.swift”) to hold the following code:

1let iOS7 = floor(NSFoundationVersionNumber) <= floor(NSFoundationVersionNumber_iOS_7_1)
2let iOS8 = floor(NSFoundationVersionNumber) > floor(NSFoundationVersionNumber_iOS_7_1)

Whenever you need to check which iOS version the device is running, you can simply use the iOS8 / iOS7 constants that you just defined – they’re accessible in other Swift files throughout your project:

1if iOS8 {
2  //Do some iOS 8-specific things that may not be supported in older versions
3} else {
4  //Implement your fall-back plan for older versions of iOS
5}

With these little snippets, you should be empowered to support iOS 7 while taking advantage of new iOS 8-only features and APIs. You can also begin to move away from deprecated ways of doing things, while not breaking your app for iOS 7 users, so long as iOS 7 retains a significant slice of the iOS version pie.

Create Documentation for your Swift Playground

Wed, 10 Sep 2014 03:44:16 +0000

As I opened Apple’s latest “Patterns Playground” blog post, I was impressed with the look and feel. Rather than create the documentation as comment blocks, they managed to put in sharp-looking notes and explanations before each code example / experiment. It’s like an interactive book, reminiscent of the Swift Programming Language iBook! Here’s a snippet of what their Playground looks like:

[][1]

Of course, my immediate question / thought was, “How’d they do that?! Can I do that? I want to do that!”. I didn’t know it at the time of this publication, but apparently Apple has some pre-release documentation out on developer.apple.com, detailing how all this is done. I (as usual) did it the hard way and hacked my way through it. I figured I’d go ahead and share my discoveries alongside the official documentation from Apple.

I’m already a believer in using Playgrounds for teaching. The read-example-experiment loop is so easy in the Playground environment. I think using this documentation technique has the potential to enhance the Playground experience even more to create professional, sharp-looking educational material_. _

For this post, I wanted to take a simple example (the File -> New Playground playground) and convert the comment-style documentation into “fancy” documentation.

Before:

[][2]

After:

[][3]

Let’s explore.

The Gist

Create yourself a playground (and note where you save it).
Navigate to where the .playground file is saved in Finder.
Right-click the .playground file, and choose “Show Package Contents”.
Add a new folder named “Documentation”.
Create a new HTML file in the Documentation folder. It should contain the HTML markup and the text explanation that you’d like to enhance your playground with. Make sure it is a well-formed HTML document by the time you’re finished creating it. I describe a quick way to jumpstart your documentation process at the end of this article…
Although optional, I’d recommend styling your HTML file with appropriate CSS. Adding a CSS file and referencing it within the HTML file you created is probably a good idea (and this is allowed for Playground documentation).
Open contents.xcplayground with the text editor of your choice by right-clicking and choosing “Open With”.
Modify the XML so that the
element contains a node as shown in the highlighted code lines in the example below. Be sure to replace the relative-path value with the name of the HTML file you created in step 5 (I named mine “doc-fragment-0.html”):



  9.  Save, and open the playground in Xcode 6.  Your Playground should now contain documentation!

As a way to jump-start my own Playground documentation, I simply borrowed one of the HTML files and the CSS file from Apple's Patterns Playground.  Then I modified the markup to contain the educational material I wanted for _my_ playground, customized the styles to what I wanted, added the <span class="lang:default decode:true  crayon-inline "><documentation></span> node to the contents.xcplayground file, saved, and voila:  Fancy documentation!

&nbsp;

 [1]: http://www.andrewcbancroft.com/wp-content/uploads/2014/09/Patterns_playground.png
 [2]: http://www.andrewcbancroft.com/wp-content/uploads/2014/09/MyPlayground_WithDocumentation_playground_before.png
 [3]: http://www.andrewcbancroft.com/wp-content/uploads/2014/09/MyPlayground_WithDocumentation_playground_after.png



Replace Magic Strings with Enumerations in Swift
Wed, 03 Sep 2014 01:55:54 +0000
“What can I do to avoid these ‘magic strings’ in my code?” – This was the question I asked myself recently as I found myself in prepareForSegue comparing segue.segueIdentifier to in-line hard-coded Strings.  This kind of in-line hard-coding of a String for comparison purposes is what I mean by “magic strings” in this article.  I knew this felt like a bad idea, but the solution to a cleaner option wasn’t readily apparent to me.
I used to do things like create static string constants, or #define expressions so that I could easily change these values if I ever needed to update them for some reason.  You know… back in a former Objective-C developer life when these tactics were available to me.  But these options don’t exist in Swift.  What to do??
Enumerations to the rescue!
Specifically, Enumerations with pre-populated default values (called raw values).
By creating an Enumeration that stores raw String values, I was able to encapsulate what would otherwise be “magic strings” in a type-safe construct for easier, cleaner use in my code.
The Gist
Consider this fabricated example:
I have a storyboard with one main View Controller that connects to three other View Controllers through three segues:  “otherScreenSegue1”, “otherScreenSegue2”, and “otherScreenSegue3” as defined in the utilities panel in Xcode.
An Enumeration encapsulating those segue identifiers might look something like this:
1enum SegueIdentifier: String {
2    case OtherScreenSegue1 = "otherScreenSegue1"
3    case OtherScreenSegue2 = "otherScreenSegue2"
4    case OtherScreenSegue3 = "otherScreenSegue3"
5}
With this Enumeration defined (perhaps in its own .swift file – wherever you deem would be strategic and findable again), the prepareForSegue override can become “magic string”-free:
 1override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
 2    switch segue.identifier {
 3    case SegueIdentifier.OtherScreenSegue1.toRaw():
 4        println("Going to other screen 1")
 5    case SegueIdentifier.OtherScreenSegue2.toRaw():
 6        println("Going to other screen 2")
 7    case SegueIdentifier.OtherScreenSegue3.toRaw():
 8        println("Going to other screen 3")
 9    default:
10        println("Going somewhere else")
11    }
12}
Alternatively, if you prefer to compare the enum values themselves, you could do the following (thank you to Brandon Knope for pointing this out – I think it looks even cleaner than my original code above!):
 1override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
 2    if let identifier = SegueIdentifier.fromRaw(segue.identifier) {
 3        switch identifier {
 4        case .OtherScreenSegue1:
 5            println("Going to other screen 1")
 6        case .OtherScreenSegue2:
 7            println("Going to other screen 2")
 8        case .OtherScreenSegue3:
 9            println("Going to other screen 3")
10        default:
11            println("Going somewhere else")
12        }
13    }
14}
This strategy of encapsulating my various segue identifiers in an Enumeration provides me a one-stop-shop for reviewing, and if need-be, updating the String values to match what I’ve set up in my storyboard.
The Details
I’ve chosen an Enumeration with Raw Values, because the other two kinds (Enumerations as Inherent Types, or Enumerations with Associated Values) don’t allow me to do String comparison, or don’t allow me to define a value at declaration-time, respectively.
Notice one critical aspect of the Enumeration:  because default raw values are defined, all of the raw values must be of the same Type, as explicitly specified in the declaration line:  enum SegueIdentifier: String // All of the enum cases must be Strings
The next important thing to understand is that in order to do actual comparisons with the raw value itself (see the switch statement in my code example above), I needed to call toRaw() on the Enumeration value being used (first code example), or call fromRaw() to convert the segue.identifier string to an Enumeration value (second code example):
1SegueIdentifier.OtherScreenSegue1 // Enum value of type SegueIdentifier
2SegueIdentifier.OtherScreenSegue1.toRaw() // String value, "otherScreen1Segue"
3SegueIdentifier.fromRaw("otherScreenSegue1")! // Unwrapped Enum value of type SegueIdentifier
Conclusion
In addition to segue identifiers, I’m considering using raw value Enumerations to wrap NSNotificationCenter keys as well.  Share if you find other nice uses of raw value Enumerations!
So far, this solution has provided me a nice, straight-forward, type-safe way to encapsulate groups of Strings where the urge to fall back to “magic strings” would otherwise be high.
 


Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
Wed, 27 Aug 2014 04:43:29 +0000
The delegation pattern is ubiquitous in iOS development – the pattern is a “core competency” for developing in Cocoa, and if you program with the iOS SDK for any length of time and you’ll end up writing some code that resembles someInstance.delegate = someDelegate.
One of the toughest things that I’ve experienced is choosing what someDelegate is.  All too often, a View Controller ends up being assigned the responsibility of being the delegate for everything in its hierarchy.  My question is:  Is there a cleaner way?
Let’s pick up on the example I proposed in my recent post about sending e-mails in-app.  For “quick and dirty” pragmatism, I just crammed everything into the View Controller with the promise of coming back and (hopefully) showing a cleaner way.  Here is a quick link to example posed before if you’d like to review it before proceeding.
What if…
What if we could make some adjustments so that the View Controller was trimmed down to the example on the right (click for larger view):

I’ve created a fully-working example on GitHub if you’d like to download it and play.
So the question at hand:  Is the class labeled “Clean Example” preferable (ie, better)?  First, let’s explore how I accomplished the “clean” View Controller.  Then I’ll tip my hand on and share what I like about this approach…
EmailComposer
In order to accomplish the self-declared Clean View Controller above, I placed all of the configuration processes and the delegate method for the MFMailComposeViewController in a new class called EmailComposer.  It should look familiar if you recall the previous example:
 1import Foundation
 2import MessageUI
 3
 4class EmailComposer: NSObject, MFMailComposeViewControllerDelegate {
 5    // Did this in order to mitigate needing to import MessageUI in my View Controller
 6    func canSendMail() -> Bool {
 7        return MFMailComposeViewController.canSendMail()
 8    }
 9    
10    func configuredMailComposeViewController() -> MFMailComposeViewController {
11        let mailComposerVC = MFMailComposeViewController()
12        mailComposerVC.mailComposeDelegate = self
13        
14        mailComposerVC.setToRecipients(["someone@somewhere.com"])
15        mailComposerVC.setSubject("Sending you an in-app e-mail...")
16        mailComposerVC.setMessageBody("Sending e-mail in-app is not so bad!", isHTML: false)
17        
18        return mailComposerVC
19    }
20    
21    // MARK: MFMailComposeViewControllerDelegate Method
22    func mailComposeController(controller: MFMailComposeViewController!, didFinishWithResult result: MFMailComposeResult, error: NSError!) {
23        controller.dismissViewControllerAnimated(true, completion: nil)
24    }
25}
So literally, the only thing I did is

Cut the function definitions for configuredMailComposeViewController, and the MFMailComposeViewControllerDelegate method.
Paste them into the new EmailComposer  class, which inherits from NSObject  (a requirement for this particular delegate protocol’s conformity), and conforms to the MFMailComposeViewControllerDelegate  protocol.
Adjust my View Controller to create an instance of EmailComposer , obtain a configured MFMailComposeViewController, and present it whenever the user taps on a button in my UI.

Conclusions

The View Controller in its final version is focused.  It’s primary concern is presentation and handling of user interaction with the View itself, rather than needing to worry with configuring an MFMailComposeViewController and its delegate callback.
EmailComposer is less of a hassle to test, in the sense that I no longer need to instantiate a View Controller in my XCTestCase class just to test my MFMailComposeViewController stuff.  It’s a real pain to test an actual View Controller instance, so I like that I can easily create an instance of EmailComposer and test away without the bulk.
No need to import MessageUI in my View Controller.

All in all, this is the cleanest, simplest, most balanced solution (that I could think of) to factoring out some logic to another class, so as to make my View Controller as clean as possible.
The goal was to make sure the appropriate responsibilities are assigned to the right classes.  Presentation logic is all in the View Controller.  Configuration and delegate callback implementation is done in EmailComposer.
I’m thinking through applying this same idea to other more complicated examples (UITableViewDataSource and UITableViewDelegate come to mind), and I think it would do us a lot of good to strategize on how to avoid making the View Controller the “catch-all” delegate / data source class for everything that’s currently on the screen_._
Hopefully these thoughts spark some ideas in the Swift community.  This post has already been revised slightly based on feedback that I’ve received from folks on Twitter.  If you have additional ideas in regards to choosing the right delegate, holler my way!  I’d love to hear from you.
Thanks for reading.

  
    You might also enjoy
  
  
    
      Clean Coding in Swift – Functions
    
    
      Clean Coding in Swift – Type Inference
    
    
      Expanded Thoughts on Swift’s Type Inference
    
    
      Send Email In-App – Using MFMailComposeViewController with Swift
    
    
      Send Text Message In-App – Using MFMessageComposeViewController with Swift
    
  



Send Email In-App – Using MFMailComposeViewController with Swift
Tue, 26 Aug 2014 03:48:30 +0000
Updated on October 11, 2016 – Swift 3.0
In this writing, I want explore how to use MFMailComposeViewController with Swift to send e-mails within your app as a walkthrough. My focus here is “quick and dirty” pragmatism, so that we can easily see what the inter-working components of MFMailComposeViewController are. That being said, here’s an important disclaimer – I’m going to overload the View Controller’s responsibilities in the examples to follow.
An op-ed with my thoughts and experimentation on how to keep the View Controller clean by factoring out some of the configuration and delegate methods to another class is now live as well.

Defining the requirements
As part of your app requirements, you need to be able to send an e-mail within your app without leaving it. Additionally, you need to pre-populate some standard e-mail fields such as “To”, “Subject”, and “Body”.
Not only is this possible, the API for accomplishing it is pretty straight forward.

Implementation overview
In order to implement the solution for this requirement, you need a few things:

A View Controller from which your user will initiate the display of the email composer screen, presumably by tapping on a button or something else that’s wired up to an `@IBAction`.
A configured `MFMailComposeViewController` to present.
An `MFMailCompseViewControllerDelegate` to handle dismissing the email composer screen.

Note that you may have trouble in the iOS 8 Simulator, with symptoms of the composer presenting itself and immediately dismissing. Running the app on an actual device running iOS 8 should work fine, as the problem seems to be isolated to the simulator, only.
An example View Controller class that implements the three steps above is proposed here. All that would be left for you to do is to design a user interface and wire up the @IBAction. Lines of code that are of special importance, such as module imports, protocol conformance and assignment, checking for the ability to send e-mail, and the protocol method implementation are highlighted. Take a look:
 1import Foundation
 2import UIKit
 3import MessageUI
 4
 5class ViewController: UIViewController, MFMailComposeViewControllerDelegate {
 6    
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9    }
10    
11    @IBAction func sendEmailButtonTapped(sender: AnyObject) {
12        let mailComposeViewController = configuredMailComposeViewController()
13        if MFMailComposeViewController.canSendMail() {
14            self.present(mailComposeViewController, animated: true, completion: nil)
15        } else {
16            self.showSendMailErrorAlert()
17        }
18    }
19    
20    func configuredMailComposeViewController() -> MFMailComposeViewController {
21        let mailComposerVC = MFMailComposeViewController()
22        mailComposerVC.mailComposeDelegate = self // Extremely important to set the --mailComposeDelegate-- property, NOT the --delegate-- property
23        
24        mailComposerVC.setToRecipients(["someone@somewhere.com"])
25        mailComposerVC.setSubject("Sending you an in-app e-mail...")
26        mailComposerVC.setMessageBody("Sending e-mail in-app is not so bad!", isHTML: false)
27        
28        return mailComposerVC
29    }
30    
31    func showSendMailErrorAlert() {
32        let sendMailErrorAlert = UIAlertView(title: "Could Not Send Email", message: "Your device could not send e-mail.  Please check e-mail configuration and try again.", delegate: self, cancelButtonTitle: "OK")
33        sendMailErrorAlert.show()
34    }
35    
36    // MARK: MFMailComposeViewControllerDelegate Method
37    func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
38        controller.dismiss(animated: true, completion: nil)
39    }
40}

Step-by-step implementation
With the above example in front of you, let’s explore what’s going on here in detail.

Setting up the View Controller
First of all, we need to import the MessageUI module.
Second, we need to specify that the View Controller will conform to the MFMailComposeViewControllerDelegate protocol. Later, we’ll actually implement the method that this protocol outlines, which will allow us to make the email composer screen go away once the user is finished either sending an e-mail or cancels out of sending one.

sendEmailButtonTapped()
This is the method that responds to the user tapping on a button. Assuming this is wired up to an appropriate element in the UI, it kicks off everything related to creating and showing the email composer screen. The logic is as follows:

Obtain a configured `MFMailComposeViewController` instance
Check to make sure the device can send e-mail at this moment

If it can, present the configured `MFMailComposeViewController`
Otherwise, show an alert with an error message




configuredMailComposeViewController()
I decided to encapsulate the configuration of an MFMailComposeViewController instance inside a function. I found that it made things a little more readable, perhaps more testable, and kept the spirit of decomposing sub-steps of a process into individual, single-responsibility functions.
One vital property to set is the mailComposeDelegate property (otherwise, you can never get rid of the e-mail composer screen after it’s presented). Now, there’s a “gotcha” here – MFMailComposeViewController instances also have a property named delegate . The delegate property is not the one to set (I did this at first and wondered why my implemented delegate “callback” method never got called). Set the mailComposeDelegate property to the instance of whatever you want to handle dismissing the email composer screen once the user is finished sending an e-mail or cancels. In the example, I set it to self, since the View Controller itself will implement the appropriate delegate method (Read my thoughts on cleaning this up a bit).
As you can see, setting up the “To”, “Subject”, and “Body” are simply a matter of setting properties of an MFMailComposeViewController instance. Notice that setToRecipients() accepts an array of e-mail address strings, so don’t forget to wrap that argument in an array, even for a single recipient. The same would work for Cc, and Bcc recipients, had I configured those.

showSendMailErrorAlert()
This method shows a simple UIAlertView if the user’s device cannot send an e-mail at the moment.

MFMailComposeViewController’s delegate method
The implementation of this delegate method simply dismisses the email composer screen.


  
    You might also enjoy…
  
  
    
       Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
    
       Send Text Message In-App – Using MFMessageComposeViewController with Swift
    
  




Expanded Thoughts on Swift’s Type Inference
Thu, 21 Aug 2014 02:19:45 +0000
In my recent op-ed on clean coding in Swift focused on Type Inference, I began by saying,
Quick!  Tell me!  What is the Type of the birdDetails constant in this code example:
let birdDetails = birdDetailsFromStorage()
With no additional context to glean information from, the correct answer to the question is, “I have absolutely no clue…”
But is that concluding assertion true?  Hmm…
I’m learning, and as I’ve weighed a recent Twitter conversation and thought on a comment thread that Rob Napier made on the post quoted above, I’m compelled to expand a little on my first post on Type Inference as it relates to clean code in Swift.
Something struck me as I read Rob’s comment:  Why wouldn’t I know the Type that would be inferred from what is returned by birdDetailsFromStorage() and assigned to birdDetails?  Presumably, I named the function what I named it intentionally.  The part I missed, was that if I had designed well and created a Type called BirdDetails (say, a Struct as Rob proposed), then all of a sudden, an inference can be made by both the compiler and a human that the birdDetails constant is… well… an instance of BirdDetails.  Imagine that!
To quote Rob (emphasis added):

Type inference should only be used when the result is unambiguous, but the best solution is to make the result unambiguous.

Bingo.  The best solution is to make the result unambiguous.  You and I as code authors are in charge of the clarity or ambiguity of our code – it’s up to us to make the results of our function evaluations unambiguous.
When I named the function birdDetailsFromStorage(), I heavily implied something about its return Type in the name.  I even implied it in the name of the constant.  I was expecting the return Type to be something that encapsulated whatever “bird details” are – I just didn’t realize it at the time (although it’s super obvious now)!
The very name of a thing sets expectations for you and the readers of your code.  It’s our job to set ourselves up for that expectation to be fulfilled!  Be predictable with the return Type of your functions for your own sake.  A function signature should be such that when you run across birdDetailsFromStorage()in some piece of code, you are able to legitimately expect it to return a BirdDetails.  
Using this predictable, convention-based approach to give humans the right clues about what the compiler is going to compute a Type to be makes Type Inference a totally legitimate language feature to embrace for the sake of your code’s clarity and simplicity.
I’ll leave you with a final quote from Rob’s comments:

Don’t go implying that you’re returning one thing when you’re returning another. If you must, then yes, explicit types are your punishment. 😀

Thank you Rob for your insight and feedback.  You can read more of Rob’s work at http://robnapier.net.

  
    You might also enjoy
  
  
    
      Clean Coding in Swift – Functions
    
    
      Clean Coding in Swift – Type Inference
    
    
      Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
  



Sort It Out – Sorting an Array in Swift
Sat, 16 Aug 2014 18:06:26 +0000
I had a question come to me today regarding sorting an array of integers that are actually encoded as strings in the array.  Data comes to is in a variety of encodings/types, so it’s quite common to need to adjust things to the right state for working with.  Let’s take a look at how to solve this one.
The Dilemma
Given an array like this…
1let arrayOfIntsAsStrings = ["103", "2", "1", "50", "55", "98"]
… the question arises:  “How do I sort this in numerical order so that my output array is still an array of strings, but sorted like this ["1&#8221;, "2&#8221;, "50&#8221;, "55&#8221;, "98&#8221;, "103&#8221;, "1000&#8221;] (integer comparison), not this ["1&#8221;, "1000&#8221;, "103&#8221;, "2&#8221;, "50&#8221;, "55&#8221;, "98&#8221;]  (string comparison)?” Enter Swift’s sorted function:

“Swift’s standard library provides a function called sorted, which sorts an array of values of a known type, based on the output of a sorting closure that you provide. Once it completes the sorting process, the sorted function returns a new array of the same type and size as the old one, with its elements in the correct sorted order. The original array is not modified by the sorted function.” Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l

This is exactly what we need to do the job here.
The Gist
Given the original array outlined above, we can create a new_ sorted_ array like this:
1let sortedArray = sorted(arrayOfIntsAsStrings, {
2    (str1: String, str2: String) -> Bool in
3    return str1.toInt() < str2.toInt()
4})
This code produces our desired output:  ["1&#8221;, "2&#8221;, "50&#8221;, "55&#8221;, "98&#8221;, "103&#8221;, "1000&#8221;]
The Details
Swift’s sorted function takes two arguments:  an Array, and a Closure.  The part that may be confusing is the closure argument.  Isolated it looks like this:
1{
2    (str1: String, str2: String) -> Bool in
3    return str1.toInt() < str2.toInt()
4}
Swift provides several shorthand forms of the closure syntax, but I’ve chosen the longest-form here just for full exposure and clarity.  The closure I’ve written simply needs to compute a Bool value representing the result of a comparison between two values – in this case, I’m wanting to do integer comparison, so I write this:  str1.toInt() and str2.toInt().
You can choose whatever parameter names you’d like, and you can actually rely on Type Inference in the parameter section — the compiler can work out what Types your parameters are.  But if it helps clue you in to what the code is doing, you can specify the Types in the closure’s parameter section, as I wrote about recently, and as I did in my example when I wrote str1: String, str2: String (I could have left off the : String).
Within the closure’s body, you can put in as many lines of logic as are necessary in order to produce an appropriate comparison result to get your Array in the right order.  If it gets too complicated to do it in-line, think about encapsulating that logic inside one or more functions in the spirit of writing clean code.
To produce an appropriate comparison result, you’ll have to consider the Types of the data you’re working with within the closure and consider any casting or manipulation you’ll need to do to produce the correct result like we did in our example. Other than that, it’s pretty straightforward to sort it out!


Clean Coding in Swift – Type Inference
Wed, 13 Aug 2014 04:22:25 +0000
Quick!  Tell me!  What is the Type of the birdDetailsconstant in this code example:
1let birdDetails = birdDetailsFromStorage()
With no additional context to glean information from, the correct answer to the question is, “I have absolutely no clue…”  Or is it?
“Not fair!”, you say.  “In the real world, I’d have the ability to option-click and learn the type from a pop-up tooltip, or learn this information by inspection from Xcode’s utilities panel.”
Truth.  We would.  But… should we have to for an example like the one above?  Could we have helped ourselves out a bit by being explicit about the type of birdDetails?
This was the question I asked myself as I set out to determine how and when I prefer to explicitly specify the Types of my variables and constants at declaration-time, rather than letting the compiler infer the Type for me.
Type Inference is powerful and convenient.  It enables us to leave off explicit type specifications when we declare a variable or constant, leaving us with nice, terse, clean-looking code.  But in reality, for examples like the one posed above, is clean-looking truly “clean code”?
From Apple’s documentation:

Type inference enables a compiler to deduce the type of a particular expression automatically when it compiles your code, simply by examining the values you provide.

The key phrase that stuck out to me was this:  “Type inference enables a compiler to deduce the type of a particular expression…”.  Humans are not compilers!
I don’t know about you, but I could use all the help I can get when it comes to figuring out simple things like the Type resulting from an expression.  Sure, I could rely on the IDE, but in debugging, or in trying to simply read and understand what the intention of my code is when I come back to it sometime later, I want to focus on the code, not on pop-up tool tips or inspector panels.
For instances where deducing the type is not simple for a human to do (and I mean really simple), I’m getting to where I prefer to specify the Type up-front.  We’re used to doing this in Objective-C, and I even do it in C# when using var would obscure things.  When a language gives me the option to be clear about Types, I try to take advantage of that valuable language feature for all but the simplest of situations.
The Simplest of Situations
Let’s think for a moment about this so-called “simplest of situations”.  I would define such a situation to be when the Type resulting from an expression can easily, at a glance, be inferred by a human being without assistance from an IDE.  It’s all about context here, and for these simplest of situations, I love Type Inference.
Compare the following two lines of code:
1let birdDetails = "Swift"
and
1let birdDetails: String = "Swift"
In the example just presented, typing “: String ” to explicitly specify birdDetails‘ type is superfluous in my opinion (and I prefer not to be repetitively redundant when I can).  It’s crystal clear that birdDetails in this example is a String.
However, in situations like the one at the beginning of the article where, by simply looking, I would have to answer, “I have no clue what the Type of this is”, my preference / proposal for your consideration would be to go ahead and specify the Type at declaration time.  Consider:
1let birdDetails: (genusSpecies: String, commonName: String) = birdDetailsFromStorage()
2
3
4//... somewhere else in a Swift file far, far away ...
5
6
7func birdDetailsFromStorage() -> (genusSpecies: String, commonName: String) {
8    return ("Apus apus", "Swift")
9}
When I’m writing this the first time, I can spend the time looking up the function’s return Type and specify it when I declare my constant.  It will make my life so much easier down the road.
Don’t stumble over the fact that birdDetails is a tuple type (String, String).  The point is that the function could have returned anything, and it would still have been impossible for me to tell you what the Type of the constant was just by looking, had I not specified it upon its declaration.
Being explicit about the type in the declaration has great potential to immediately help us get our bearings around a particular set of code when we return to it after any length of time.  And it seems to me that one of the principal goals of writing clean code is to help ourselves and our teams make sense of code quicker so that everyone’s happier and more productive.
Whew.  That was a long-winded exploration of some things to think about when relying on (or avoiding) Type Inference in your own code.  Thanks for reading!

Since publishing this op-ed, I’ve expanded my thoughts on Type Inference as it relates to clean coding practices in Swift.  I highly recommend that this post be read and considered alongside my latest musings,which were heavily influenced by Rob Napier’s comments below.

  
    You might also enjoy
  
  
    
      Clean Coding in Swift – Functions
    
    
      Expanded Thoughts on Swift's Type Inference
    
    
      Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
  



Clean Coding in Swift – Functions
Thu, 07 Aug 2014 18:16:23 +0000
I’ve been thinking a lot about how the principles of clean coding (Bob Martin’s “Clean Code”) apply in Swift. How do I express clean code in this language? Conversely, how do I avoid writing cryptic code in Swift? What language features help me write clear and self-explanatory code and what language features present the potential for tempting me to write obscure code in Swift?
I am beginning a commentary series that I hope will encourage clean coding practice in myself and in the Swift developer community. Dialog on these topics is welcomed – I have not “arrived”, so please – help me help the Swift community for the better!
The first in the series is on writing clean functions in Swift. As it turns out, Swift provides some really great mechanisms for defining self-explanatory, clear-purposed functions. We’ll start by analyzing the features around naming functions and their parameters, and will conclude on thinking through function decomposition.
Function Names
Something that I really enjoyed about Objective-C was that while method names were often long and verbose, they were extremely descriptive. My code often read like a narrative, and I enjoyed that. Some may have hated it, but I found it extremely helpful in facilitating my recollection of a method’s intended purpose and the expectations around its argument requirements.
I do my best to think hard about the names that I give my functions, ascribing to them a name that is specific, targeted, and focused on the single “thing” that each one does. Nothing in Swift mandates that we leave the verbosity of Objective-C naming conventions behind. In fact, the exact opposite is true!  One example is that swift intentionally provides us with the ability to add external parameter names so that we can be as descriptive as we need to be about the names of our functions.
Parameter Names
Swift’s external parameter names, in my opinion, are wonderful for helping write self-documenting code. They simply help guide my mind back to what a given function does and needs in order to do its job. Anything to help me get back in the zone is worth spending a few extra keystrokes on, especially since Xcode’s auto-completion assists me so well when calling functions with long signatures.
Apple recommends the following:

Consider using external parameter names whenever the purpose of a function’s arguments would be unclear to someone reading your code for the first time.

I would only add that sometimes, that someone “reading your code for the first time” is you. Not technically, of course, but think about this: Write some code, leave it, and come back to it some time later. Will it make sense? Will you immediately go, “Ah, I know what I meant there”, or will you do like I’ve often done and say, “WHAT in the WORLD was I THINKING??!?”.
Spending a few seconds on typing a few more words to save brain power and potentially more seconds/minutes some time later is a worthy investment. And if you work on a team, your teammates will appreciate the extra care you put in to providing as many hints as possible through inventing good names. Good naming includes parameter names. Why not take advantage of the fact that Swift provides you this opportunity to write self-documenting code?
Function Decomposition

In order to make sure our functions are doing “one thing”, we need to make sure that the statements within our function are all at the same level of abstraction. -Bob Martin, Clean Code pg. 36

This is just general advice without respect to a specific language. A couple of things to think about:

 Watch out for key words like “and” / “or” in your function names. These red-flag words often indicate that your function is doing more than one thing and can be further decomposed. Consider:

1func washAndDryCar() {
2    // Logic to wash and dry a car
3}
A preferred decomposition could look something like this:
1func washCar() {
2    // Logic to wash a car
3}
4
5func dryCar() {
6    // Logic to dry a car
7}

 Doing one thing can still involve multiple steps. But if each step takes a few steps of its own, that group of steps can be extracted out into another function. Consider:

1func washCar() {
2    // Pre-rinse code (example implementation - 4 lines)
3    // Soap code (example implementation - 5 lines)
4    // Rinse code (exmple implementation - 4 lines)
5}
A preferred decomposition might look something like this:
1func washCar() {
2    rinse(durationInSeconds: 25.0)
3    soapCar()
4    rinse(durationInSeconds: 60.0)
5}
What’s neat about the final result of the decomposition is that not only is my washCar function shorter and more readable (from 13 lines to 3 lines), but I got code re-use by making the rinse< function take a duration argument.
Hopefully these thoughts spark a few ideas in you.  Constructive feedback is welcome!  How are you thinking about writing clean code in Swift?

  
    You might also enjoy
  
  
    
      Clean Coding in Swift Type Inference
    
    
      Expanded Thoughts on Swift's Type Inference
    
    
      Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
  



Fade In / Out Animations as Class Extensions in Swift
Sun, 27 Jul 2014 20:13:53 +0000
Updated on December 6, 2016 – Xcode 8 & Swift 3.0
The question has been asked (and solved) on StackOverflow in Objective-C, but my aim in this post is to take the Objective-C implementation and leverage Swift extensions to make this job even easier to achieve and reuse.
Fade animations basically involve adjusting a UIView‘s alpha value from 1.0 to 0.0 (fade out) or 0.0 to 1.0 (fade in) over a specified duration using some kind of easing option (like starting fast, then slowing down at the end of the animation, or starting slow and speeding up at the end of the animation).
I’ve published an example Xcode project to GitHub with the final working version of the code below if you’d like to just see it. Read on for the full explanation.
Edit: 2/23/2016 – A new idea flowing out of my Pluralsight Course involves a similar implementation, but using protocol extensions instead. This article’s implementation still works though, so feel free to check out either the contents of this blog entry, or the new one!

  
    New article using protocol extensions
  
  
    
       Fade Views In/Out with Fadeable – A Swift Protocol Extension
    
  


Fade without an extension
Below is an example of how my view controller may look if I want to click a button and have it fade out a label, set the text, and fade it back in again:
 1class ViewController: UIViewController {
 2    @IBOutlet weak var birdTypeLabel: UILabel!
 3    
 4    override func viewDidLoad() {
 5        super.viewDidLoad()
 6        // Do any additional setup that your app requires
 7    }
 8    
 9    @IBAction func updateBirdTypeLabel(_ sender: UIButton) {
10        // Fade out to set the text
11        UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseOut, animations: {
12            self.birdTypeLabel.alpha = 0.0
13            }, completion: {
14                (finished: Bool) -> Void in
15                
16                //Once the label is completely invisible, set the text and fade it back in
17                self.birdTypeLabel.text = "Bird Type: Swift"
18                
19                // Fade in
20                UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseIn, animations: {
21                    self.birdTypeLabel.alpha = 1.0
22                    }, completion: nil)
23        })
24    }
25}
What I don’t like about this implementation is that if I want to perform this same kind of animation again elsewhere in my app, I’ve got to write the bulk of that algorithm again each time I want to fade something in or out. I’d like it to be in one place for easier maintainability. I’d also like to be able to fade in / out simply by doing something like self.birdTypeLabel.fadeIn() or self.birdTypeLabel.fadeOut() optionally setting parameters for duration, delay, and completion. With these goals in mind, let’s see what Swift extensions provide us in terms of simplifying the process.

Refactoring using Swift extensions

Step 1 – Create UIViewExtensions.swift
Create a new Swift file and name it something like UIViewExtensions.swift

Step 2 – Move fadeOut and fadeIn to UIViewExtensions.swift
Use the previously-written fadeOut() and `fadeIn() algorithms in the new UIViewExtensions.swift file.
We can leverage what we wrote before with a few modifications. Take a look (I’ve written some comments to help identify some of the tweaks for the extension version):
 1import Foundation
 2import UIKit
 3
 4extension UIView {
 5    func fadeIn() {
 6        // Move our fade out code from earlier
 7        UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseIn, animations: {
 8            self.alpha = 1.0 // Instead of a specific instance of, say, birdTypeLabel, we simply set [thisInstance] (ie, self)'s alpha
 9            }, completion: nil)
10    }
11    
12    func fadeOut() {
13        UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseOut, animations: {
14            self.alpha = 0.0
15            }, completion: nil)
16    }
17}
With this extension in place, we can now call self.birdTypeLabel.fadeIn() or self.birdTypeLabel.fadeOut() . To gain a little more control (if I so choose), I can outfit the fadeIn and fadeOut extension functions with parameters with default values defined so that I can call them with or without parameters as I need.

Step 3 – Provide parameters with default values
In Step 2, we simply hard-coded values for duration, delay, and completion. Below is the final version of the extension that provides parameters for you to (optionally) pass arguments to.
 1import Foundation
 2import UIKit
 3
 4extension UIView {
 5    func fadeIn(_ duration: TimeInterval = 1.0, delay: TimeInterval = 0.0, completion: @escaping ((Bool) -> Void) = {(finished: Bool) -> Void in}) {
 6        UIView.animate(withDuration: duration, delay: delay, options: UIViewAnimationOptions.curveEaseIn, animations: {
 7            self.alpha = 1.0
 8            }, completion: completion)  }
 9    
10    func fadeOut(_ duration: TimeInterval = 1.0, delay: TimeInterval = 0.0, completion: @escaping (Bool) -> Void = {(finished: Bool) -> Void in}) {
11        UIView.animate(withDuration: duration, delay: delay, options: UIViewAnimationOptions.curveEaseIn, animations: {
12            self.alpha = 0.0
13            }, completion: completion)
14    }
15}
With this now in place, the final version of my view controller becomes much simpler and clean:
 1import UIKit
 2
 3class ViewController: UIViewController {
 4    @IBOutlet weak var birdTypeLabel: UILabel!
 5                        
 6    override func viewDidLoad() {
 7        super.viewDidLoad()
 8        // Do any additional setup that your app requires
 9    }
10    
11    @IBAction func updateBirdTypeLabel(_ sender: UIButton) {
12        self.birdTypeLabel.fadeOut(completion: {
13            (finished: Bool) -> Void in
14            self.birdTypeLabel.text = "Bird Type: Swift"
15            self.birdTypeLabel.fadeIn()
16            })
17    }
18}
By employing Swift extensions to encapsulate the fade in / out animation logic, I was able to

Define the animation logic in one place for easy maintainability
Make my view controller’s code simpler and clean
Provide a more natural way to perform the animation on any UIView instance by simply calling fadeIn() or fadeOut()
Give myself the option to specify a different duration, delay, or completion closure if I need extra control



  
    You might also enjoy…
  
  
    
       Fade Views In/Out with Fadeable – A Swift Protocol Extension
    
    
       The 5 W’s of Swift Extensions
    
    
       Slide In Animation in Swift
    
    
       Rotate Animation in Swift
    
  




Swift Optionals?  Don’t Forget to Unwrap!
Sat, 26 Jul 2014 02:23:53 +0000
There is a compiler error that throws me off every time I see it.  It takes the form,

‘ClassName?’ does not have a member named ‘memberName'

This can happen when you’ve declared a variable as an optional, but forget to unwrap that optional when you attempt to call a method on it.
For example, given this class definition:
 1class Bird {
 2	var family: String
 3	var color: String
 4 
 5	init(family: String, color: String) {
 6		self.family = family
 7		self.color = color
 8	}
 9 
10	func isSwift() -> Bool {
11		return self.family == "Apodidae" ? true : false
12	}
13}
If, say in a ViewController, I declare a variable that I intend to reference an optional Bird instance like this:
1var birdInstance: Bird?
And then I later initialize this variable with a Bird instance, perhaps in viewDidLoad() :
1birdInstance = Bird(family: "Apodidae", color: "Black")
If I attempt to invoke the isSwift method on the birdInstance later  on, I’ll get a compiler error:
1println(birdInstance.isSwift())

error: ‘Bird?’ does not have a member named ‘isSwift'

This may seem pretty basic — after all, I declared the birdInstance as an optional and I know optionals need special treatment.  How could I make this mistake??  Perhaps this is just a consequence of my current stage in life, trying to code in 15-30 minute spurts with my 1 1/2 year old running around, haha.
We all deal with this though:  it’s fairly easy to write some code and come back to it later and not remember how you declared your variable in an earlier coding session.  Then when you’re presented a message saying that your class doesn’t have a member named “___”, you immediately go to the class definition and see the function there, plain as day.  It’s easy to spend 3-5 minutes scratching your head thinking, “What in the world??!” … And then you realize – it’s that optional declaration that you forgot to handle.
To fix this, of course, you can do any number of things, depending on your situation.
Force unwrap the optional and invoke the method:
1birdInstance!.isSwift() // Force unwrapped -- **CAUTION** make sure that birdInstance gets instantiated before you do this,&nbsp;or you'll get a runtime error
Employ optional chaining and invoke the method:
1birdInstance?.isSwift()
Declare the variable as implicitly unwrapped optional, then invoke the method later without extra exclamation or question marks:
1var birdInstance: Bird! // Implicitly unwrapped -- **CAUTION** make sure that birdInstance gets instantiated before you use it, or you'll get a runtime error
2birdInstance = Bird(family: "Apodidae", color: "Black")
3
4// Some time later, invoke isSwift
5
6println(birdInstance.isSwift())
A blog post by Peter Witham over at CompileSwift was the article that caused me to think, “OH!  I haven’t done anything with my optional…that’s the problem”.  Credit to you, sir, for your post!


Swift Access Control – Implications for Unit Testing
Wed, 23 Jul 2014 04:04:43 +0000
If you find yourself with broken unit tests, failing to build with the error, “Use of unresolved identifier…”, you’re not alone!
Unit Tests and Swift Access Control
When Swift access control came into the picture, we suddenly had a little more to consider. From the Apple docs:
Swift access control has three access levels:

private entities can only be accessed from within the source file where they are defined.
internal entities can be accessed anywhere within the target where they are defined.
public entities can be accessed from anywhere within the target and from any other context

that imports the current target’s module.

By default, most entities in a source file have internal access.

So given the following…

Out of the box, your unit tests are part of a separate test target
The default access control for a class is internal, (meaning that if you do not explicitly specify an access control on the class / properties / functions, they’re marked internal behind the scenes)

… we now know why the unit tests break, unless we make a few tweaks:  classes marked internal are only seen within a set of specified targets and our unit tests are in a separate target that our class is not a part of by default.
Options
It seems to me that we have two options:

Change the access control on our class to public.  Additionally, mark any methods we intend to test with public also.
Add the class(es) you want to be able to write unit tests for to the tests target.

Solution
I found option #2 to be the easiest to implement at first. However, it turns out that this can lead to some really obscure issues. An enlightening Twitter conversation also shed some light on the subject, and pointed to the solution of testing only publicly accessible behavior that your Types expose, rather than trying to test internal implementation. That probably deserves a blog entry of its own, but for now, I’ll leave it to say that I’d recommend not adding your .swift source files to your test target, but rather to adjust the access control modifiers of the things you want to test to public (ie, Option # 1).

  You might also enjoy 
  
    
      Don't Write Legacy Swift
    
    
      Getting Started with Unit Testing in Swift
    
    
      Swift Unit Testing Resources
    
    
      TDD for iOS in Swift – What’s the Goal?
    
  



Implement NSManagedObject Subclass in Swift
Fri, 18 Jul 2014 04:08:12 +0000
Updated on July 8, 2016 – Xcode 7
My goal with this blog entry is to help get you set up to create NSManagedObject subclasses in Swift for the Entities in your Core Data model.

Example
Let’s look at a fabricated example: Say that you’ve got a Core Data project and you’re creating Entities.  For my simple project, I’ll create an Entity called “MyEntity” with an attribute called “myAttribute”.
After you create an NSManagedObject subclass for the Entity and come back to the data model screen to specify the “Class” in the inspector area, you must prefix the name of the class with “YourProjectName.” (don’t forget the dot).  Forgetting to do this will lead to run-time errors when you start interacting with instances of your NSManagedObject subclass.
Apple specifies this in their documentation page, but it was a subtle mention at the end of the document and I just happened upon it as I was troubleshooting this:

Swift classes are namespaced—they’re scoped to the module (typically, the project) they are compiled in. To use a Swift subclass of the NSManagedObject class with your Core Data model, prefix the class name in the Class field in the model entity inspector with the name of your module.


Walk-through

Create an Entity
In your .xcdatamodeld file, create an Entity to your liking.  In my example, I named the Entity “MyEntity” and I gave it an attribute called “myAttribute” with a data type of String.



Create an NSManagedObject Subclass for that Entity
On the Menu, click Editor, then “Create NSManagedObject Subclass…”


Make sure you choose “Swift” as your language of choice as you click Next through the wizard and Xcode will generate you a file that is appropriate for your Entity.  The files it created for me (Xcode 7.1.1) look like this:



Verify NSManagedObject class in the “Data Model Inspector”
Make sure that you have your .xcdatamodeld file selected in the Navigator panel.  Then make sure your Utilities panel is visible.
Click the “Data Model Inspector” icon.  This will be the last icon in the inspector of Xcode.  You should see a section for “Entity” and within this section, two textboxes:  one for Name and one for Class. You should also see a drop-down for the Module that the NSManagedObject subclass is found in.
You’ll be verifying the Class and the Module values:

According to the Swift documentation, Swift class namespaces are scoped to the module they’re compiled in (usually the project you’re working in).  
To use the NSManagedObject subclass in your project, you just need to verify that the Module setting is set to “Current Product Module”, assuming that the NSManagedObject subclass you’re wiring this Entity to is found in that module. If it’s in another module, you’ll need to adjust the Module value in the inspector appropriately.
Once the Class and Module values are verified (or set), you’ll be able to use this NSManagedObject subclass anywhere in your project.


  
    You might also enjoy…
  
  
    
       Core Data Cheat Sheet for Swift iOS Developers
    

    
       Using Swift to Seed a Core Data Database
    

    
       Displaying Data With NSFetchedResultsController and Swift
    

    
       Sync Table View Data: NSFetchedResultsController and Swift
    

  




  
    Resources
  
  
    
       Core Data Fundamentals with Swift
 
    
  




How to Create Mocks and Stubs in Swift
Tue, 15 Jul 2014 05:12:16 +0000
Without 100% support for a mocking framework like OCMock, I found myself needing to get creative when building mock objects and method stubs in Swift unit tests.  The great thing about testing is that you’re…well… testing things out to see if they’ll work, and I found a solution that I’m pretty happy with for now.  I’m open to better ways, so leave a comment if you’ve had good results using a different design!
The process is essentially this (example to follow):

Ensure that the class that you would like to test is designed so that you can substitute your mock for the real one that’s used in your class’ implementation
Create an XCTestCase  class with a test function in your unit test project
Within the function body create a nested class
Make the nested class inherit from the real object you’re trying to mock / create a method stub for
You can give the nested class a name such as Mock[ObjectName]
Configure the mock object however you need by setting its properties or overriding its function implementations with stubbed implementations – no need to override every function… only the one(s) that your class calls during the test at hand
Instantiate the class you’re testing and pass in an instance of the mock object you just nested in the test function to your class somehow (either through its initializer, by setting a property on the class, or by passing it into the method under test via parameter — however you intended to ‘inject’ the mock from step 1 is what you should do)
XCTAssert…

Let’s see those 8 steps in action for those of us who are more visually inclined.
EDIT:  July 22, 2014 – I’ve added a simple Xcode Project to GitHub for those interested in seeing the setup directly in Xcode at  https://github.com/andrewcbancroft/MocksAndStubs
The scenario that I’d like to use a mock class in is this:  I have a CoreData application and I’d like to be able to mock the NSManagedObjectContext  so that instead of making actual database fetch requests, I can just provide stubs of various sorts with the kinds of responses I’d expect from the real database calls to ensure my class will do the right thing based on predictable results.  To do this I begin at step 1…
1.  Ensure that the class that you would like to test is designed so that you can substitute your mock for the real one that’s used in your class’ implementation
In the example class below, I intend to provide the NSManagedObjectContext  dependency through the class’ initializer which will set a property that is used by my class’ methods later on, but you could easily use some other way of performing “dependency injection”.  The initializer strategy just makes it super clear in my mind what the class’ dependencies are, so that’s what I’m going to do here.  Have a look:
 1import Foundation
 2import CoreData
 3
 4class MyClass {
 5    let context: NSManagedObjectContext
 6    
 7    init(managedObjectContext: NSManagedObjectContext) {
 8        self.context = managedObjectContext
 9    }
10}
Now, let’s say that my example class has a member function called databaseHasRecordsForSomeEntity  that returns a Bool  value of true if the resulting array of a fetch request contains objects, and a Bool  value of false if the result array of a fetch request is empty.  The completed class looks like this:
 1import Foundation
 2import CoreData
 3
 4class MyClass {
 5    let context: NSManagedObjectContext
 6    
 7    init(managedObjectContext: NSManagedObjectContext) {
 8        self.context = managedObjectContext
 9    }
10    
11    // If the array returned from executing a fetch request contains objects, return true; if empty, return false
12    func databaseHasRecordsForSomeEntity() -> Bool {
13        let fetchRequest = NSFetchRequest(entityName: "SomeEntity")
14        let fetchRequestResults = self.context.executeFetchRequest(fetchRequest, error: nil) // May want to do something with the error in real life...
15        return (fetchRequestResults?.count > 0)
16    }
17}
I want to test if databaseHasRecordsForSomeEntity  does what I intend it to do. So…
2.  Create an XCTestCase  class with a test function in your unit test project
Just listing this for completeness
Next comes the way to make the mock.  Read steps 3-5 and then look below for a code example of what the skeleton will look like.
3.  Within the function body create a nested class
4.  Make the nested class inherit from the real object you’re trying to mock / create a method stub for
5.  You can give the nested class a name such as Mock[ObjectName]
 1import UIKit
 2import XCTest
 3import CoreData // <-- Make sure to import CoreData or you will get errors when you try to use NSManagedObjectContext
 4
 5class MyClassTests: XCTestCase {
 6
 7    override func setUp() {
 8        super.setUp()
 9        // Put setup code here. This method is called before the invocation of each test method in the class.
10    }
11    
12    override func tearDown() {
13        // Put teardown code here. This method is called after the invocation of each test method in the class.
14        super.tearDown()
15    }
16
17    // Yay for verbose test names!  :]
18    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
19        class MockNSManagedObjectContext: NSManagedObjectContext {
20            
21        }
22    }
23}
 6.  Configure the mock object however you need by setting its properties or overriding its function implementations with stubbed implementations – no need to override every function… only the one(s) that your class calls during the test at hand
For my example, I’m going to stub out the executeFetchRequest  method so that it returns an array with one object in it.  This is really the part where you have to determine what you’re testing and what you expect the stubbed results to be.  Whatever you decide, the way to stub a method is simply to override it in the mock you’re implementing.  Here’s how I implemented the executeFetchRequest  stub for my example:
1// Yay for verbose test names!  :]
2    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
3        class MockNSManagedObjectContext: NSManagedObjectContext {
4            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
5                return ["object 1"]
6            }
7        }
8    }
We’re ready to perform the test and assert the results.  Read steps 7-8 and take a look at the code example below step 8:
7.  Instantiate the class you’re testing and pass in an instance of the mock object you just nested in the test function to your class somehow (either through its initializer, by setting a property on the class, or by passing it into the method under test via parameter — however you intended to ‘inject’ the mock from step 1 is what you should do)
8.  XCTAssert…
From step 1, I intended to pass an NSManagedObjectContext instance to the initializer of MyClass, so that’s what I’ll do in my test.  I’ll then perform the XCTAssert on the return value of my method under test:
 
 1// Yay for verbose test names!  :]
 2    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
 3        class MockNSManagedObjectContext: NSManagedObjectContext {
 4            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
 5                return ["object 1"]
 6            }
 7        }
 8        
 9        // Instantiate mock
10        let mockContext = MockNSManagedObjectContext()
11        
12        // Instantiate class under test and pass it the mockContext object
13        let myClassInstance = MyClass(managedObjectContext: mockContext)
14        
15        // Call the method under test and store its return value for XCTAssert
16        let returnValue = myClassInstance.databaseHasRecordsForSomeEntity()
17        
18        XCTAssertTrue(returnValue == true, "The return value should be been true")
19    }
Running the tests at this point should produce a passing test using the mock object in place of a real NSManagedObjectContext that calls a database!
Now, if I wanted to test the “false” branch of my class’ method, I could simply create another test method following the same steps, only this time, I’d provide a new implementation for the overridden executeFetchRequest  method that’s appropriate:
 1func testDatabaseHasRecordsForSomeEntityReturnsFalseWhenFetchRequestReturnsEMPTYArray() {
 2        class MockNSManagedObjectContext: NSManagedObjectContext {
 3            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
 4                return [] // Provided a different stub implementation to test the "false" branch of my method under test
 5            }
 6        }
 7        
 8        // Instantiate mock
 9        let mockContext = MockNSManagedObjectContext()
10        
11        // Instantiate class under test
12        let myClassInstance = MyClass(managedObjectContext: mockContext)
13        
14        // Call the method under test and store its return value for XCTAssert
15        let returnValue = myClassInstance.databaseHasRecordsForSomeEntity()
16        
17        XCTAssertTrue(returnValue == false, "The return value should be been false")
18    }
And that’s a wrap – happy mocking and stubbing in Swift!
EDIT:  July 22, 2014 – I’ve added a simple Xcode Project to GitHub for those interested in seeing the setup directly in Xcode at  https://github.com/andrewcbancroft/MocksAndStubs

  You might also enjoy 
  
    
      Don't Write Legacy Swift
    
    
      Swift Access Control – Implications for Unit Testing