You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -18,18 +18,157 @@ Under the hood, this will create a client using `HTTPNetworkTransport` with a de
18
18
19
19
## Advanced Client Creation
20
20
21
-
If you need to add additional headers to requests, to include authentication details for example, you can create your own `URLSessionConfiguration` and use this to configure an `HTTPNetworkTransport`. If you want to define the client as a global variable, you can use an immediately invoked closure here:
21
+
For more advanced usage of the client, you can use this initializer which allows you to pass in an object conforming to the `NetworkTransport` protocol, as well as a store if you wish:
22
22
23
23
```swift
24
-
let apollo: ApolloClient = {
25
-
let configuration = URLSessionConfiguration.default
-**`HTTPNetworkTransport`**, which has a number of configurable options and uses standard HTTP requests to communicate with the server
31
+
-**`WebSocketTransport`**, which will send everything using a web socket. If you're using CocoaPods, make sure to install the `Apollo/WebSocket` sub-spec to access this.
32
+
-**`SplitNetworkTransport`**, which will send subscription operations via a web socket and all other operations via HTTP. If you're using CocoaPods, make sure to install the `Apollo/WebSocket` sub-spec to access this.
33
+
34
+
### Using `HTTPNetworkTransport`
35
+
36
+
The initializer for `HTTPNetworkTransport` has several properties which can allow you to get better information and finer-grained control of your HTTP requests and responses:
37
+
38
+
-`configuration` allows you to pass in a custom `URLSessionConfiguration` to set up anything which needs to be done for every single request without alteration. This defaults to `URLSessionConfiguration.default`.
39
+
-`sendOperationIdentifiers` allows you send operation identifiers along with your requests. **NOTE:** To send operation identifiers, Apollo types must be generated with `operationIdentifier`s or sending data will crash. Due to this restriction, this option defaults to `false`.
40
+
-`useGETForQueries` sends all requests of `query` type using `GET` instead of `POST`. This defaults to `false` to preserve existing behavior in older versions of the client.
41
+
-`delegate` Can conform to one or many of several sub-protocols for `HTTPNetworkTransportDelegate`, detailed below.
42
+
43
+
### Using `HTTPNetworkTransportDelegate`
44
+
45
+
This delegate includes several sub-protocols so that a single parameter can be passed no matter how many sub-protocols it conforms to.
46
+
47
+
If you conform to a particular sub-protocol, you must implement all the methods in that sub-protocol, but we've tried to break things out in a sensible fashion. The sub-protocols are:
48
+
49
+
#### `HTTPNetworkTransportPreflightDelegate`
50
+
51
+
This protocol allows pre-flight validation of requests, the ability to bail out before modifying the request, and the ability to modify the `URLRequest` with things like additional headers.
52
+
53
+
The `shouldSend` method is called before any modifications are made by `willSend`. This allows you do things like check that you have an authentication token in your keychain, and if not, prevent the request from hitting the network. When you cancel a request in `shouldSend`, you will receive an error indicating the request was cancelled.
54
+
55
+
The `willSend` method is called with an `inout` parameter for the `URLRequest` which is about to be sent. There are several uses for this functionality.
56
+
57
+
The first is simple logging of the request that's about to go out. You could theoretically do this in `shouldSend`, but particularly if you're making any changes to the request, you'd probably want to do your logging after you've finished those changes.
58
+
59
+
The most common usage is to modify the request headers. Note that when modifying request headers, you'll need to make a copy of any pre-existing headers before adding new ones. See the [Example Advanced Client Setup](#example-advanced-client-setup) for details.
60
+
61
+
You can also make any other changes you need to the request, but be aware that going too crazy with this may lead to Unexpected Behavior™.
62
+
63
+
#### `HTTPNetworkTransportTaskCompletedDelegate`
64
+
65
+
This delegate allows you to peer in to the raw data returned to the `URLSession`. This is helpful both for logging what you're getting directly from your server and for grabbing any information out of the raw response, such as updated authentication tokens, which would be removed before parsing is completed.
66
+
67
+
#### `HTTPNetworkTransportRetryDelegate`
68
+
69
+
This delegate allows you to asynchronously determine whether to retry your request. This is asynchronous to allow for things like re-authenticating your user.
70
+
71
+
When you decide to retry, the `send` operation for your `GraphQLOperation` will be retried. This means you'll get brand new callbacks from `HTTPNetworkTransportPreflightDelegate` to update your headers again as if it was a totally new request. Therefore, the parameter for the completion closure is a simple `true`/`false` option: Pass `true` to retry, pass `false` to error out.
72
+
73
+
**IMPORTANT**: Do not call `true` blindly in the completion closure. If your server is returning 500s or if the user has no internet, this will create an infinite loop of requests that are retrying. This **will** kill your user's battery, and might also run up the bill on their data plan. Make sure to only request a retry when there's something your code can actually do about the problem!
74
+
75
+
### Example Advanced Client Setup
76
+
77
+
Here's a sample of a singleton using an advanced client which handles all three sub-protocols. This code assumes you've got the following external classes:
34
78
35
-
> Right now, additional headers can only be specified when creating a client. We're working on a better solution for dynamic configuration of the network transport, including the ability to retry requests that failed after refreshing an access token. Please chime in on https://github.com/apollographql/apollo-ios/issues/37 to help shape the design of this feature or to contribute to it.
79
+
-**`UserManager`** to check whether the user is logged in, perform associated checks on errors and responses to see if they need to reauthenticate, and perform reauthentication
80
+
-**`Logger`** to handle printing logs based on their level, and which supports `.debug`, `.error`, or `.always` log levels.
81
+
82
+
```swift
83
+
// MARK: - Singleton Wrapper
84
+
85
+
classApollo {
86
+
staticlet shared =Apollo()
87
+
88
+
// Configure the network transport to use the singleton as the delegate.
0 commit comments