Swift has a lot to offer, but it isn't always obvious how to get the most out of the language. I often see developers compromise the APIs they build by using stringly typed code while Swift provides features that make stringly typed code unnecessary. In this series, I show you how a handful of simple patterns and techniques can help you build APIs that are type-safe, elegant, and intuitive to use.

In this episode, we focus on the analytics API itself. We define a single entry point for analytics and remove some of the string literals at the call site. The resulting API is surprisingly small, intuitive to use, and easy to extend.

We still use string literals to define the properties of an event. That is something I would like to change in this episode. The Journey enum defines the list of events the API supports. We take a similar approach for the properties of an event.

We drastically improved the analytics code of the NotesViewModel class in the past few episodes, but we still use a few string literals at the call site. That is something we address in this episode.

The analytics library we are building is tightly coupled to the GoogleAnalyticsClient class. Tight coupling negatively impacts testability and it is often an indication that there is room for improvement. In this episode, we decouple the analytics library from the GoogleAnalyticsClient class by taking a protocol-oriented approach. Let me show you how that works.

The analytics library we built in this series is easy to use thanks to its intuitive API. The call site is no longer littered with string literals and the API the analytics library exposes is type safe. We don't stop here, though. I promised you that the analytics library would be testable. Let's focus on that aspect in the next few episodes.

In the previous episode, we wrote the first unit test for the analytics library we built. In this episode, we write a few more unit tests and take advantage of the compiler to find gaps in the test suite.

In the previous episodes, we used code coverage to help us write unit tests for the analytics library we built. This worked fine, but code coverage isn't perfect. Code coverage inspects which lines of code are executed when the test suite is run. The result may be misleading or incorrect at times. In this episode, we take a look at an important shortcoming of code coverage.

In the previous episodes, we unit tested the analytics library we built. The integration with the Google SDK is an aspect of the implementation we haven't talked about in detail. We shouldn't unit test the Google SDK itself, but can we unit test the integration with the project? That is the question we focus on in this episode.

In the previous episode, we used the adapter pattern to make the integration of the project with the Google SDK testable. In this episode, we put the theory to the test. We write unit tests for the GoogleAnalyticsService class to validate the integration of the project with the Google SDK.