🎉 End-of-year Sale! Save 25% when you subscribe today.

Designing Dependencies: Core Location

Episode #113 • Aug 17, 2020 • Subscriber-Only

Now that we’ve tackled two dependencies of varying complexity we are ready to handle our most complicated dependency yet: Core Location. We will see what it means to control a dependency that communicates with a delegate and captures a complex state machine with many potential flows.

Previous episode
Designing Dependencies: Core Location
Next episode
Locked

Unlock This Episode

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

Sign in with GitHub

Introduction

Fully controlling the dependency in a type we own allowed us to reimagine and modernize its API using Combine, a framework that didn’t even exist when NWPathMonitor was first introduced. We were able to clean up a lot of messy logic in our view model around starting and canceling the monitor by baking it into the publisher’s lifecycle. And what we’re seeing here is that this style of dependency is even more flexible in allowing us to evolve APIs. Had we merely slapped a protocol onto NWPathMonitor to control it, we may have not been so bold as to rethink its design.

We now have a weather app that is perfectly useful for the inhabitants of New York City. 😂 It’d be nice for it to be useful to folks in any location, though. So let’s introduce yet another dependency, Core Location, so that we can fetch a user’s local weather, instead. Core Location is our most complex dependency yet. It employs manager objects and delegates to handle a complex state machine of events out in the real world.

Updating the weather client to search locations


References

Downloads

Get started with our free plan

Our free plan includes 1 subscriber-only episode of your choice, access to 64 free episodes with transcripts and code samples, and weekly updates from our newsletter.

View plans and pricing