Fixed a deadlock that could occur if the host application attempts to set user defaults on a background queue. Now we observer user defaults changes synchronously.
Cherry-picked from d76ef6e53b.
When a map view was smaller than the entire viewport, negative content insets would be applied. Negative content insets would only be valid if the map view extended outside of its frame, which cannot happen.
Fixes#4440.
Requesting progress is expensive, so it is once again computed only on demand, rather than automatically at launch. Moved progress requesting back to iosapp and osxapp.
Made MGLOfflineStorage.packs strong rather than copy so that KVO notifications on that key path include index paths. Replaced custom KVO mutable collection methods with calls to -mutableArrayValueForKey:, avoiding redundant casts.
Privatized MGLOfflinePackDelegate and made its methods required, since MGLOfflineStorage is the only conforming implementation. Require a pack to be explicitly invalidated before deallocation by its owner (MGLOfflineStorage). Added a method to reload the canonical collection of packs.
Previously, if the user adds an offline pack without specifying a name in the alert, the pack would be named “Untitled n” for the nth pack created since the application was launched. This logic could result in identically named packs (for example, if the user relaunches and creates another unnamed pack). Instead, use the visible coordinate bounds as a placeholder and fallback name.
Resume a pack upon successful addition. Removed an extraneous weakSelf/strongSelf dance. When possible, update individual labels in a cell instead of reloading the entire cell. That way, if the user swipes to the left to reveal the Delete accessory button while the pack is actively downloading, the accessory button remains on screen as progress updates come in.
MGLOfflineStorage now maintains a centralized, strongly held, KVO-compliant collection of all extant offline packs. MGLOfflineStorage issues notifications for progress updates. Client code can now react to the successful addition of an offline pack either via the completion block or via a KVO insertion.
Fixes#4287.
Corrected a few Xcode terms in the changelog entry about static framework installation fixes. Merged that entry with the one above it because they discuss the same fixes. Also moved the combined entry to the top, because it’s about as close to a breaking change as we can get without incurring a major version bump.
Fix issues with static build configuration that caused it to be
problematic for host applications when they were installed on device.
Also fixes issues that broke the iTunes Connect validation and upload
process. This also updates the `binary` instructions in INSTALL.md to reflect
these changes.
Previously, the post of the turnstile event was a side effect of the
map.load event and would happen when the host app was started from a
terminated state at the first initialization of MGLMapView. The
turnstile event post was guarded with dispatch_once so that it would
only ever be sent once during the lifecycle of the application after
it started from the terminated state.
This changes that behavior by:
- Allowing a new turnstile event to be posted as much as once per
day
- Only triggering a map.view event when a map is initialized if the map
is loaded outside of the 'background' application state
- Sending a map.view event whenever a MGLMapView is instantiated
and the application did become active or enters foreground
iOS turnstile event sending behavior is now:
- A map.view event is generated whenever a map is loaded and also
when a map is shown again when the host app becomes active and moves
into the foreground
- Turnstile events are still triggered by mapviews and will be sent as
frequently as once per day for a host app that is not terminated and
also whenever a host app is terminated and restarted
w
There is now only one instance of mbgl::OfflineFileSource, created when the shared MGLOfflineStorage object is initialized. Also create and use the shared MGLOfflineStorage object when initializing an MGLMapView object. The unified cache file is located in a subdirectory of Application Support, where the SDK has control over the file’s lifetime. The subdirectory is already named after the host application’s bundle identifier, ensuring that each Mapbox-powered application has an independent tile limit. If there’s an ambient cache in a subdirectory of Caches, delete it. If there’s an offline cache in a subdirectory of Documents on iOS or Caches on OS X, move it to the unified cache location in a subdirectory of Application Support.
Fixes the iOS/OS X side of #4338.
Include offline headers in the umbrella header used by the static framework. These includes are already present in the umbrella header used by the dynamic framework. jazzy relies on the static umbrella header to include all the headers, so the offline headers were also missing from documentation.
Although often recommended, CFBundleName is not guaranteed to exist in
an app's configuration. As an identifier of telemetry data, even when
it is present it can be inconsistent because of localization.
CFBundleIdentifier, although possibly longer, will be consistent
across locales and for the lifetime of an app in the App Store even
if the app name changes in any locale.
Also categorized offline symbols for jazzy and moved styleURL from MGLOfflineRegion to MGLTilePyramidOfflineRegion, since you never know if there will be a region type not constrained by a style in the future.
Tapping on a download now pauses or resumes it. Tapping on a completed download navigates to the downloaded region and switches to the downloaded style.
Renamed SDK classes related to offline viewing to more closely match the terminology used by mbgl and the Android SDK while remaining consistent with Cocoa naming principles.
Added a new ifabric Make target for packaging up a static framework similar to the one released as 3.0.1. Place artwork and certificate assets inside Mapbox.bundle inside Mapbox.framework. Link SystemConfiguration in the umbrella header.
Distinguish between the framework bundle and the resources bundle. For the dynamic frameworks and embedded static frameworks, the two are the same; for the non-embedded static framework, the latter resides inside the former.
