Top-notch video tutorials for Swift developers

Most server applications will need to store some data in a database. For Vapor applications, this is done with Fluent, a Swift Object-Relational-Mapper for persisting objects to a database. Fluent supports SQLite, Postgres, and Mysql. In this episode we will learn how to set up Fluent with a SQLite database for development. We'll create our first model object, and discuss how Fluent supports migrations for evolving the database schema over time.

Let's take what we have learned and build a simple web app. We'll leverage NSLinguisticTagger on the server and built a small UI that extracts names from provided text. We'll lean on everything we have used so far in this series: routes, templates, master templates, context data, and a little CSS to make the UI look nice.

With special guest Yono, we dive into the system for text-to-speech and speech recognition on iOS. Yono builds an app for language practice. Along the way we become familiar with AVAudioEngine, AVSpeechSynthesizer, and SFSpeechRecognizer from the Speech Framework.

When working with web pages, you will almost certainly want to share a considerable amount of HTML. By nesting templates inside of master templates, we can share common HTML structure, layout, and share styles and scripts. We will see how to define sections that can be customized inside of your templates, as well as how to extract common components into partials that you can embed inside of other templates.

Leaf is Vapor's component for rendering dynamic templates. Rather than writing HTML strings by hand in our router, we can write leaf templates that allow us to mix HTML with code. Since Leaf is a separate package, we will show how to integrate this into your project from scratch, to get an overview of how dependencies are assembled in a Vapor project.

Vapor uses a router to determine how to process incoming requests. In this episode, we will see how to define routes and how to return simple responses. We will see how to return custom JSON responses, how to accept JSON posts, and how to deal with requests with dynamic parameters.

In this episode we'll learn how to install the vapor tools, how to create new projects, and look at how projects are structured.

Signposts are a special part of the Unified Logging and Activity Tracing system. They allow you to mark point-in-time events that occur in your code, or track the duration of operations by specifying the begin and end for an activity. These can be visualized in Instruments to get a rich, high level view of how these operations are performing, how often they are occurring, and how long they are taking. In this episode we will see how to add signposts to an app and how to view these signposts in Instruments.

Activity Tracing can help give you the big picture when looking at logs. By marking logical activities with os_activity, you can create a hierarchy of tasks that roll up the log statements that occurred for that activity. Unfortunately, using os_activity from Swift is not really supported yet, so we will see how to use a wrapper to make it a little easier, then dive in deep into C interop to see how all the pieces work.

In this episode we show how you adopt the Unified Logging framework in code by using the OSLog type to define your log subsystems and categories, and how to use os_log to actually log events and messages.

Testing view controllers can sometimes be challenging. In this episode we will write some tests that verify a view controller loads its data properly from the API client. We will add additional tests to verify that a loading indicator is shown.

When refactoring tests, you end up moving critical assertion logic outside of the test method. This can cause our tests to fail in the wrong spot. This becomes worse if multiple methods share test logic. When a test fails you want to know exactly where the failure occurred. By leveraging #file and #line expression literals we can move the failure back to where it should be, within the test method. We will also see how we can continue to use expectations outside of a test instance.

In this episode we implement OHHTTPStubs, a library that can be used to intercept and stub out network calls made with URLSession. Using this technique we can avoid hitting the network for our tests. We can also simulate different responses that are difficult or impractical to simulate in a real request.

In this episode we talk about testing requests against a real API. For this we will build an app called CoinList that leverages the Crypto Compare API to fetch stats about crypto currencies.

In this episode we cover the concept of expectations, which enables us to test asynchronous code, properly timing out and failing a test if the expectation is never fulfilled.

Swift 4 key paths allow us to refer to properties of Swift types in a dynamic way, enabling us to program against them without knowing the exact property in question. In this episode we will see how they are created, how they are used, and see examples of them in action with Key-Value Observing and Autolayout.

The prefetch APIs for UITableView and UICollectionView are great for preemptively loading pages of data, as we saw in episode 315. However, to take full advantage of this API we should also leverage loading or processing data related to the cells we are about to show. One common example of this is fetching an image before the cell comes on screen. In this episode we will implement this with a handy library called Nuke. The result is quite impressive.

Extending our example from episode 309, here we implement automatic tableview paging support by utilizing the UITableViewDatasourcePrefetching protocol. With this protocol, our delegate is notified of upcoming rows the user is about to encounter, and gives us an opportunity to preemptively load data for those rows.

This episodes kicks off a new series on SOLID principles for improving at object-oriented design. Writing better code means writing code that costs less to change, which can be a crucial factor in delivering project successfully. In this series we will see how these principles apply to Swift.

UITableView can support scrolling through many rows of data, however fetching large amounts of remote data can slow down your app, use up too much memory, and bog down your web server. This is all wasteful if users aren‘t ever going to scroll down that far. In this episode you‘ll learn how to perform automatic UITableView pagination using an easy technique.

In this episode we continue with our caching example, this time introducing a new type that will handle the caching for us, as well as wrapping the response type into a new type that will indicate to the view controller if the response was served from the cache or from the network. We end the episode by implementing Equatable so that our store can avoid needless double callbacks if the data has not changed.

In a recent project I leveraged the Codable protocol to save API responses to disk to make the application more responsive (and to have an offline mode). I was happy with the results. In this episode we will add some caching to an existing application, saving JSON responses to the caches directory on the device.

In this episode we extract our camera preview layer into its own view so we can add subviews. We’ll use this to add a flash button control to the UI, which will require us to learn about locking the device and controlling the camera’s "torch".

I got a tip from a subscriber about the method I used to capture the photo in the last episode. Since we're capturing the data using the preset we chose for processing the rectangles, we are bound to that preset when we export to an actual photo. By using AVCapturePhotoOutput, we can have much more control over the format, size, and quality of the resulting image. In addition, since we are leveraging the SDK for capturing the photo, we benefit from things like auto-flash, HDR, auto focus, and the built-in camera shutter sound. (Yay for deleting code!) The end result might not look very different on device, but if you are taking that image somewhere else to do OCR or other processing on it, a higher quality image is important.