Posts tagged "swift"
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.
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?
The last post covered the basics of an OAuth flow: how we check to see if tokens, how we ask the user to log in, how we refresh the tokens, and so on. In this post we’re going to take that state machine and integrate it into an
While Basic Access authentication works for “basic” cases, it is far more common these days to see some form of OAuth used instead. There are some interesting advantages that OAuth has over Basic authentication, such as:
HTTP requests to web apis frequently need to have some sort of credential to go with them. The simplest kind of authentication is Basic Access authentication, and in this post we’ll be adding this feature to our library.
Most networking libraries have the ability to automatically send a request again if the received response wasn’t quite what the client was looking for. Let’s add that to our library as well.
I once worked on an app that used a
Timerto periodically ping a server with a status update. In one build of the app, we noticed that the status server started experiencing CPU spikes, eventually culminating in it not being able to handle any more requests.
Cancelling an in-progress request is an important feature of any networking library, and it’s something we’ll want to support in this framework as well.
There are a couple remaining changes we need to make to our loading interface, and one of them is to allow resetting.
So far we’ve written enough code to describe a chain of
HTTPLoaderinstances that can process an incoming
HTTPRequestand eventually produce an
In this post, we’ll be creating an
HTTPLoadersubclass that will allow us to dynamically modify requests.
So far, the
HTTPLoadingtypes we’ve created have all been loaders that directly respond to an
HTTPRequest. In order to create new kinds of loaders, we’ll need to revisit the
We’ve seen how a single method can provide the basis for loading a request over the network.
Up until now, we’ve been looking at the structure and implementation of a simple request/response model. Now it’s time to talk about how we send requests and receive responses.
Before moving on to sending our
HTTPRequestvalues, let’s make an improvement to our struct. Last time, we ended up with this basic definition:
In the previous post, we took a look at the structure of HTTP requests and responses. In this post, we’ll transform that information into the types we need to model them in Swift.
For a while now I’ve had a series of blog posts floating around in my head on how to build an HTTP stack in Swift. The idea started last spring with Rob Napier’s blog posts on protocols, and matured last summer and fall while I was working at WeWork on an internal Swift framework.
I’ve been wanting to blog more, but it’s always seemed like such a hassle. I appreciate the speed and flexibility of statically-generated sites, but the authoring experience around them isn’t that great. On the other hand, the authoring experience on hosted solutions (like Wordpress or Medium) is fantastic, but you lose a lot of the speed of a static site, and the ownership becomes more murky.
Four years ago I blogged about the oddities of leap days.
App Extensions tend to somewhat problematic when it comes to conditional compilation, because there are methods and functionality that are not available in app extensions. For example, app extensions don’t have a
UIApplicationinstance, and so the
UIApplication.sharedproperty is marked as
In the previous post, we saw how the
SWIFT_ACTIVE_COMPILATION_CONDITIONSbuild setting can inject values in to our .swift files that we can use to conditionalize code depending on our active SDK and/or architecture.
When developing an app or a library, it’s pretty common that at least once in the course of development, you’ll need to conditionalize compilation of your code. Maybe you’ll be accounting for a bug in the operating system where things that don’t work quite the same on your device as they do on the simulator. Or perhaps you’ll want to simply exclude code from your simulator builds because the simulator simply doesn’t have that functionality (like invoking the camera).
If I were Supreme Swift Potentate, there are a few things I’d change about how Swift deals with protocols, and how this gets manifest in the standard library.