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.