Dependency injection is a 25-dollar term for a 5-cent concept. -James Shore

Dependency Injection is a fancy way of saying that we will provide an object with the object(s) it requires or depends on, to perform its job.

In SwiftUI, a very common way of implementing Dependency Injection is by using environment objects. By injecting an object into our view hierarchy we can abstract the logic and data out of our views and into classes, allowing us to follow the single-responsibility principle, and making our code more testable.

For an example, let’s imagine that we have a UserSettings class with a few properties.

In order to make sure that our View can access the values in our UserSettings object, we can inject it using the .environmentObject() modifier, and reading it using the @EnvironmentObject property wrapper.

In this example, ContentView needs two values found in UserSettings, but we’re creating a much deeper dependency, our view simply won’t work without a full UserSettings object.

This has two distinctive disadvantages:

1. First, every time any of the values in the object changes, the view’s body will be re-evaluated, even if the value changed is not a value that is used by this specific view. In our example, our view’s body will be re-evaluated when soundsEnabled changes, even though it’s not being used in the body. If you happen to be using this method to inject your app’s state, like I have in the past, this object could hold many values that will trigger unnecessary view evaluations throughout your view hierarchy.
2. And second, when previewing a view that has a dependency to an environment object, we will need to inject that environment object to the preview, otherwise it will fail to load. Even worse, any views that display this view as a child will need to receive the environment object in their previews in order to load, even though this requirement is not obvious by looking at their body.

Custom Environment Values

EnvironmentValues, like EnvironmentObjects, are injected into the view hierarchy and propagated to all descendants until they are replaced by a new value. They are the mechanism used by modifiers like .foregroundColor() or .font().

The big difference is that to define a custom environment value you need to provide a default value. It requires a bit more boilerplate, but it has it’s advantages.

To create your own environment value you need to create an environment key and extend EnvironmentValues; you can then insert the value into the hierarchy using the .environment() modifier.

Value Injection with Environment Values

By reading from a specific environment value, our view’s body will only be re-evaluated when that value changes. And because EnvironmentValues always have a defaultValue, these views can be utilized without having to inject anything, which means you don’t need to modify your previews.

An important thing to note is that @Environment properties are read-only. You may have noticed that I injected the UserSettings in my SettingsProvider, that’s because any views that need to modify the values, like a SettingsView would in this example, will still need to read the whole object.

More than just User Settings

So far I’ve used simple values as an example, but this technique can be useful when populating our app’s views with all kinds of data.

Let’s say we’re building an app that displays the user’s transactions in different ways and subsets throughout the app.

If we were using CoreData, we could use a @FetchRequest with the relevant query in each view; if we were fetching data from the server we could fetch the required transactions from the network on each view.

My preferred alternative, however, is to inject the transactions at a very high level in the hierarchy, and read that value in any view that will display them.

Fetching the data is an exercise left to the reader, but once the transactions are fetched, we can inject them into the environment using the .environment modifier.

Any views that want to display the values in the userTransactions array can read that value from the environment instead of having to fetch any values by itself.

This makes our views a lot simpler, and the logic for fetching the transactions is not only removed from the View struct, it’s in a different node of the view hierarchy altogether.

Conclusion

By using value injection, views that require read-only access to these values will only be refreshed when those specific values change.

Because environment values provide a default value, we no longer need to inject dependencies to the previews of views that use them.

Dependency Injection using environment objects still has its place in views that require write access to the properties of the object.

Continue Reading

In my previous article, I explored creating a responder chain using EnvironmentValues, allowing us to follow a “fire and forget” approach to actions in order to make our views more self-contained.

Building a Responder Chain Using the SwiftUI View Hierarchy

Environment Values as an Alternative to Dependency Injection in SwiftUI was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past 10 years I’ve spent a lot of time answering questions in StackOverflow, and a question I see very often is a flavor of:

How do I trigger an event in class A from a function in class B?

This may seem like a simple question for a seasoned developer, after all there are multiple ways we can go about this, we can use delegates, callbacks, notifications, etc., but it’s still a situation that we encounter often, and the farther apart that the two objects are, the more complex it is to communicate between them.

Part of the challenge is to implement this in a way that is scalable and maintainable. You could create an app where every event is sent via NotificationCenter, but you’ll be knocking your head on your desk soon enough.

Enter Responder Chains

A responder chain is a design pattern where responder objects form a “chain”. Events are generated in one of the “links” or “nodes” of the chain, and the node determines if it can handle the event or not. If it cannot handle the event, the event is sent to the next node in the chain. This process continues until a node can handle the event, or the end of the chain is reached.

An object-delegate relationship is a trivial example of this pattern. The object creates an event that it can’t handle itself, so the event is sent to the next node in the chain, which is the delegate. A more complex example is the UIResponder chain.

Explicit responder chains are not super common in iOS development, probably because most of the core building blocks of UIKit, like UIViewController and its subclasses, make it really easy to build without one.

With SwiftUI, however, every object is linked to the root view via the View Hierarchy, which means that the overall structure we need to build a responder chain is already in place, all we need to add are the responders and the events.

The SwiftUI View Hierarchy

An interesting property of the SwiftUI View Hierarchy is that some of its values, like the Environment and EnvironmentObjects, are passed down the hierarchy until they are replaced. We can use this, especially the Environment, to register our responders.

To make things a little bit more visual, this is the hierarchy that would be generated from this simple view. Notice how modifiers, likeforegroundColor, create a node that is a parent to the view they are modifying.

SwiftUI Environment

Environment values can seem intimidating at first because they are often used for system actions, like dismissing a sheet, and adding our own requires extending a system type, EnvironmentValues. It’s perfectly safe to do so, though, and since they can be any kind of type, their Type can be a closure.

With this value in place, any view can read our custom environment value, and also set a new value to it. Since the value we added is a closure, our view can also call this closure.

Creating a Responder

Earlier we mentioned that a responder has the responsibility to determine if it can handle an event or not. Our views will register themselves as responders by registering their own eventClosure into the environment.

Any child views that call eventClosure will be triggering our view’s handler, as long as an intermediate view hasn’t replaced it. If our view determines that it cannot handle the event, it can use the closure it read from the environment, which will come from a parent responder, to allow the event to continue through the chain.

Since this will be a common pattern, we’ll create a ViewModifier that will encapsulate this funcionality.

Our new handler closure has a return type of Any? because that’s how we’re going to determine if the event was handled or not. If the returned value is nil, the event will be considered handled, if the returned value is anything else, that value will be sent up the chain.

Views can now register themselves as responders by calling our modifier and passing a handler closure.

Sending an Event

Triggering an event is a lot simpler, all we need to do is to read the eventClosure from the environment and call it with any value.

A simple but complete example would look like this:

An important detail is that for a responder to be able to receive an event, the source of the event has to be a direct descendant of the responder.

In practice this means that our responders will usually be registered at the root node of each feature or screen.

Scalable and Maintainable

One of the more common ways of triggering events from a child view in SwiftUI is passing a closure as an argument, like you would with a Button. When the view that is responsible from calling that closure gets deeper in the view hierarchy, this closure has to be carried by multiple intermediate views.

Our approach is much more maintainable because only the responder and trigger views need to know about the event. This means that our hierarchy can be modified without having to “carry” this closure through multiple levels.

Thanks to this, our approach is also scalable, and creating an event is as easy as defining a new type. No need to add a new environment value for every event.

Creating a Framework

Following this pattern I created the framework HierarchyResponder, designed to handle events and errors.

This framework takes this concept and expands it by adding specific modifiers to receive, handle, or transform an Event or Error, as well as catching errors.

1. Receiving an Event or Error lets you decide if the event was handled or not.
2. Handling the Event or Error means it will be consumed, no other options.
3. The transforming modifiers let you replace the received Event or Error with a different value.

Another feature is that each modifier has a generic version with a Type parameter that will automatically filter any values that don’t match the type you supplied.

Building a Responder Chain Using the SwiftUI View Hierarchy was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: When I started implementing this animation I thought about implementing it as a refresh control, but it quickly started feeling like work, so I decided to just focus on the animation. Anything else is left as an exercise to the reader.

Introduction

Just like my first article, Recreating Instagram’s Page Control, in this article I will recreate a UI component from an app, in this case it’s Tweetbot’s Refresh Bar.

This control is pretty simple, it’s a bar that fills as you drag down, and once you reach a certain distance, it starts bouncing left and right.

Download the Playground and follow along. It has a page for each step.

Step 1: Class Setup

This step is really simple, we’ll create a UIView subclass with a single UIView property that will be used as the fill.

We’ll use two existing properties of UIView to style our control, backgroundColor for the background (shocker!), and tintColor for the fill. That way we won’t need to add any extra properties, but we will need to override tintColorDidChange() to update the background color of our fillView.

Finally, we’ll override intrinsicContentSize and return the size we want our control to have. If you’re not familiar with what intrinsicContentSize does, you can read about it in this article I wrote.

Step 2: Progress Fill

Our view will have two states, the first one will be when it fills. Since the bar will fill as the user drags down, we’ll add an associated value to store that progress.

The second state will be when the bar is animating. To handle these two states we’ll create the following enum.

Next we’ll implement layoutSubviews, and use it to round the corners of our views, then we’ll call our updateFrames() function.

In our updateFrames(), first we’ll make sure that state is .progress, otherwise we exit early. Then we’ll use lerp to calculate the width of our fill view, and set it’s frame. The lerp function is found in my CGMath library, you can learn more about it in the readme.

Step 3: Animation

To start implementing the animation we’ll need a couple of constants, the width of the bar and the duration of each step of the animation.

We’ll split the animation in two very similar steps, each step will use UIView.animate to set the frame of our fill view, and on completion, if state is still .loading, we’ll call the other step, this will cause the animation to loop endlessly.

Now, in state.didSet we’ll call animateFirstStep() if state is .loading. If state is not .loading, we’ll check if it previously was, and if that’s the case, we’ll animate the call to updateFrames().

Step 4: Final Touches

To get it production-ready, we’ll turn loadingWidth and duration from private constants to variables.

We’ll make alsoRefreshBar.State conform to Equatable, and use that to exit early if state is set to the same value.

And done!

This animated refresh control was quite easy to implement, the trickier part would probably be to integrate it into a scroll view, but as I mentioned before, that is an exercise that will be left to the reader.

Stay tuned for my next article about Instagram’s story loading animation!

Introduction

The Instagram app has a lot of nice UI details, one the always intrigued me is the page control, which shows a maximum of seven dots, and scrolls as you scroll between photos. As you can see in the gif below, it has three central dots that are full size, and up to two on each side that are smaller the further they are from the center. As you scroll through the pages, the dots scroll and change in size.

For this article I recreated that page control, and I’ll show you step by step how I did it. I strongly recommend you download the playground to follow along, since I won’t post all the code here and you might miss something.

The Playground contains several numerated pages, each page corresponds to the step with the same number in this article.

It also contains, in the Sources folder, a copy of my library CGMath, which extends CGGeometry types like CGRect, CGSize, etc., as well as FloatingPoint and Comparable, with some properties and methods useful for animations.

If you want to use it and have no interest in learning how it was created, you can install it with Cocoapods. More info here.

Step 1: Class Setup

We’ll start by creating a UIView subclass called PageControl, and set some properties. We’ll also override draw(_ rect: CGRect), since that’s what we’ll use to draw the dots.

Step 2: Draw Dots

To draw the dots we’ll need to calculate their position, once we have it we can use UIBezierPath to draw the dots with the correct color.

You might notice that the dots are not centered, instead they are stuck to the left of the view. We’ll fix that later.

Step 3: Update Dots

Since we added a property observer that calls setNeedsDisplay() to all variables, whenever any of those are changed, our view will be redrawn.

To trigger that, we’ll use the UIScrollViewDelegate to be notified whenever the scroll view ends a movement, and update our PageControl then.

That should do it, now our PageControl will update whenever the scroll view stops scrolling.

Step 4: Intrinsic Content Size

If you are not familiar with the intrinsicContentSize property of UIView, you can read about it in this article I wrote, but the gist of it is that the intrinsicContentSize property of a view is the size the view wants to be in order to show all of it’s content and no more.

UIView subclasses are in charge or returning their desired size, or .zero if that’s not possible, but we can easily calculate the required size for our view.

The height will be simply the size of the dot, the width will be the number of dots times their size, plus one less than the number of dots times the spacing. If you don’t understand why it’s one less for the spacing, count the spaces between your fingers.

To make sure our dots are centered, even if the view has a width different from it’s intrinsicContentSize (which would be the result of using a width constraint on the view), we’ll calculate a horizontalOffset, which is simply half the difference between the actual size and the desired size.

Finally, we’ll call invalidateIntrinsicContentSize() on pages.didSet, that way, whenever the number of pages changes, the size will be recalculated and the view’s size will be updated.

Step 5: Scrolling Dots

You might be thinking that this is pretty easy, and so far it has been, but this is the part when things get tricky, so hold on to your seat.

To scroll the dots, we’ll need to keep track of which central dot is highlighted, and how much we’ve scrolled the dots. We’ll use these two variables.

Now, in selectedPage.didSet, we’ll update the value of those variables like this.

This might be hard to understand at a glance, what it does is to calculate where selectedPage lands after being modified by the pageOffset, if it’s between 0 and 2, 0 being the left dot, 1 being the central dot, and 2 being the right dot, we’ll update centerOffset. If it falls outside those values, we’ll update pageOffset instead. That way selectedPage — pageOffset will fall in the range we want and the selected page will always be within the central dots.

Now we have to update the drawing code. We’ll start by modifying the way we calculate the horizontalOffset, for each offset we have we’ll move all the dots to the left the length of one dot and one spacing. The reason we add a 2 is that we have two dots on the left of the central three. If we’re on the leftmost page, with a pageOffset of 0, we’ll still want to move the dots to the right to make sure that the central dots are centered.

The other change you’ll notice is the scale variable, which will calculate the scale for each of the page dots. Remember that the central three are full size, and as they go farther away, they get smaller.

1 + pageOffset will tell us what is the index that is currently as the middle dot, we’ll use that to calculate the “distance” between that dot and our current page. If the distance is 0 or 1, we’ll return a scale of 1, as the distance grows bigger, we’ll return smaller numbers until we reach 0.

The 1 we add to pageOffset might seem like it comes out of nowhere, but it makes sense once you think that pageOffset tells us which page is currently on the left, central dot, if we add 1 to that, we get the index of the page in the center dot.

Finally, in intrinsicContentSize(), we’ll limit the number of pages to show to a maximum of seven.

Step 6: Animate Scroll

If you run the playground you’ll notice that while it’s easy to tell when the highlighted dot moves between the central dots, once it moves to one of the dots on the sides, it’s hard or impossible to tell that something happened.

To fix this, we’ll implement a small animation, just like Instagram does.

It’s totally possible to implement this animation using the current drawing method, but UIKit already provides us with some handy methods to animate UIViews, so we’ll switch our code to use that instead and save ourselves some time.

First we’ll create a dotViews property to hold our views. Whenever it changes we’ll remove the views in the old value and add the views in the new one, then we’ll update the colors and positions (we’ll look at these functions in a minute).

On pages.didSet, we’ll set the dotViews value to a number of views equal to the number of pages (CircularView is a UIView subclass that will round it’s corners automatically, you can find it’s declaration in the playground).

Next we’ll get rid of draw(_ rect: CGRect) and replace it with updateColors() and updatePositions(). Update colors is very straightforward:

updatePositions() is pretty much the same as draw(_ rect: CGRect), with the difference that instead of drawing each dot with the calculated values, we’ll update the corresponding view.

The final step is animating the change in pageOffset.didSet, since the that offset is what dictates when the dots should scroll. We can use UIView.animate to animate the position change.

Note: The animation block is wrapped inside an asyncAfter call to add a one frame delay to this animation, that way the user will see the dot change in color and then all the dots move. It makes it easier to see what’s happening. Theres an UIView.animate method with a delay parameter, but that wasn’t working for me on the Playground.

Step 7: Flexibility

In order to copy the way the Instagram page control works, we’ve hard coded some values, like the max number of dots, and the number of central dots. That is good for a prototype, but not good for production code, so we’ll change that. We’ll start by adding properties for those two things.

We’ll require that the value for these two properties is odd because our design and our code relies on one dot being centered in the view at all times, which can’t happen if the number of total or central dots is even.

In selectedPage.didSet we’ll change 0...2 to 0..<centerDots. When centerDots was hardcoded to 3, those two were equivalents.

We’ll modify updatePositions() by removing the constants we used before. Instead of adding 2 to -pageOffset, we'll calculate the amount of side pages and use that instead.

The other thing we’ll change is the way we calculate the scale. After calculating the distance, we’ll return a scale of 0 if the distance from the center dot is greater than half the max number of dots. We’ll then subtract the number of dots to the left and right of the central dot from the distance we already had, and then clamp the result to a value between 0 and 3. Using that new value we’ll get a value from an array of values we defined.

Finally, we’ll update intrinsicContentSize to use maxDots instead of the hard coded value we were using.

One unexpected upside of these last changes is that we can now fully replicate Instagram’s page control functionality. The one difference our controls had was that when Instagram’s page control had five pages or less, it would show all full dots and not scroll, while ours would always show up to three big dots and scroll.

Now we can set maxDots and centerDots to 5 whenever the number of pages is less or equal to 5, and the other values for whenever it’s greater. We won’t implement that by default because I like the scrolling dots.

Step 8: Final Touches

To wrap it up and make it production ready we’ll add some guards to make sure that the control only updates when the values change. For example, if the number of pages was set to 5, and you set it to 5 again, there’s no reason to update the colors and positions of the views.

We’ll also add some checks to make sure valid values are provided for all variables. For example, you can’t have less than 0 pages.

Another change we’ll make is to change dotSize and spacing to non private variables to add more customization options to our control. We’ll also need to add some property observers to update our control when those values are changed.

Aaaand we’re done!

That’s it, we’ve recreated Instagram’s page control in a class of just 127 lines, and other than the scrolling of the dots, it was pretty straightforward. We started using CoreGraphics to draw our dots, but halfway we realized that UIViews were better suited to do the job. Since our logic was solid and didn’t depend heavily on CoreGraphics, the switch was simple.

If you want your control to be updated as the user is scrolling, like Instagram does, you can override scrollViewDidScroll instead of scrollViewDidEndDecelerating. I didn’t do it in the example because it caused lag in the Playground, I don’t know if it’s an issue with my computer or playgrounds, but it shouldn’t be an issue on the full simulator or on the device.

You can install this in your project with Cocoapods. More information here.

TL;DR: I automated the lights in my apartment. There’s a video at the end if you don’t feel like reading.

For the longest time I’ve had a big interest in home automation, it’s been a dream of mine to have a smart home that reacts to my needs with minimum input from my part.

In 2012 I saw the LIFX Kickstarter campaign and backed it for eight smart light bulbs. Their premise was simple, light bulbs that connect to your WiFi and you control them with your phone. Six years ago I was still living at my mom’s house, which is rather big, so we distributed the light bulbs around the house and used them scarcely.

I moved out of my mom’s shortly after but it wasn’t until the end of 2016 that I moved into an apartment all by myself, and this gave me the perfect opportunity to start developing the system I have had in mind for a while.

The main goal I set for my automated home system was simple: never to have to touch a light switch again.

A little over a year ago I pretty much reached that goal. I can’t say I haven’t touched a light switch in my apartment since, because sometimes the bulbs get disconnected from the network and the only way to reconnect them is to turn the switch off and back on, but I haven’t used them to control the lights, which was the essence of my goal.

For the past year I’ve slowly improved the functionality based on my experience with the system, there’s been a lot of trial and error, and some instances where I was left with a system with a few awkward behaviors that I had to work around for a couple of days, but it works really well now.

Lately I’ve read a lot about integrating smart devices — light bulbs, garage doors, thermostats, cameras, etc — with HomeKit or Google Home, but usually what they achieve is to change the input device from a physical switch to a digital one, and in many cases it’s slower to use the digital switch, even if you use Siri, Google Home or Alexa.

Another thing to note is that not everything can be fully automated, for example, if you set the garage door to open whenever you enter the garage, it might open in the middle of the night when you go find a tool, which is undesirable and could be even dangerous.

Lights are special in the sense that the way we use them is pretty straight forward. When we enter a room, we turn the lights on, when we leave a room or go to sleep, we turn them off.

That’s one of the main reasons I chose to make my lights smart, the desired behavior is predictable, the other main reason is that I had the LIFX bulbs to play around with, and finding motion sensors was easy enough.

Hopefully by now you’re curious about all the things the light system in my apartment can do, so here’s a list of it’s main features. You will also find a video below where you can see them in action.

Automatic Light Switching

This is the main feature. I have a motion sensor in each of the areas of my apartment, and whenever I move to a different area, the sensor is triggered and the light is turned on and other areas are turned off.

One neat thing I implemented is something I call “pre-heating”. In my apartment, four rooms — the living room, bedroom, bathroom and TV room — are connected to the same hallway, so it’s a given that whenever I’m in that hallway, I’m going to enter one of those four rooms (there isn’t a lot to do in the hallway).

Whenever the hallway motion sensor is triggered, all those rooms enter “pre-heat” mode, where their lights are turned on at 50% brightness, and once the motion sensor in one of the rooms is triggered, the room is fully turned on.

This is pretty useful because it takes around two seconds from the time the motion sensor detects motion to the command being executed by the lights, so this helps you avoid entering a dark room at night.

Smart Color

Another one of the main features is the smart color. The system keeps track of the time of the day. I have 5 “times of day” setup: Morning, Work, Day, Evening and Night. Each time of the day has a set of rules for each room, which dictate the temperature/color and brightness of the light.

For example, during work hours the lights in my living room/office are bright and white, which is better for working, but late at night, the lights are dim and warm, so if you get up in the middle of the night for a glass of water, you won’t be blinded by bright lights.

This set up is not system-wide, each house has it’s own setup configure to the owner’s needs, though currently my apartment is the only one in the system.

Companion iOS App

I’ve been an iOS developer for a long time, so obviously I built an app for my phone to control the lights in the few situations that require manual input.

It’s a rather simple app that allows me to see if the lights are on/off, which rooms are active, and toggle any of the rooms and light scenes.

This app works remotely, so I can control my lights from far away, if required.

Location Triggers

The iOS app also tracks my location in the background and manages the lights whenever I leave or arrive to my apartment. When I get within 50 meters of my apartment, the lights are turned on, and when I get farther than 50 meters away, the lights are turned off.

The result is that lights are on by the time I open the door and I don’t have to worry about turning them off when I leave.

Scenes

If you looked closely at the screenshot you might have guessed what scenes are, they are basically presets that change the lights in a single room, overriding the current rules.

The one I use the most is the “Movie” scene, which dims the lights in my TV room to make it more comfortable to watch a movie, a TV show or play video games. The name “Movie, TV Show or Video Games” was too long and I couldn’t find a good icon for it.

Siri and HomeKit

HomeKit is designed to control individual devices, you can group them and add some automation rules, but it wasn’t enough for me, so I configured HomeKit (and thereby Siri) to work in a very similar way to the iOS app I built.

Each “light” in HomeKit is actually a room or a scene, so if I tell Siri to turn on the living room, it will relay that information to my system and my system will handle it by enabling that room and setting the correct lighting.

The system works really well with minimal input, but there’s currently no way for my system to figure out when I’m going to bed (yet), so I set up a “Good Night” scene in HomeKit, so at night I can say “Hey Siri… Good night”, and Siri will turn off the lights.

If you’re more technically inclined and you are wondering how this works, I set up Homebridge in a Raspberry Pi and I used the HTTP plugin to communicate with my server.

IFTTT Notifications

Another neat thing I added is an alert endpoint. I connected this with IFTTT to receive different notifications on my apartment.

I currently have two notifications setup, whenever the International Space Station flies above my apartment all the lights flash blue three times, and whenever an Uber is arriving to pick me up they flash orange.

There are a more things I’ve implemented over this past year, and I have a few more in my to do list, but this should give you a good idea of how the whole thing works.

In the video below you can see most of the features in action, and if you want to know more you can contact me with the links at the bottom.

Want to learn more?

I can talk about this for hours so if you want to know more details, feel free to contact me on twitter. You can also find my email and other social media profiles on my website.

You’d be hard-pressed to find somebody who doesn’t like to travel. I’m not the exception. Thanks to my parents I had the opportunity to travel quite a bit when I was younger. It was living in Vancouver, however, what sparked my interest in living in other cities. I had visited a lot of places, but before Vancouver I had never had the chance to experience actually living outside of Mexico City.

During a visit to the Savvy Apps headquarters in Reston, Va., I brought this up to my boss, Ken. His reply was that as long as the quality of my work didn’t decrease, and I adjusted my work hours to sync as much as possible with the work hours in the office, it didn’t matter where I was working from. I can’t overstate how grateful I am with Ken and Savvy Apps for this unique opportunity.

I started planning the trip when I returned to Mexico. My goal was to spend less than six months in Mexico City during 2016. My initial plan consisted of two, three-month trips around Europe, since three months is the longest you can stay in Europe with a Mexican passport. After learning that the UK doesn’t share immigration laws with the rest of Europe, my plan changed into a single, five-month trip with three months in Europe and two in the UK. This would also save me some money on airfare.

The next step was picking the five cities I’d be staying in. Five cities might sound like a small number for a five-month trip, but it makes a lot more sense when you remember that I’d still be working 40-hour weeks. The five cities I picked were Paris, Sheffield, Edinburgh, Milano and Lisboa.

I’m often asked how I picked where I’d be staying. I didn’t have a criteria other than a general idea of countries I wanted to visit, and in many cases it boiled down to Airbnb availability. Sheffield seems like the odd one out of the list because even though it’s England’s fourth largest city, it doesn’t have a lot going on for it. What Sheffield does have is a a couple of universities and a lot of students, one of whom happened to be one of my best friends, who I hadn’t seen in seven months.

Packing took a long time, but in the end I managed to pack everything I would need into a 22kg suitcase and a backpack. I knew I’d be using public transit often, and this setup allowed me to have one hand free while I pulled my suitcase with the other. I put all my important stuff into the backpack and all my clothes, shoes and other stuff in the suitcase. Having everything I’d need for five months in just two bags was a little bit surreal and really put things into perspective.

I arrived at Paris after a 12-hour flight. Unfortunately, je ne parle pas français. I tried using Duolingo a few times before the trip, but I didn’t put enough time into it. It didn’t help that the course is not designed to teach you useful stuff right away; it takes it’s time with the basics. Even if I had used it consistently, though, I don’t know if it would’ve helped a lot since Parisians are notoriously hard to understand. Thankfully, many spoke English, especially the younger people. Reading was a lot easier as a lot of French words are very similar to words in English or Spanish. It was a similar situation in Italy and Portugal, the two other countries where English isn’t the native language.

I used Airbnb for all my accommodations. My budget was $1500/month, and I found very nice apartments in every city I stayed in. I managed to stay under budget outside of the UK, and went over it in the UK. It might sound like an exaggeration but I don’t think I could have made this trip without Airbnb. It gave me the combination of privacy, comfort and reliable WiFi that I couldn’t have gotten from a hotel or a hostel. The only downside I found is that you have to pay when you book, and it’s best to book a few months in advance to find good places, so I was out several thousand dollars a few months before I even started my tip.

Making sure I could do my job was a top priority for me. There are two main things I need to work, one is my Mac and the other is an internet connection. I knew I’d have WiFi in every apartment I’d be staying in, but in case it failed I also bought a SIM card with data in every country I visited.

Ever since I moved to Vancouver over three years ago, I’ve been buying my iPhones, unlocked, directly from Apple. This allowed me to use any SIM I wanted and avoid ridiculous roaming charges. An internet connection on my phone was also very useful to navigate, find places to eat, and translate the things I didn’t understand. The Google Translate app, which can translate directly from the camera, proved to be very useful.

I usually paid about 20 euros for 2 or 3 GB per month, except in the UK, where I paid 20 pounds for an insane 12 GB per month. Apparently mobile internet in the UK is quite cheap to make up for the fact that everything else is very expensive.

Working in Europe during American work hours was confusing at first, but by the end I actually liked it. I usually started at 1 or 2 p.m., depending on the time zone. Sometimes I worked my eight hours straight and went for a late dinner afterwards; sometimes I took a break to get something to eat; and sometimes I’d go out at night after work. This meant I had the mornings free, which turned out alright because most museums and galleries close at around 6. I also had weekends free, of course, and during those days I could go to places that required more time than I could have in the morning of a weekday.

I’m not a terribly extroverted person — I probably wouldn’t be a good programmer if I was — and being in a city where I don’t speak the language just makes meeting people more complicated. What I found to be very effective was to go to Couchsurfing events. Even though I was not looking to host or be hosted, a lot of people there are travelers and most of them speak English. I ended up making a lot of friends and as a side effect the number of posts in my Facebook feed that are in a language I can’t understand has increased substantially.

One of the first things people ask you when they learn you are travelling is whether you are doing it for business or pleasure. My situation was not very common. I only met one other person, a programmer as well, who was doing the same thing. It always took some time to explain that I was travelling for pleasure and that my job allowed me to work remotely, “you’re very lucky to be able to do that” was the most common response.

In the end I spent more than a month in four of the cities I visited. Saying I lived in those cities feels like a bit of a stretch but I definitely experienced them in a way that most travellers don’t. They say that travel broadens the mind, and after all the different experiences I had during these few months, which I wouldn’t have had any other way, I think I can vouch for that.

I landed in Mexico City a few weeks ago. Overall I spent 20 weeks away, lived in five cities and visited more than 16 cities in seven countries with over seven different official languages, used three currencies, took 10 flights and 26 trains, and went through one Brexit.

You can see some of the photos I took in my Instagram.