Quartz and Open Source / github collaboration

[snodnipper]

Given that Quartz is C/C++, can ESRI open source the Android / Java wrapper so that folk can raise issues and submit pull requests? It would be great to use the geometry-api-java geometry classes with the SDK.

[EuanCameron]

The majority of the code contained within the runtime architecture is C++ and is compiled natively on each platform. The API code that is written to expose the C++ functionality must always be in sync with the C++ code, and in reality there is not a huge amount of code there. We are currently not considering open sourcing this, as it is tightly coupled to the C++ internals and the release cycle.

You mention the geometry-api-java project here on GitHub. The Android API has its own geometry API, implemented in C++, and exposed in Java. I'd recommend while working with one of the runtime APIs you use the build in Geometry engine (it performs faster) rather than the geometry-api-java.

[snodnipper]

The main issue is creating reusable Java libraries using geometry as a foundation class (similar to String) - which may be distributed on maven central etc. and used by any Java software.

To date, I have created reusable Java libraries with geometry-api-java geometries baked in. That is, a cycle track etc. is simply:

• name : String
• track : ESRI Java Geometry

That, fundamentally, means that I don't need to create my own geometries or use JTS...only to write adapters to get those geometries to paint on an ESRI map.

Ideally, we would have a consistent set of pure Java ESRI geometries that we can use with our business code and simply pass to the map, which will create a geometry implementation according to whether the software is running on Android or any other supported Java environment - yielding the desired performance characteristics.

I raised this as an issue and passed some comments on Early Adopter Community > ArcGIS Runtime SDK for Android > Java Geometry API / Android