-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstract NetworkService functionality #5
Abstract NetworkService functionality #5
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wmcginty looks good as well. Sync w/ 'master' and merge whenever you can.
@@ -46,7 +46,7 @@ extension BackendService: BackendServiceProtocol { | |||
networkService.cancelTask(for: request) | |||
} | |||
|
|||
private func handleResponseData<T: NetworkRequest, U>(_ data: Data, for request: T, completion: @escaping BackendServiceCompletion<U>) where T.ResponseType == U { | |||
private func handleResponseData<T: NetworkRequest>(_ data: Data, for request: T, completion: @escaping BackendServiceCompletion<T.ResponseType>) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm digging the simplification!
/// | ||
/// - Parameter clientError: The error returned by the NetworkSessionDataTask. | ||
/// - Returns: The outcome NetworkServiceResult dictated by the error. | ||
public static func networkServiceFailure(for clientError: Error?) -> NetworkServiceFailure { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with networkServiceResult(for response:)
below, would we want to return a NetworkServiceResult
here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but on the use side I ended up then having to immediately unwrap the NetworkServiceResult into the underlying NetworkServiceFailure to use it so I felt like it was a waste in this case to wrap into a Result to simply unwrap immediately after.
Maybe as an addition we could add a third function to the helper that returns the Result?
I pulled some of the conversion functionality out of NetworkService and intro a NetworkServiceStruct helper - this allows for a simpler approach to creating a delegated network stack. Because of the wide variety of implementation concerns, the framework can't really provide a way to store and execute
'completion handlers' using the URLSessionDelegate (and sub-protocols).
Because of this, it is simplest to bypass the majority of BackendService and NetworkService's execution functions and use URLSession directly. It is still desirable to use Hyperspace's error and result handling however, and breaking these functions out of NetworkService itself allows us to do that.