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 got a bag of accessories that I cart around that meets about 95% of all the tech needs I tend to have these days, but there’s one accessory I’ve wanted in there that doesn’t exist: the perfect Apple Watch charger.
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