Requires changing `generate-style-code` to treat 'formatted' as being the same as 'string' until gl-native gets 'formatted' support with https://github.com/mapbox/mapbox-gl-native/pull/12624.
To make nitpick happy, PropertyFunction.java uses the latest "text-field" description from v8.json. It's technically correct, just kind of pointless since the "If a plain `string` is provided" clause will always be true.
FOUNDATION_EXTERN is an alias for extern in most cases, but also covers us in the event that a method could be mismangled by the compiler as C++ (when we want C-style mangling, for Obj-C compatibility).
`MGLMapPointForCoordinate()` was `extern`-defined in a C header, but implemented in an Obj-C++ source file and mangled as a C++ symbol. `FOUNDATION_EXTERN` is C++-aware and will force C-style symbol mangling, which fixes the undefined symbol issue in consumer Obj-C projects.
* [ios] The new location manager API provides two new protocols MGLLocationManager and MGLLocationManagerDelegate to handle the location cycle and updates respectively. This enables developers to chose the appropriate location provider according to their needs, or transition between outdoors/indoors location updates.
It does provide a default implementation based on CLLocationManager.
Removes mgl_expressionByReplacingTokensWithKeyPaths and associated code. Converting on output is no longer necessary: from the prior commit, core converts token strings to expressions at parse time; all that's necessary is to ensure that the runtime styling API does so as well.
Based on patch from @lbud (Lauren Budorick).
Give `HeatmapColorPropertyValue` a more generic name,
since the same value type will be used for both `heatmap-color`
and `line-gradient` properties.
* Introduce AspiringActor, EstablishedActor
This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.
An `AspiringActor<O>` is responsible for:
- ownership of the actor's `Mailbox`
- allocating the memory for (but *not* constructing) the target object `O`
Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`. (Such messages
are queued in the mailbox until after the object is constructed.)
This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.
An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.
The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.
* Remove Actor#{invoke,ask}
