Modern SwiftUI: Effects, Part 1

Episode #217 • Dec 19, 2022 • Subscriber-Only

After a brief digression to explore the performance and ergonomics of identified collections, we dive into the messy world of side effects by implementing the “record meeting” screen. We’ll start with the timer, which has surprisingly nuanced logic.

Effects, Part 1
Introduction
00:05
Identified arrays
02:04
The record meeting view
04:56
Timers
12:06
Next time: speech recognition
36:43

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

Introduction

And this model binding logic is getting a little complex, but the amazing thing is that because it’s all integrated together at the model level, it’s all 100% testable. We can write tests that go through an entire user flow and prove that the features interacted with each other in the correct way. And then if we ever accidentally break the binding logic we will get instant visibility into it.

That will all come later, so let’s keep moving forward. We are down to the very last piece of functionality in the detail screen, and that’s drilling down to start a new meeting, and that feature is by far the most complex of the entire application because it involves effects.

It manages a timer for counting down the meeting time, and it manages a speech recognizer for transcribing live audio while the meeting is taking place. There’s also another effect in the app. Way back at the root we need to handle persistence of the data for saving and loading to disk.

That will be the focus of this episode, but before doing any of that, let’s have a little fun by making our domain modeling even more concise than it is now. A moment ago we came across two thorny situations that made it clear that our simple array of standups is not pulling its weight. There are many times we need to deal standup values by their ids, and forces us to scan the entire array to find a particular standup.

SwiftUI has already learned this lesson because many of its APIs require you provide Identifiable data, and in fact many of our core domain data types already conform to that protocol. So, wouldn’t it be nice if you could look up a value by its id, or remove a value by its id instead of linearly scanning the entire collection?

Well, it is possible, and it is all thanks to another library that we open sourced a year and a half ago. It’s called IdentifiedArray, and it’s a collection type that is specifically tuned for dealing with Identifiable elements. It has all of the standard collection APIs, but also comes with some enhanced APIs that allow for performant, safe and ergonomic access to elements via their id.

So, let’s bring in that library and see how things improve.

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in

Exercises

  1. Refactor RecordMeetingModel.speakerIndex to be derived from elapsedSeconds, instead.

  2. The original Scrumdinger application plays a sound when it advances to the next speaker, bring this sound into Standups and insert this logic into the record meeting view.

References

Getting started with Scrumdinger

Apple

Learn the essentials of iOS app development by building a fully functional app using SwiftUI.

Identified Collections

Brandon Williams & Stephen Celis • Sunday Jul 11, 2021

Identified Collections is our open source library that provides an ergonomic, performant way to manage collections of identifiable data, and fits in perfectly with SwiftUI.

SwiftUI Navigation

Brandon Williams & Stephen Celis • Tuesday Sep 7, 2021

A library we open sourced. Tools for making SwiftUI navigation simpler, more ergonomic and more precise.

Packages authored by Point-Free

Swift Package Index

These packages are available as a package collection, usable in Xcode 13 or the Swift Package Manager 5.5.

Downloads