Emerging Best Practices in Swift

Slide 1

Slide 1 text

Emerging Best Practices in Swift Ash Furrow

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Afraid I was

Slide 4

Slide 4 text

Fine Everything turned out

Slide 5

Slide 5 text

Best Practices in Swift

Slide 6

Slide 6 text

What do they look like? Also, how do we find new ones?

Slide 7

Slide 7 text

Agenda • We’ve been here before • Learning is forever, deal with it • Never throw ideas away • How to force yourself to think • Always be abstracting

Slide 8

Slide 8 text

Let’s go!

Slide 9

Slide 9 text

This looks strangely familiar…

Slide 10

Slide 10 text

—Lots of people, for hundreds of years “Those who don’t study history are doomed to repeat it.”

Slide 11

Slide 11 text

Wow, that’s depressing.

Slide 12

Slide 12 text

—Me, today “Those who don’t understand the past can’t make informed decisions about the present.”

Slide 13

Slide 13 text

iOS 5 or earlier?

Slide 14

Slide 14 text

Before Object Literals NSArray *array = [NSArray arrayWithObjects: @"This", @"is", @"so", @"tedious", nil]; NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys: @"Who would do this?", @"Not me", nil]; NSNumber *number = [NSNumber numberWithInt:401];

Slide 15

Slide 15 text

Before Object Literals and ARC NSArray *array = [[NSArray arrayWithObjects: @"This", @"is", @"so", @"tedious", nil] retain]; NSDictionary *dictionary = [[NSDictionary dictionaryWithObjectsAndKeys: @"Who would do this?", @"Not me", nil] retain]; NSNumber *number = [[NSNumber numberWithInt:401] retain];

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

After Object Literals NSArray *array =   @[ @"This", @"is", @"much", @"better" ]; NSDictionary *dictionary =   @{ @"Who likes this?": @"Me!" }; NSNumber *number = @(401);

Slide 18

Slide 18 text

Object Literals • Clearly way better • Adopted by everyone almost immediately • Became a “best practice”

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Blocks & GCD • Introduced in iOS 4 • Adopted slowly, but surely • Required new ways of thinking • Did using blocks became a “best practice”? • Sort of…

Slide 21

Slide 21 text

Enable Blocks other best practices

Slide 22

Slide 22 text

^{ Functional Reactive Programming Futures Promises Collections Operations Callbacks Inline Network Operations Generic Datasource Objects Deferred Customization Contextual Code Execution

Slide 23

Slide 23 text

Embrace Change

Slide 24

Slide 24 text

Swift 2

Slide 25

Slide 25 text

Swift 2 • Lots of new syntax • New syntax lets us do new things • However! Syntax is only a tool • Like blocks, Swift 2 syntax is most useful when it enables new ideas

Slide 26

Slide 26 text

Swift 2 • guard • defer • throws • etc…

Slide 27

Slide 27 text

Should I use guard?

Slide 28

Slide 28 text

What can I do with guard?

Slide 29

Slide 29 text

Examples

Slide 30

Slide 30 text

Pyramid of Doom if let thing = optionalThing { if thing.shouldDoThing { if let otherThing = thing.otherThing { doStuffWithThing(otherThing) } } }

Slide 31

Slide 31 text

Clause Applause if let thing = optionalThing, let otherThing = thing.otherThing where thing.shoudDoThing { doStuffWithThing(otherThing) }

Slide 32

Slide 32 text

Avoid Mutability func strings( parameter: [String], startingWith prefix: String) -> [String] { var mutableArray = [String]() for string in parameter { if string.hasPrefix(prefix) { mutableArray.append(string) } } return mutableArray } ಠ_ಠ

Slide 33

Slide 33 text

Avoid Mutability func strings( parameter: [String], startingWith prefix: String) -> [String] { return parameter.filter { $0.hasPrefix(prefix) } }

Slide 34

Slide 34 text

Currying • One of those weird words you avoid because people who say it are sometimes jerks • It’s actually a pretty straightforward concept • Currying is a function that returns another function • Useful for sharing code that’s mostly the same

Slide 35

Slide 35 text

Before Currying func containsAtSign(string: String) -> Bool { return string.characters.contains("@") } ... input.filter(containsAtSign)

Slide 36

Slide 36 text

Currying func contains(substring: String) -> (String -> Bool) { return { string -> Bool in return string.characters.contains(substring) } } ... input.filter(contains("@"))

Slide 37

Slide 37 text

Currying func contains(substring: String)(string: String) -> Bool { return string.characters.contains(substring) } ... input.filter(contains("@"))

Slide 38

Slide 38 text

Extract Associated Values • Use Swift enums • Attach associated values • Extract using a case

Slide 39

Slide 39 text

Extract Associated Values enum Result { case Success case Failure(reason: String) } switch doThing() { case .Success: print("") case .Failure(let reason): print("Oops: \(reason)") }

Slide 40

Slide 40 text

Extract Associated Values enum Result { case Success case Failure(reason: String) } if case .Failure(let reason) = doThing() { print(" \(reason)") }

Slide 41

Slide 41 text

Syntax That’s all just

Slide 42

Slide 42 text

Ideas What matters are

Slide 43

Slide 43 text

Protocol-Oriented Programming

Slide 44

Slide 44 text

… just go watch the WWDC video.

Slide 45

Slide 45 text

Others Let’s ask

Slide 46

Slide 46 text

Syntax vs Idea • How to tell if something is universally a good idea, or just enables other ideas? • You can’t • It’s a false dichotomy • I lied to you • I’m so sorry

Slide 47

Slide 47 text

Try stuff You’ve just got to

Slide 48

Slide 48 text

Ideas Never throw away

Slide 49

Slide 49 text

Never Throw Away Ideas • Swift was released • We treated Swift like object literals instead of like blocks • Some of us thought Swift was universally better • My fault, oops

Slide 50

Slide 50 text

Merit Older ideas have

Slide 51

Slide 51 text

A lot iOS developers throw things away

Slide 52

Slide 52 text

Why?

Slide 53

Slide 53 text

Beginner learns thing Is bad at thing Blames thing Thing must be bad

Slide 54

Slide 54 text

Beginner gets more experience New thing comes out Learning new thing is easier than old thing New thing must be good

Slide 55

Slide 55 text

Appealing New ideas are

Slide 56

Slide 56 text

Always a fresh supply of old APIs for us to blame iOS is constantly changing

Slide 57

Slide 57 text

Refactoring Let’s talk about

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

What is Not Refactor? • Refactoring does not add new functionality • Refactoring does not change a type’s interface • Refactoring does not change a type’s behaviour

Slide 60

Slide 60 text

Changing a unit test? Refactoring Rewriting No Yes

Slide 61

Slide 61 text

Bad Rewrites are

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

Favour incremental change

Slide 64

Slide 64 text

Code isn’t necessarily valuable But throwing it away is dangerous

Slide 65

Slide 65 text

Things to never throw away: Code Ideas &

Slide 66

Slide 66 text

Change Unit tests will help

Slide 67

Slide 67 text

Unit Testing & Thinking • So, uhh, unit testing • Controversial in iOS • Not so much everywhere else • Why? • We’ll get to that

Slide 68

Slide 68 text

Benefits of Testing • (Let’s presume that unit testing is a good idea) • I really don’t care that much about the tests • I care more about how writing tests makes me think about what I’m writing

Slide 69

Slide 69 text

Benefits of Testing • Limited object scope is good • High cohesion, low coupling • How to limit scope? • Controlling public interface and dependencies

Slide 70

Slide 70 text

Dependency injection?

Slide 71

Slide 71 text

Dependency Injection • €5 word for a ¢5 idea • Your things shouldn’t create the things they need

Slide 72

Slide 72 text

Example

Slide 73

Slide 73 text

Without Dependency Injection class ViewController: UIViewController { let networkController = NetworkController() func viewDidLoad() { super.viewDidLoad() networkController.fetchStuff { self.showStuff() } } }

Slide 74

Slide 74 text

With Dependency Injection class ViewController: UIViewController { var networkController: NetworkController? func viewDidLoad() { super.viewDidLoad() networkController?.fetchStuff { self.showStuff() } } }

Slide 75

Slide 75 text

Dependency Injection • Rely on someone else to configure your instance • Could be another part of your app (eg: prepareForSegue) • Could be a unit test • Protocols work really well for this

Slide 76

Slide 76 text

Dependency Injection protocol NetworkController { func fetchStuff(completion: () -> ()) } ... class APINetworkController: NetworkController { func fetchStuff(completion: () -> ()) { // TODO: fetch stuff and call completion() } }

Slide 77

Slide 77 text

Dependency Injection protocol NetworkController { func fetchStuff(completion: () -> ()) } ... class TestNetworkController: NetworkController { func fetchStuff(completion: () -> ()) { // TODO: stub fetched stuff completion() } }

Slide 78

Slide 78 text

Dependency Injection • Use of protocols limits coupling between types • Adding a method to a protocol becomes a decision you have to make • Dependency injection can also be used for shared state, like singletons

Slide 79

Slide 79 text

Without Dependency Injection func loadAppSetup() { let defaults = NSUserDefaults.standardUserDefaults() if defaults.boolForKey("launchBefore") == false { runFirstLaunch() } }

Slide 80

Slide 80 text

How would you even test that?

Slide 81

Slide 81 text

With Dependency Injection func loadAppSetup(defaults: NSUserDefaults) { if defaults.boolForKey("launchBefore") == false { runFirstLaunch() } }

Slide 82

Slide 82 text

Don’t be an ideologue

Slide 83

Slide 83 text

Cheat with Dependency Injection func loadAppSetup( defaults: NSUserDefaults = .standardUserDefaults()){ if defaults.boolForKey("launchBefore") == false { runFirstLaunch() } }

Slide 84

Slide 84 text

Cheat with Dependency Injection loadAppSetup() // In your app loadAppSetup(stubbedUserDefaults) // In your tests

Slide 85

Slide 85 text

Cheat with Dependency Injection class ViewController: UIViewController { lazy var networkController: NetworkController = APINetworkController() func viewDidLoad() { super.viewDidLoad() networkController.fetchStuff { self.showStuff() } } }

Slide 86

Slide 86 text

—Mackenzie King (Canada’s Winston Churchill) “TDD if necessary, but not necessarily TDD.”

Slide 87

Slide 87 text

Unit Testing • Don’t test private functions • Also, start marking functions as private • Remember, we want to avoid rewriting • Don’t test the implementation • Don’t use “partial mocks” • See @searls post on partial mocks

Slide 88

Slide 88 text

Unit Testing • So why don’t iOS developers do unit testing? • It’s unfamiliar and no one forces us to do it

Slide 89

Slide 89 text

Better Testing code makes me a Developer

Slide 90

Slide 90 text

Everything Abstract

Slide 91

Slide 91 text

Two or more lines of repeated code? Find a better way

Slide 92

Slide 92 text

(╯°□°）╯︵ ┻━┻

Slide 93

Slide 93 text

Look for Abstractions • You’re already learning new syntax • Look for new abstractions along the way • Not all ideas will work out • But you should still do it • Experiment!

Slide 94

Slide 94 text

No such thing Failed experiment as a

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

Learn Always opportunities to

Slide 97

Slide 97 text

Wrap Up • We have a history of being awesome, let’s keep it up • Learning isn’t just for when Xcode is in beta • Ideas are more valuable than code, but throwing away either is dangerous • Effective unit tests make it easy to change code • Operate at the highest level of abstraction you can at any given time

Slide 98

Slide 98 text

Make Tomorrow Better Mistakes