My original article — “Design Patterns in Swift #1: Factory Method and Singleton” — was published on appcoda.com.
There are 23 classic software development design patterns probably first identified, collected, and explained all in one place by the “Gang of Four” (“GoF”), Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their seminal book, “Design Patterns: Elements of Reusable Object-Oriented Software.” This tutorial focuses on two of those patterns in terms of what the GoF calls the “creational” category: “factory method” and “singleton.” Follow along with the Xcode projects both on GitHub, available for factory method here and singleton here.
Continue reading “Two Creational Design Patterns in Swift 4: Factory Method and Singleton”
In this tutorial, I’ll show you how to track down memory leaks within Xcode via the Memory Graph Debugger, new since Xcode 8. This is a powerful visual tool and doesn’t require you to step out of Xcode and start the Leaks Instrument. Once we identify some memory leaks, I’ll show you how to plug those leaks by using the Swift language’s
unowned qualifiers, and talk about the differences between the two qualifiers.
I recently discussed iOS memory management and memory leaks that occur when using reference semantics and reference types (classes) in my tutorials on “Swift 4 memory management via ARC for reference types (classes)” and “Fixing memory leaks — strong reference cycles — in Swift 4.” After reading these articles, you should understand how easy it is to inadvertently encode and introduce a strong reference cycle into your Swift 4 code and thus end up with a memory leak. You should also understand how generally straightforward it is to fix such a memory leak. My sample code in both tutorials was didactic. What about real-world projects with hundreds of thousands or millions of lines of code? Suppose that you’ve heard reports of diminished app performance, low memory warnings, or just plain app crashes. Finding memory leaks in your code is quite cumbersome when trying to debug via rote inspection, setting breakpoints, adding logging statements, etc.
Continue reading “Finding memory leaks with the Xcode Memory Graph Debugger and fixing leaks with unowned and weak”
PREREQUISITES FOR THIS TUTORIAL
If you don’t understand how Swift manages memory for classes (reference types), you need to read the first article in this series, “Swift 4 memory management via ARC for reference types (classes)”. Once you understand how reference type-based memory is managed with ARC, you’ll be ready to understand how to prevent memory leaks from occurring in your app. Remember that ARC only applies to reference (
class) types, not value types like
THE ARC DEALLOCATION PROCESS
Remember how we visualized the reference count that ARC maintains on the allocated instance of reference type
Widget in my introductory ARC tutorial?
// reference count is zero; nothing allocated
widgetReference = Widget(name: "eraser", manufacturer: "Acme")
// reference count is now 1
widgetReference1 = widgetReference
// reference count is now 2
widgetReference2 = widgetReference
// reference count is now 3
widgetReference = nil
// reference count is now 3-1 = 2
widgetReference1 = nil
// reference count is now 2-1 = 1
widgetReference2 = nil
// reference count is now 1-1 = 0
Continue reading “Fixing memory leaks — strong reference cycles — in Swift 4”
My original article — How to Integrate Your App with Files App in iOS 11 — was published on appcoda.com.
In this tutorial I’ll show you how to embrace iOS 11’s Files app. First, I’ll walk you through configuration of an app so that any files stored in its iOS file system-based “Documents” folder are made visible in the Files app and exposed to other apps installed on your device. Second, I’ll demonstrate how you can incorporate a Files app-like interface and functionality into your own apps. All of the Swift code I wrote to accomplish these two tasks is included below — and I’ve taken lots of screenshots regarding Files app integration. Sit back, enjoy, and learn about a fundamental paradigm shift in the iOS zeitgeist, moving from a “hide-the-details” (like hiding individual files) mindset to providing users with the ability to look at and manipulate files related to their apps using a macOS Finder-like interface, except on iOS.
To pique your interest, let’s look at a feature I encoded in the final app for this tutorial. We’ll use my app, named “Document-Based App,” to view an image file in the app’s main folder:
Continue reading “iOS 11 Files app integration and the UIDocumentBrowserViewController”
Most developers assume that Swift is a “safe” language in terms of memory management. That’s probably true most of the time, but there are some notable exceptions, especially when dealing with certain scenarios when using what are called “reference types” and “reference semantics.”
This tutorial is ultimately meant to prepare you for in-depth discussion of what seems to be inevitable shift from reference semantics to value semantics. Before I plunge into this software development paradigm shift, I want to provide you with a strong and understanding of how memory is managed when you create and use instances of the
class type, a reference type. Oftentimes, reference-based memory management “just works” … until it doesn’t. Things don’t work mainly in situations where
class types are designed with interdependencies and/or when multiple threads access the same instance (object) of a
class type, and you get “memory leaks.” Swift manages reference-based memory with a technology Apple has dubbed “Automatic Reference Counting” (ARC). Before even begin talking about debugging memory leaks, you must understand ARC.
This discussion does not pertain to memory management for value types (
enum), but note that I will mention value types and value semantics several times in terms of comparison to reference types and reference semantics.
Continue reading “Swift 4 memory management via ARC for reference types (classes)”
Have you ever wondered how all those people out there figured out how to manipulate the iOS file system in their apps? For some strange reason, Apple has never provided well-organized documentation on the subject. Here’s how I feel: “Ask and simple question and get an obtuse and overly complex answer.” There are many articles and tutorials out there, including my own, showing you examples of Objective-C or Swift code for manipulating the iOS file system, and most of the code looks basically the same. Nonetheless, this code is deceivingly complex, often underestimated, and rarely well-explained or well-understood.
Where did everybody find this boilerplate code? From simple observation, I’ve found that in many cases, developers use a copy and paste methodology, i.e., look up a few keywords in a web search engine, find the code needed on sites like StackOverflow or some blog, copy it, paste it into an Xcode project, and beat on it until it works. I don’t want you to feel this way after reading my tutorials.
I hope you’ll find it edifying and interesting to read about how I figured out how to understand and navigate the iOS file system using the “most of the code looks basically the same” boilerplates. But I bet you’ll find it even more intriguing to find that I’ve discovered an much better alternative to the boilerplate code.
Continue reading “The iOS file system in-depth (and how to be the best using critical thinking)”
My original article — Introduction to MVVM: refactoring a MVC app using the MVVM design pattern — was published on appcoda.com.
[Download the Xcode 9 project from GitHub so you can follow along with my code explanation and try MVVM yourself!]
Design patterns are very important tools for iOS developers to keep in their software engineering arsenals. These patterns, along with several other best practices I’ll mention below, help developers to create reliable and maintainable apps. In other words, design patterns help in managing software complexity. In this tutorial, I’ll introduce you to the “Model-View-ViewModel” or “MVVM” design pattern. For a historical and pragmatic perspective, I’ll compare the very well-known “Model-View-Controller” or “MVC” design pattern, long favored by many iOS developers, to MVVM, which has steadily been gaining traction among the same group of developers.
In order to help you understand these design patterns, I’ll walk you through the design and coding of my app shown here:
Continue reading “Introduction to MVVM: refactoring an MVC app using the MVVM design pattern”
My original article — Introduction to HealthKit with Core Bluetooth — was published on appcoda.com.
[Download the Xcode 9 project from GitHub so you can follow along with my code explanation and try iOS
HealthKit features yourself!]
In a previous tutorial, I discussed the technology, applications, and benefits of Apple’s
Core Bluetooth framework. I showed you how to build an app that wirelessly connected to a Bluetooth® heart rate monitor (HRM) — a small, portable, and “wearable” device. My sample app’s code read heart rate data from the HRM, but it didn’t do anything with the heart rate data except display it in real-time on an iPhone’s screen. While edifying and interesting, there are already a bazillion apps in the App Store that can read heart rate data, and other wearable data, using
Core Bluetooth. What about doing something interesting with that data, like analyzing it, deriving value-added and meaningful results from it, and sharing it with researchers? That’s where Apple’s
HealthKit framework shines. Please download the Xcode 9 project written is Swift 4 so you can follow along with my discussion.
Continue reading “Introduction to iOS HealthKit with Core Bluetooth using Swift 4”