-
Notifications
You must be signed in to change notification settings - Fork 90
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
Adjust naming of offline tile downloading methods #353
Conversation
The flaky GeoJSON tests may be caused by unsorted JSON. |
I ran it again and it passed. Can't seem to reproduce locally. where is the non-determinisim? there seems to be a timeout in the test, which could indicate the OHHTTPStubs isn't yet bootstrapped properly, or there's a race. I think we've seen this before with NSURLProtocol-based network stubbing in tests. I don;t think this should block merge of this PR (assuming we're 👍 otherwise) but we do need to get to the bottom of it. |
I can't find the non-deterministic URL here, but it MapboxStatic.swift, the OHHTTPStub parsed GeoJSON when setting up the router which would lead to undeterministic route/url. We worked around that in the test case by adding: |
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.
Thanks for taking this one. Apart from the feedback below, the changelog entry should mention both the addition of data task methods and the fact that these methods now resume their tasks, so the postcondition is no longer required.
@discardableResult | ||
func fetchAvailableOfflineVersions(completionHandler: @escaping OfflineVersionsHandler) -> URLSessionDataTask | ||
@objc(fetchAvailableOfflineVersionsWithCompletion:) | ||
func fetchAvailableOfflineVersions(completionHandler: @escaping OfflineVersionsHandler) -> () |
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 think it’s still useful to return a data task, as the “calculate” methods in Directions do. That way the application can cancel the task if necessary. Sort of the “scheduled timer” pattern.
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.
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.
No, I think the important thing is that this method resumes the task. It’s fine that it also returns the task.
I'm not so sure the JSON keys sort order is a factor here - the stub is matching on:
... so I interpret the expectation timeout to mean that it isn't set up, or that internal async within the URL loading system tearing down the previous stubs caught this one in its dragnet as well. Since these stubs are so specific and localized, I think we can let them live longer and tear them down at the end of this test class's execution. Small commit coming to test this theory. |
Interestingly, the test still failed with eeb41aa (which passes locally). 🤔 |
cd1f4d1
to
fff15d4
Compare
I reverted the change to test teardown since it seems to incur the same level of flakiness. We can move the discussion of JSON key sorting into #354 and try to keep this focused and get it merged, or not merged, depending on #353 (comment) (cc @1ec5 ) |
fff15d4
to
2bd8a14
Compare
@discardableResult | ||
func downloadTiles(in coordinateBounds: CoordinateBounds, version: OfflineVersion, session: URLSession?, completionHandler: @escaping OfflineDownloaderCompletionHandler) -> URLSessionDownloadTask | ||
@objc(downloadTilesInCoordinateBounds:withVersion:completionHandler:) | ||
func downloadTiles(in coordinateBounds: CoordinateBounds, version: OfflineVersion, completionHandler: @escaping OfflineDownloaderCompletionHandler) -> () |
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.
Either the argument label in Swift should be with:
or the selector piece in Objective-C should be just version:
.
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.
@1ec5 should we plan a major release for this?
ec2f3f6
to
3b873cc
Compare
*/ | ||
@discardableResult | ||
@objc(availableVersionsDataTaskWithCompletionHandler:) | ||
public func availableVersionsDataTask(completionHandler: @escaping OfflineVersionsHandler) -> URLSessionDataTask { | ||
let task = URLSession.shared.dataTask(with: availableVersionsURL) { (data, response, error) in | ||
if let error = error { | ||
return completionHandler(nil, error) |
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.
availableVersionsDataTask(_:)
still confuses me; I don’t really see the point in keeping it separate. In general, for any kind of API request, the developer would only ever need two kinds of methods:
- A method that encapsulates requesting and processing a response, taking a completion handler and returning a (discardable) task for cancellation.
- A method or property that provides access to the request payload itself without side effects.
These requirements are satisfied by fetchAvailableOfflineVersions(_:)
and availableVersionsURL
, and by downloadTiles(in:version:)
and tilesURL(for:version:)
. availableVersionsDataTask(_:)
and routingTilesDataTaskWith(_:version:completionHandler:)
are confusing hybrids, because they look like accessors or factory methods but take completion handlers, as if they’re the methods that perform the task. In fact, completionHandler
is documented as being “called when the request completes”, but calling the method by itself doesn’t cause the completion handler to ever get called.
We can leave these methods in, but we should probably remove @discardableResult
because the methods do nothing on their own.
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 agree. The hybrid methods don't improve readability or versatility so I folded them into their counterparts.
ready for review |
Fixes #352