Stephen OK, so that concludes our “soft” landing into the Composable Architecture, though we did end up exploring quite a few advanced topics already. We implemented a few side effects, including a network request and a timer, and we already came face-to-face with the gnarly beast known as “dependencies.” They can wreak havoc on your code, and they made it very difficult for us to unit test our application, and so we saw what it takes to control our dependencies rather than letting them control us.

And so we are now going to move on to explore Apple’s Scrumdinger application, but we also want all of our viewers to know that the Composable Architecture repo comes with lots of demos and case studies that explore other kinds of problems one faces day-to-day. We highly encourage our viewers to check out those examples to get even more comfortable with the foundations of the library.

We are going to start by giving a tour of the Scrumdinger application so that everyone knows what is we will be building.

So, let’s get started.

The Scrumdinger application is a full blown tutorial that Apple released. We can open it in Safari:

From the first page of the tutorial we learn:

Note

This module guides you through the development of Scrumdinger, an iOS app that helps users manage their daily scrums.

And if we look at the table of contents we will see that this demo encompasses an impressive number of topics. It’s got views, navigation, state management, persistence, drawing and even recording audio.

We have the final project already downloaded and opened. Let’s run it in the simulator to see what all it can do.

The app launches into an empty list view. Right now there is only one action we can take, and that’s to tap the “+” button for adding a new daily scrum meeting.

Tapping the “+” button brings up a sheet with a form that allows us to edit the details of the meeting. We can set a title, duration, theme, and we can add attendees by name. Further we have the choice of dismissing the sheet without adding the meeting, or we can tap “Add” to actually add it.

Let’s go ahead and a new meeting for “Point-Free”, and we will add “Brandon” and “Stephen” to the attendees list…

Now one weird thing about this attendee interface is that you have to actually hit the blue “+” button to add the attendee. This means if we tapped “Add” in the top-right, Stephen wouldn’t actually be an attendee. Also the previous attendees aren’t editable at all. These are minor user experience annoyances, and we’re going to take the time to fix some of them as we recreate this application.

Now let’s tap the “Add” button, and we will see the sheet dismiss and the new meeting was added to the of the list.

The only other action we can take on this screen is to tap a row to drill-down to the meeting detail. So, let’s go to the “Point-Free” meeting.

There are a few actions we can take on the screen.

First, we can hit “Edit” to bring up a sheet with a form that allows us to edit any of the details of the meeting. One interesting thing about this modal is that we can make changes to the data and then hit cancel, and we will see those changes were not saved. This must mean this screen manages a bit of scratch data so that it can make changes without changing the original source of truth.

Another action we can take on the detail screen is to start the meeting. That will drill down to a new screen with a timer going and letting you know whose turn it is to give their update. The screen will even record the audio from your meeting and transcribe it so that it can be referenced at a later time. That’s what the history section down below is all about. We just need to grant permission.

Each speaker gets equal time of the total minutes for their update. So once half the seconds elapses we should hear a ding, and then we see that “Stephen” is now the speaker.

To end the meeting we can manually tap the back button in the top-left:

OK, and we do indeed see a new meeting as been added to the history.

Let’s tap the history row to drill down to see what’s inside, and we see a transcript of what was said during the meeting.

So, we’ve now created a daily scrum and recorded a meeting in the scrum. Let’s close the app in the simulator and then relaunch the application:

We will see that our scrum is already in the list, so the app must have some mechanism for persisting data to disk and loading it on launch. We can even drill down to the scrum to see that the history was also persisted.

OK, that is the entirety of the app. It’s only 4 screens: the root list, the add/edit screen, the detail screen, and the recording screen. So, it seems somewhat simple, but there are some really interesting interactions happening.

• There’s the interaction where the edit screens works on a scratch piece of data and the changes are only committed if the “Save” button is tapped.

• There is complex logic around navigation, such as when the meeting timer ends we should pop the screen off the stack.

• The application uses a complex Apple framework in order to live transcribe audio to text.

• And finally, the application persists the data to disk.

This is just a really fun application, and I think perfectly demonstrates a lot of real world problems that one must solve when building applications.