Why Swift?

With Swift 3 coming out of beta, some are still asking the question ‘Why Swift?’

Maybe you’re already an Objective-C developer – why learn a new language when the old one works fine?

Or maybe you’re learning iOS development and are facing the daunting question – should I learn Objective-C, the stalwart language that’s been around for many years, or Swift, the chic new up-and-coming language that keeps evolving!

I wrote an article recently on this question recently for medium – ‘Why Swift‘ – go check it out!

The article is actually an excerpt from my new book, iOS Development with Swift.

Grummitt-iOS-HI

 

iOS Development with Swift is Deal of the Day for today, September 20! 

Half off iOS Development with Swift. Use code dotd092016au at http://bit.ly/2cI792G

 

Any vs AnyObject vs NSObject in Swift 3

What is the difference between these three enigmatic types? A sometimes confusing topic, and to confuse things further Swift 3 has shaken it up by removing implicit bridging between Foundation and native data types. Aagh! Let’s get it straight by looking at an example with arrays.

You probably know Swift is a type-safe language. For this reason, the compiler won’t permit you to type infer an array of different types that don’t share a common root:

//Error: Type of expression is ambiguous without more context
var test = ["a",0]

Strings and Ints in Swift don’t share a common root, so the compiler doesn’t know what you want it to do when type inferring the array.

There are three tricks for removing this error:

Solution 1: Array of NSObjects

If you import UIKit and cast the string as an NSString and the Int as an NSNumber the error goes away. Why?

import UIKit
//No error, test inferred to be [NSObject]
var test =  ["a" as NSString,0 as NSNumber]

UIKit Framework includes the Foundation framework. If you have imported the Foundation framework you can explicitly bridge common Swift data types to their Foundation Objective-C counterparts. (this bridging was automatic pre-Swift 3) String for example, bridges to NSString and Int can bridge to NSNumber.
Unlike in Swift, in Objective-C, most data types do have a root: NSObject is an actual class (docs here), that is the root of most classes if you’re using the Foundation framework.

If you option-click on the test variable, you’ll find that it has defaulted to [NSObject].

But then – out of curiosity – what happens if you add another variable to the array that does not have NSObject as a root, such as a class of your own?

class Test {}
//Error
var test = [Test(),"a" as NSString,0 as NSNumber]

The compiler can no longer find a root class to infer the array’s data type. You would need a way to indicate to the compiler that you know that the elements of the array are incompatible, and you’re ok with that.

Solution 2: NSArray

One solution would be to type the array as Foundation data type NSArray. NSArray is less strict than its Swift countertype; NSArray doesn’t enforce that elements it contains are the same data type.

//No error: test defined as NSArray
var test:NSArray =  [Test(), "a",0]

Solution 3: [Any] or [AnyObject]

If you specifically define the array as [Any], you are indicating to the compiler that you are aware that the elements are not of the same data type, and you are ok with that.

class Test {}
//No error, test is defined as [Any]
var test:[Any] = [Test(),"a",0]

You may be surprised to learn that unlike NSObject, Any is not actually a concrete data type. You won’t find a type description for it in documentation. Rather Any is an alias for any data type.

Similarly, AnyObject is an alias for any data type derived from a class. You can use it to define an array that contains more than one object derived from a class, that don’t share a common root class:

class Test {}
class Test2 {}
//No error, test is defined as [AnyObject]
var test:[AnyObject] = [Test(),Test2()]

(You could of course have used [Any] as well – [AnyObject] is just a little more specific.

Passing in a string and an integer for example, to an AnyObject array will cause an error, as these data types are structs in Swift.

//Error: String does not conform to element type 'AnyObject'
var test:[AnyObject] = ["a",0]

Of course, an Array which could contain any data type is unlikely to pop up in your code, and if it does, maybe you should double-check you’re following best practices!
Rather, this has been an exercise to explore Any, AnyObject, NSObject, NSArray and how Swift 3 now requires explicit bridging between Foundation and native data types. Hopefully this helps!

Parsing XML in Swift 3

Parsing XML has always bothered me in Swift. The NSXMLParser class doesn’t actually parse the XML structure into Swift objects, rather it traverses the XML structure, pinging its delegate whenever it discovers something new, like an XML element or attribute, and then leaves it up to you to make something of it.

There are several solutions out there for parsing XML to Swift objects, such as AEXML or SwiftyXML, but nothing seemed to do exactly what I was after, or had problems in Swift 3.

I decided to write my own XML Parser, and I’ve called it SwiftXML. Check it out here!

 

Sorting strings in Swift

Sorting an array of strings in Swift is a bit of an iceberg topic – it seems fairly manageable, you just call the sort function right? Then you dig a little deeper and find a whole lot more lurking under the surface!

Let’s start with the example in Apple’s Swift Programming Language guide:

(Apple sorts the data in reverse order, for simplicity I’ve swapped it)

let names = ["Chris", "Alex", "Ewa", "Barry", "Daniella"]
let sortedNames = names.sorted(by: { $0 < $1 } )
print(sortedNames)
// Prints "["Alex", "Barry", "Chris", "Daniella", "Ewa"]"

Great, but what happens if “Alex” starts with a lower case letter? Alex gets shunted to the end of the list – probably not what you’re after!
“Barry”, “Chris”, “Daniella”, “Ewa”, “alex”

To ignore case, compare the lower case versions of the names:

let sortedNames = names.sorted(by: {
    $0.lowercased() < $1.lowercased() } )

The rules for ordering strings can vary for different languages and locales. From Apple’s iOS String Programming Guide:

Important: For user-visible sorted lists, you should always use localized comparisons.

Fortunately, strings have another property called localizedLowercase.

let lowercaseSortedNames = names.sorted(by: {
    $0.localizedLowercase &lt; $1.localizedLowercase } )

Now let’s add some complexity to this problem. Let’s say we have a Person class, that contains a first name and a last name, and an array of people:

struct Person {
    var firstName: String
    var lastName: String
}
let people = [
    Person(firstName: "Kylie", lastName: "Minogue"),
    Person(firstName: "Dannie", lastName: "Minogue"),
    Person(firstName: "Paul", lastName: "Kelly"),
    Person(firstName: "Ned", lastName: "Kelly")
]

Sorting them by last name is easy enough, just be sure to include the lastName property:

let sortedPeople = people.sorted(by: {
    $0.lastName.localizedLowercase < $1.lastName.localizedLowercase } )

Screenshot 2016-08-05 12.57.30

Obviously the first names need to be compared as well. You can achieve this by putting the two comparisons into a tuple:

let sortedPeople = people.sorted(by: {
    ($0.lastName.localizedLowercase,$0.firstName.localizedLowercase) <
        ($1.lastName.localizedLowercase,$1.firstName.localizedLowercase)
} )

Screenshot 2016-08-05 13.02.11

My book: iOS Development with Swift – Early access Deal of the Day!

I’m pleased to announce that I am half way through writing a book on iOS development with Swift, to be published by Manning Publications.

The great news if you have experience in programming is that this book skips over all the basics, and skips straight to the juicy bits – such as “What’s new and different in Swift?” After introductory material, the book will take you through the process of building a sophisticated app in iOS from concept through to beta testing and the App Store.

Extra special news is that it is Deal of the Day for today (July 28) and early access is available for half-price.

Use code dotd072816au at http://bit.ly/2avl1hSGrummitt-iOS-HI.jpg

Keyboards, text views and first responders

If you’re moving your app’s interface from under the keyboard when it appears, you’re probably doing the following:
1. Get a reference to the relevant text field in the UITextFieldDelegate‘s textFieldDidBeginEditing method.
2. Listen to a relevant keyboard notification (possibly UIKeyboardWillShow or UIKeyboardWillHide but probably the best to use is UIKeyboardWillChangeFrame, as this covers all your bases). Get the size of the keyboard from the userInfo property and move the textField up out of the way.

Great, this works because when the user taps on a text field, the events occur in this order:
1. textFieldDidBeginEditing
2. UIKeyboardWillChangeFrame

But then when you happen to implement a text view you’ll discover that the events occur in the opposite order:
1. UIKeyboardWillChangeFrame
2. textViewDidBeginEditing

Whaaa? Well, that messes up the steps we were following – when we get the UIKeyboardWillChangeFrame notification, we don’t yet have a reference to the relevant text view to move it!

How to solve this? Here are three approaches:
1. Use UIKeyboardDidChangeFrame (Did, not Will) instead, to be sure we get it in the right order. Problem – we can no longer animate interface changes simultaneously with the keyboard, rather animations will happen in sequence.
2. Store the keyboard size in a property in the UIKeyboardWillHide selector. Call a method (let’s call it moveInterface() ) after both steps that will move the interface out of the way. The moveInterface() method will only work when it has references to both the keyboard size, and the relevant text field / text view.
3. Here’s another option, thinking outside the box:

The reason why we need to get a reference to the text field/view in the …didBeginEditing method, is that Apple hasn’t given us a simple way to get a reference to the current field/view being edited (also known as the firstResponder). However, Apple has given us an isFirstResponder() method that will tell you if a view is currently the fist responder. Great! We can use that method to recursively iterative through a view’s subviews and determine the current first responder.

If we know the first responder, we don’t need the …didBeginEditing methods at all, and can skip straight to dealing with moving the interface when we receive the UIKeyboardWillChangeFrame notification.

Here’s a UIView extension to add a computed property that returns the first responder from a view’s subviews:

import UIKit
extension UIView {
    var firstResponder:UIView? {
        if self.isFirstResponder() {
            return self
        }
        for view in self.subviews {
            if let firstResponder = view.firstResponder {
                return firstResponder
            }
        }
        return nil
    }
}

And here’s a UIViewController extension to get the scene’s first responder:

extension UIViewController {
    var firstResponder:UIView? {
        return view.firstResponder
    }
}

Any vs AnyObject vs NSObject

What is the difference between these three enigmatic types? A sometimes confusing topic, let’s get it straight.

UPDATE: Things have changed in Swift 3!

This post has been updated for Swift 3 here.

You probably know Swift is a type-safe language. For this reason, the compiler won’t permit you to type infer an array of different types that don’t share a common root:

//Error: Type of expression is ambiguous without more context
var test = [&quot;a&quot;,0]

Strings and Ints in Swift don’t share a common root, so the compiler doesn’t know what you want it to do when type inferring the array.

There are two tricks for removing this error:

Solution 1: Import UIKit

If you import UIKit the error goes away. Why?

import UIKit
//No error, test inferred to be [NSObject]
var test = [&quot;a&quot;,0]

UIKit Framework includes the Foundation framework which automatically bridges common data types to their Foundation Objective-C counterparts. And unlike in Swift, in Objective-C, most data types do have a root: NSObject is an actual class (docs here), that is the root of most classes if you’re using the Foundation framework.

If you option-click on the test variable, you’ll find that it has defaulted to [NSObject].

But then – out of curiosity – what happens if you add another variable to the array that does not have NSObject as a root, such as a class of your own?

import Foundation
class Test {}
//No error, test inferred to be NSArray
var test = [Test(),&quot;a&quot;,0]

The compiler can’t find a root class to infer the array’s data type, but instead of displaying an error, it instead infers an alternative data type – the Foundation Objective-C NSArray. NSArray is less strict than its Swift countertype; NSArray doesn’t enforce that elements it contains are the same data type.

Solution 2: [Any] or [AnyObject]

If you specifically define the array as [Any], you are indicating to the compiler that you are aware that the elements are not of the same data type, and you are ok with that.

class Test {}
//No error, test is defined as [Any]
var test:[Any] = [Test(),&quot;a&quot;,0]

You may be surprised to learn that unlike NSObject, Any is not actually a concrete data type. You won’t find a type description for it in documentation. Rather Any is an alias for any data type.

Similarly, AnyObject is an alias for any data type derived from a class. You can use it to define an array that contains more than one object derived from a class, that don’t share a common root class:

class Test {}
class Test2 {}
//No error, test is defined as [AnyObject]
var test:[AnyObject] = [Test(),Test2()]

(You could of course have used [Any] as well – [AnyObject] is just a little more specific.

Passing in a string and an integer for example, to an AnyObject array will cause an error, as these data types are structs in Swift.

//Error: String does not conform to element type 'AnyObject'
var test:[AnyObject] = [&quot;a&quot;,0]

Unless you import Foundation! (or UIKit) As we saw earlier, importing UIKit bridges Foundation data types to their Foundation counterparts. Strings are bridged to NSStrings and Ints are bridged to NSNumbers. NSNumbers and NSStrings happen to be defined as classes in Objective-C, so they now fulfill the definition of being an AnyObject:

import UIKit
//No error: test defined as [AnyObject]
var test:[AnyObject] = [&quot;a&quot;,0]