* This is a proof-of-concept for how we might manage connections.
It is currently in a good enough state to see if the idea is worth pursuing.
At a minimum, and before landing, we'd:
* split the schema.rs changes into its own PR - they aren't strictly needed
for what this patch does.
* Probably move PlacesAPI into its own source file, and better consider
threading considerations - the PlacesAPI instance will end up being called
from multiple threads (although the stuff we hand out shouldn't be)
* Manage the "sync" connection similarly to how we manage the "write"
connection. The PlacesAPI object is probably also where the sync "store"
objects can live (as currently we create brand new stores each sync, which
isn't as optimized as it should be)
* FFI changes needed to support this - this would be a breaking change, but
shouldn't be too difficult to manage.
* Lots of other cleanup - I figured I'd get comments on the general approach
before spending much time cleaning things up.
So by all means, offer all suggestions, but the main thing I'd like from this
is general approval that we should go ahead with this.
* Flesh out the Api more, including the Kotlin side of the fence
* First cut at Thom's feedback
* Fix nit: IOError => IoError
* Return writer connection to API when finished with it, ensure there's only one in kotlin
* Avoid duplication of rustCall
* Detect closing a connection on a different API than the one that opened it.
* Tests for PlacesApi::close_connection
* Fix busted benchmarks
* Address review feedback
* Changelog entry for connection types refactor
* Document thread-safety of places API
The website now publishes only consmer-facing documentation
found in ./docs/product-portal/. The rest of the ./docs/ folder
can be for internal contributor documentation such as how-to guides.
* Implement a bridge from the rust log crate to android.
* Ensure we still have logs available in non-megazord contexts
* Changelog entry
* Gradle plugin bump to 0.3.0
* Android version bump to v0.14.0