Swift Archives — Page 5 of 9 — Coding Explorer Blog

Instance Methods and Type Methods in Swift

Last updated on August 12, 2020

We touched a bit on this in a previous post Classes In Swift — An Introduction. To recap what was mentioned in that post, methods are functions that are associated with a type. In other words, all methods are functions, but not all functions are methods. Functions can be written outside of the context of a type, especially in playgrounds. I felt it would be best to state that in a post dedicated to them, instead of having it just nestled in the Classes post. I also have learned of some nuances about them, that there are a few differences between them, particularly in parameter naming. While I’m at it, we’ll quickly cover the idea of type methods as well.
[Read more…]

Designated Initializers and Convenience Initializers in Swift

Last updated on August 12, 2020

Today we will be learning about another aspect of Class Initializers. The Swift language has two different types of initializers they are called designated initializers and convenience initializers. These existed in Objective-C, but a few rules have changed in Swift, and a very helpful keyword was introduced. We will discuss how designated and convenience initializers are used, and how they can work together to get your classes ready for use.

Designated Initializers

Like most constructs in Swift, designated initializers are aptly named and do exactly what they say they do. They are the main initializers to be used for a class. A class must have one designated initializer, but it is not limited to one. It can have multiple if necessary, but most classes only have one.
[Read more…]

Swift Property Observers

Last updated on August 12, 2020

In my previous article Class Initializers, I had mentioned property observers, and glossed over them a bit. Now we’ll discuss them in a bit more depth.

Why use a Property Observer?

Back in Objective-C, if you wanted to do any special handling for setting a property, you would have to override the setter, reimplement the actual value setting (that was originally done for you), and then add whatever you wanted to do besides that, like posting a notification of a change. Swift’s property observers save you from having to reimplement the setter in those cases.

Property Observers are somewhat similar to computed properties. You can read more about those in my previous article Computed Properties in Swift. For computed properties, you write custom code for the getter and setter. For property observers, you write custom code only for setting, for right before (willSet) and right after (didSet). The main purpose of Swift’s property observers is to watch for when a property is set. As such, property observers are only useful for variables (var properties), and cannot be written for constants (let properties).
[Read more…]

Class Initializers

Last updated on August 12, 2020

Writing Class Initializers

So, I have mentioned a few times about initializers on this blog. I want to talk today about writing and using initializers for classes, later we can talk a bit more about how they are different for value types like structs or enumerations.

Initializers do exactly what is sounds like they do, they initialize your instances and get them ready to use. Specifically, before an object can be used, it must set all of its stored properties to valid values. This can be handled in one of three ways:

Give them default values in their property definition
Set them during the initializer
Declare them as optionals

[Read more…]

Using a Nested Type in Swift

Last updated on August 12, 2020

In my previous post Classes In Swift — An Introduction, I mentioned that I should probably use an enumeration to denote what the status of my Message was (whether it was sent, received, or read). Now, I could write a full MessageStatus enumeration with its own file that could be imported into any project, and that would work. But really, this status is only supposed to talk about my custom class here, about my “Message” class. Why go through all of the hassle to make this some generic MessageStatus enumeration that could be used on messages completely unrelated to my Message class?

This is exactly where we would want to use a nested type!
[Read more…]