Notice that Swift almost seems to frown on making a copy of a reference type, i.e., a copy of an instance of a class, or, as some would rather put it, getting a copy of an object. I’m not talking about getting another reference to a class, I’m talking about getting an entire, separate copy of a class instance. This frowning on class copying is not an accident. Swift’s language architects want the syntax and semantics of the language to be crystal clear. They want developers to be confident that reference types and value types will both have 1) distinct and obvious meanings and that both types will 2) behave consistently. But still, why not be able to safely make a copy of a class instance? I’ll show you how in this tutorial by borrowing the copy constructor concept from C++. In Swift, we’d call this a “copy initializer.” (NOTE: Yeah, yeah, yeah, I know about NSCopying in Cocoa and Objective-C.)
How many of you have written iOS apps that work with files? I’m talking about developing apps that read, write, create, copy, move, and delete files in the app’s sandboxed file system. I’m not talking about reading an image from your app bundle so you can display it on screen, like so:
Image file from bundle
I’m talking about apps like Adobe Photoshop Express which is only useful if it can edit image files; Apple’s Pages and Numbers apps which are only useful if they can edit word processor and spreadsheet/chart files, respectively; and, Microsoft Word which is only useful if it can edit word processor documents. Yes, you can solely work from/in the cloud with all these apps, but you can also opt to store files locally on your devices. What if you open an email attachment or download a file from Safari? I guarantee you that many apps with associations to certain file extensions store those attachments or downloads locally first for editing and display, and only later sync files with iCloud or Dropbox.
We’re going to talk in-depth about protocol-oriented programming (POP) using Swift 4 in this article. This post is the second and final article in a two part series. If you haven’t read the first, introductory article, please do so before continuing onwards. Today, we’ll: discuss why Swift is considered a “protocol-oriented” language, compare POP and object-oriented programming (OOP), compare value semantics and reference semantics, consider local reasoning, implement delegation with protocols, use protocols as types, use protocol polymorphism, review my real-world POP Swift code, and finally, discuss why I’ve not bought 100% into POP. Download the source code from the article so you can follow along: There are 2 playgrounds and one project on GitHub, both in Xcode 9 format and written in Swift 4.
We’re going to learn about a feature of Swift called “property observers” that help developers manage app state. You can easily add code to monitor changes to Swift native type property values as well as your own custom type property values. Remember that you can gain insight into an application by looking at its state: the data values stored in all properties of the app at a specific point in time. Getting a grip on app state, therefore managing complexity, is one of the biggest challenges in computer science. Property observers are one technology that help you get a grip. In today’s article, I’ll explain this Swift feature, demonstrate its usage with runnable examples of Swift code, show you how I built an app which relies on property observers, and provide you a list of other Swift technologies that help you manage app state and complexity. Here’s my sample app in action:
Download the Xcode 9 project and playground, both written in Swift 4, from GitHub so you can follow along with my discussion.
It is my great honor and privilege to have joined the tutorials team at AppCoda.com as a freelancer. My first tutorial, “Swift 4 Generics: How to Apply Them in Your Code and iOS Apps,” was published yesterday, and was originally published here on my own site at this link. I am looking forward to publishing many more tutorials for you, my most loyal readers, at AppCoda and here on iOSBrain.com. Note: If I cross-post an article on AppCoda and here, the article will appear first on AppCoda. Thank you AppCoda!
The topic today is how to communicate between objects within an app, specifically using iOS’s NSNotificationCenter. In the last post, “Tutorial: delegates and delegation in Swift 4,” I used delegation to communicate between two objects. In the code I wrote for the last article, the app’s main (and only) view controller waited to display an image. The image was not included in the app bundle, rather downloaded from a NASA website. I created a class that downloaded the image file. The view controller was informed that the image was finished downloading and ready to display using a technique called “delegation.” Here, we’ll modify the delegation tutorial code to work with NSNotificationCenter instead. The image downloading class will notify the view controller that the image has finished downloading by sending a notification (message).
I’m going to talk about “delegates” and “delegation.” I’ll lead you through a simple example of implementing the delegation design pattern in Swift 4, with full source code. My intent here is to show you how delegation works without getting bogged down in some crazy complex example. To help you become the best of the best, I’m going to introduce you to one of the greatest design tools to aid in object-oriented software development, UML. I’ll show you a UML diagram that I drew up to design and document the implementation of the delegation design pattern used in the sample app we’ll build together. Download the Xcode 9 project with full Swift 4 source from GitHub to follow along.
I’ll show you how to build a user interface (UI) helper, a class that downloads a file at a specified URL. Most importantly, I’ll show you how, through delegation, a UIViewController subclass can be notified by the helper that an image file has finished downloading, and then the view controller can display the image on screen. For the sake of simplicity and clarity, we’ll pretend that Swift has minimal support for downloading a file from a URL. We’ll manually wire up the notification that the file has finished downloading using the delegation design pattern. Here’s the app we’ll build:
You’ve been working on your billion dollar app happily for days or weeks. It’s Monday morning, you open up Xcode 9 to get back to work and — dang, bummer — all your IBOutlet and IBAction connections look like they’ve been disconnected (see image below):
How would you enable or disable multiple user interface controls using one IBOutlet and one IBAction? For example, you might need to disable a UITextBox and UISegmentedControl because a user’s login has expired. Perhaps a user hasn’t filled in some required fields on a form, so you want to disable several buttons. Watch the following video to see how I built a Swift 3 app to use a UISwitch to enable or disable four controls all at one time — and I demonstrated the object-oriented programming (OOP) principle of polymorphism: