Previously, when we started a worker operation that eventually throws an exception (e.g. due to the tile not being parseable), and then enqueue another worker operation while the first one is processing, we treated the worker as idle once the first operation's error callback fired, even though the second operation was still in progress. Due to our use of coalescing, I was unable to come up with a reliable test since we'd need to reproduce the behavior described above, which is timing dependent.
Since 9a9408e811, we marked tiles as non-renderable if an error occured. This lead to situations where a tile was loaded + parsed successfully, then a revalidation attempt occured (e.g. because the resource was stale) which failed. In this case, we used to mark the tile as non-renderable although we could've used the perfectly parsed (stale) resource.
Otherwise it errors with, "cannot initialize a variable of type 'BOOL' (aka 'signed char') with an rvalue of type 'id _Nullable'."
This doesn't seem like it should be necessary.
This reverts the manual layout triggered by KVO approach in favor of a constraints based approach that the KVO method had previously replaced. Although the manual layout approach worked well in most cases and was cleaner in that it did not manipulate any containing views in the app space, using KVO on UIViewControllers has proven to be dangerous.
This also updates the gitshas for KIF and OHHTTPStubs to unbreak UI tests that verify these related changes are working.
This also adds an ornament constraint system for iOS 11+
A bogus source file path was causing contention between two resources. As a consequence, Transifex spammed the project’s watchers daily about changes that didn’t occur.
The update steps for the heading indicator are typically small, so animations tend to pile up and cause performance issues. Disabling actions is a slight regression when it comes to large steps (they're not animated now, where they previously were) and this should eventually be addressed.
Also consistently use provided API for disabling CATransaction actions.
The documentation for the `location` property states that "This property contains `nil` if the map view is not currently showing the user location or if the user’s location has not yet been determined." The iOS SDK presently returns a garbage value, which has some rather annoying consequences when the value should logically be nullable. This change should rectify the issue.
With _location no longer initialized to an invalid coordinate, trying to access `_location.coordinate` when `_location == nil` will return `0, 0`, which is a valid coordinate.
* [ios, macos] Fix querying features returning nil when features available.
* [ios, macos] Copyedited changelogs
Also, macOS SDK v0.5.1 has yet to be released, because none of the changes that went into iOS SDK v3.6.1 were relevant to macOS.
