Reverts d5aff71 (#11948) and implements an alternative solution.
Even with the previous fix applied, we were calling `renderFinished()` directly when the render was canceled. This led to the following scenario (all on the main thread):
- `Map::renderStill()` callback is called, `uv_async_send` schedules a call to `renderFinished()`.
- `NodeMap::cancel()` destroys the map object, and calls `renderFinished()` directly, which cleans up the request
- `NodeMap::startRender()` is called to schedule a _new_ render, which means that a new callback will be set
- The `uv_async_t` fires and calls `renderFinished` again:
- We don't return early as intended by the fix in #11948 since a new callback/`req` object is now available.
- Since neither error nor image has been set, we'll see a `Didn't get an image` error message.
- We call the callback with the error. In scenario where we're reusing Map objects, we will start a new render, which will now trigger the `Map is currently rendering an image` error in `Map::renderStill`, and the map object enters a circle in which it will now fail repeatedly with this error.
This commit fixes the issue by completely removing the existing `uv_async_t` handle that could have a scheduled call, and replacing it with a fresh instance of an `uv_async_t` handle.
Added an Import command to the File menu for adding the contents of a GeoJSON file to the map. simplestyle-spec formatting is applied to layers via a handful of expressions. Dropped pins include any details provided through simplestyle-spec properties.
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}
- Uses java.text.Collator for comparison
- Uses java.util.Locale for locale loading
- Uses LanguageTag for BCP 47 parsing
- Falls back to non-locale-aware nunicode/default comparison for case-sensitive/diacritic-insensitive.
- Testing these changes depends on running Android render tests
- "collator" is not yet exposed in the SDK bindings.
