I’ve been participating regularly in Advent of Code for the past couple of years. It’s one of the highlights of my holiday season. The puzzles are fun, the stories are appropriately ridiculous, and it’s a neat way for me to keep the cobwebs brushed off some of the things I learned years ago that I don’t regularly use. Every year there are puzzles that take me a couple of minutes to solve, and puzzles that take me hours: I will forever curse the Intcode puzzles from 2019.
I grew up around technology, so I don’t have good memories of when I really “started” getting in to programming. When I was around 14, I picked up HTML and started playing around with that. I learned to make simple graphics in AppleWorks that I’d embed in those pages.
Recently I was thinking about the idea I’d posted on simplifying backwards compatibility in Swift, and was also thinking about some of the principles of kindness that I wrote about in my article on API design.
Every year as new OS and Swift versions are released, the question comes up over and over again: “how do I use this new thing while also supporting older versions?”. While we have a bunch of “availability” tools at our disposal (and I’ll be using them in this post), they always come across as somewhat cumbersome: we need to do inline checks, or we have conditional logic flow that obfuscates the intent of some of our code, and so on.
In the previous post, I shared how you can create custom property wrappers that will work with SwiftUI’s view updating mechanism. I wrote that because I’ve got one other neat property wrapper to share, but understanding how it works requires knowing how to make custom wrappers. Now that I’ve got that out of the way…
As I’ve been working with SwiftUI, I’ve come up with some custom property wrappers that I want to share with you. Most of these are property wrappers that can be easily accomplished using other approaches, but I like these for their expressivity.
A while ago I was playing around with Swift’s string interpolation functionality and come up with something cool I thought I’d share with you.
Over the course of this series, we’ve started with a simple idea and taken it to some pretty fascinating places. The idea we started with is that a network layer can be abstracted out to the idea of “I send this request, and eventually I get a response”.
I was planning on having a few more posts on different loaders you can build using this architecture, but for the sake of “finishing” this series up, I’ve decided to forego a post-per-loader and instead highlight the main points of a few of them.
So far we’ve built two different loaders that handle authentication, and it’s conceivable we’d want to build more to support others. Wouldn’t it be nice if we could encapsulate all of the “authentication” logic into a single loader?