We refactor our code by moving the app's flow from the storyboard into a separate class. Our goal is to manage the view controller flow from a central place so that view controllers don't have implicit knowledge of their context.
We extend the networking code from the first episode to support POST requests. Besides using Swift's enums with associated values and generics, we get to implement a map function on a custom data type.
We build a tree structure beginning with a flat array of Ledger account names. We first implement the tree using a class, and then we refactor it to a struct and discuss the differences and tradeoffs involved.
In this episode, we implement search functionality for our Ledger GUI app. In the process, we leverage several aspects we've talked about before, such as connecting view controllers, managing application state, and parsing user input.
We build a flexible sort descriptor abstraction, similar to NSSortDescriptor, on top of Swift's native sort methods. Because we make use of generics and first-class functions, the result is dynamic and type safe.
We come back to our unfinished Swift Talk iOS app and implement a lightweight network cache for offline support. We keep our networking code from episode #1 untouched to maintain a clear separation of concerns.
We show how to make an extension on array available to other collections: first, we implement it for array slices, then we implement it as a protocol extension for all collections.
In this episode, we make a custom collection conform to Sequence. This allows us to efficiently iterate over the elements, and we gain all the useful functionality of Sequence.
We build upon the Future type of a previous episode to implement a simple reactive library. Along the way, we dive into debugging a reference cycle in our implementation.
We add the ability to map over signals and control subscriptions in a more fine-grained manner. Along the way, we improve the signal ownership model and implement the concept of disposables.
In this final episode of our collection series, we make our custom IndexSet collection type conform to the Collection protocol, implementing a custom index type along the way.
We refactor some view controller logic while working on our upcoming tvOS app. Instead of letting multiple view controllers manage the navigation bar's state individually, we pull this code out and unify the logic in one place.
We build the basic routing infrastructure to map paths to the code that should handle a particular request. We take a different approach than most web frameworks in an attempt to make the code type safe and more at home in Swift.
We look at multiple ways to create variables that have a class type but also conform to a protocol.
Brandon from Kickstarter joins us to discuss deep linking into an iOS app. We show how to unify all potential entry points into the app using a common route enum, and then we take a look at this pattern in Kickstarter's open source codebase.
We continue buildling our PostgreSQL wrapper. This time, we add the possibility of using queries with properly escaped parameters. To achieve this, we have to dive deep into Swift's unsafe pointer APIs.
Brandon from Kickstarter is back to show us how the company uses playgrounds to prototype and style individual view controllers.
This week Lisa joins us to demonstrate the test-driven approach to reactive programming taken at Kickstarter.
Károly joins us to improve our sorted array implementation from episode #35 using binary search. We benchmark both implementations to learn about their real-world performance.
In this episode, we implement a binary search tree as an alternative to the sorted array from the last episode. We benchmark the performance of insertion and lookup in both data structures, with some surprising results.
We build an experimental data type that combines the advantages of both structs and classes. It allows shared mutable state while preserving the features of structs to make easy copies and observe changes.
We refactor our reducer-based project from episode #62 to use The Elm Architecture. Instead of interacting with UIKit directly, we build a virtual view hierarchy and let our Elm framework do the rest.