Tweet
Tweet

Slide 1

Slide 1 text

Tailor your Swift Hand-crafting code as an Apple Developer

Slide 2

Slide 2 text

Swift What does it have?

Slide 3

Slide 3 text

All the things properties, optionals classes, structs, enums (super-powerful) blocks (with lamba-expression syntax) protocols (interfaces) class and protocol extensions generics

Slide 4

Slide 4 text

Properties stored computed lazy

Slide 5

Slide 5 text

read-only lazy with more observers

Slide 6

Slide 6 text

Properties wrappers

Slide 7

Slide 7 text

Methods uniquely Swift

Slide 8

Slide 8 text

Classes - can inherit from only 1 subclass - can implement 1 to many protocols (interfaces)
 - the usual reference type behavior

Slide 9

Slide 9 text

Structs - cannot inherit from another struct or class - can implement 1 to many protocols (interfaces)
 - the usual value type behavior

Slide 10

Slide 10 text

When to use what - when you need to inherit, use a class. - when your type has utility methods, holds properties (like a model object), etc. make it a struct.
 - Immutability should be preferred, thus prefer structs and use a class only when it’s necessary.

Slide 11

Slide 11 text

Enums associated values can declare a type and raw values

Slide 12

Slide 12 text

Blocks

Slide 13

Slide 13 text

Protocols

Slide 14

Slide 14 text

Optionals It’s there or it’s not

Slide 15

Slide 15 text

The Crux Why is writing better code important?

Slide 16

Slide 16 text

The complex programmer • writes cryptic, complex code because they can. • never reads programming books or attends meetups, code confs. etc. • no documentation, if you can’t read it, you’re just a bad developer. • basically a ‘lifer’ at the business.

Slide 17

Slide 17 text

The thoughtful programmer • writes clean, patterned and thoughtful code. • always strives for improvement and not for the sake of making more money. • documents code with proper naming, patterns and comments. • uses peer-reviewed pull requests to learn from his mistakes.

Slide 18

Slide 18 text

Clean Swift thoughtful coding in Apple’s language

Slide 19

Slide 19 text

mini methods

Slide 20

Slide 20 text

speaking of conditional statements be explicit

Slide 21

Slide 21 text

Prefer Swift’s method naming conventions methods should read like human speech

Slide 22

Slide 22 text

Remember, you’re making code easier to read for yourself as well as others.

Slide 23

Slide 23 text

Use , instead of && only applies to if/else statements still need || if you want to OR

Slide 24

Slide 24 text

unwrapping optionals

Slide 25

Slide 25 text

1) 2) unwrap and add a conditional

Slide 26

Slide 26 text

clean up optionals with guard • early termination (no need to carry on if conditions aren’t met). • cleans by removing if let optional bindings and conditional statements

Slide 27

Slide 27 text

optionals continued.

Slide 28

Slide 28 text

community agreement on optional unwrapping • prefer to use the same name as the optional. • the compiler has no issues, and it will only be local to the method. • The same goes for guard, use the optional’s name for the unwrapped type.

Slide 29

Slide 29 text

don’t return an optional just because you can

Slide 30

Slide 30 text

Like a book. Group sentences into thoughts, or paragraphs

Slide 31

Slide 31 text

assert yourself • assertionFailures should be used in place of many NSLog and print statements. • You the developer need to find crashing conditions early not in QA • Go through every console log (NSLog, print) and replace with error reporting and/or add to them with an assertFailure

Slide 32

Slide 32 text

• A great place to use them is in fail early guard statements. • They are stripped out for a release build (assuming you’re using different builds). • fail early and stop to solve bugs during development and not from a QA bug ticket.

Slide 33

Slide 33 text

I see dead comments • Comments are part of the code, treat them as such • The less noticeable they are, the more likely they’ll go unmaintained • Change their color to stand out more • Pay attention to comments in pull requests.

Slide 34

Slide 34 text

Take care of warnings • _ = lets you suppress the unused result warning, and explicitly tells the reader “I am intentionally ignoring this returned value.” • Follow Xcode’s instructions or fix the code to make the warning go away • Sign of a broken-window-theory project are hundreds of warnings.

Slide 35

Slide 35 text

ViewControllers MVC ? Massive-View-Controller

Slide 36

Slide 36 text

The problem

Slide 37

Slide 37 text

Start cleaning • Add a (pragma) mark above every set of protocol code (for each) • This gives you a nice visual divider in the code and the quick search drop-down

Slide 38

Slide 38 text

Extract and extend take the code out of the VC and add an extension • naming convention: className+protocol.swift • technically it’s still a part of the class but it reduces the size of the class and organizes the code better.

Slide 39

Slide 39 text

Lighten the load use the coordinator pattern for viewControllers • The heart of the problem is that segues and navigation are usually implemented in the view controllers. • This tightly couples 1 view controller to another. • Remove this responsibility with a Coordinator

Slide 40

Slide 40 text

Coordinate everything in software should have 1 job. • Every view controller gets a coordinator • All vc coordinators are controlled by an AppCoordinator • Makes the ViewControllers do only what they’re supposed to, update the view. • Segues are negated, as the coordinators now control the navigation and app workflow

Slide 41

Slide 41 text

ViewCoordinator

Slide 42

Slide 42 text

Coordinator Tutorial https://www.raywenderlich.com/158-coordinator-tutorial-for-ios-getting-started

Slide 43

Slide 43 text

Protocol based

Slide 44

Slide 44 text

Core Data manage model objects as protocols

Slide 45

Slide 45 text

Prefer protocols • Apple strongly suggests protocol-based development and you see it through out CocoaTouch. • Protocols let you swap out dependencies easily at run-time. • Coordinators can hold onto these protocol-based dependencies instead of ViewControllers. • Protocols enforce the you-have-1-job rule better.

Slide 46

Slide 46 text

Thank you!