Base Classes for entire ESRI Stack (Java)

[snodnipper]

In summary, I believe that this project (or refactored project) should be the base Geometry library for all ESRI Java projects, where other ESRI SDKs reference this project.

Quoting from my comments on the Early Adopter feedback forum (ArcGIS Runtime SDK for Android)

I'd like to start a discussion around the various base classes that we use in the SDKs and other software.

Many base classes (e.g. Point) are available from the Geometry API Java, which is a great open source resource. It would be wonderful if the released SDKs also used those base classes (gradle / mvn dependency) as that helps avoid namespace collisions or boilerplate to convert one ESRI point to another ESRI point.

Whilst working on the production API I have come across numerous collisions, which slows productivity. Right this second, The Geometry API has "GeometryEngine.geodesicDistanceOnWGS84" whereas the Android SDK requires us to use [GeometryEngine.geodesicDistance"](https://developers.arcgis.com/android/api-reference/reference/com/esri/core/geometry/GeometryEngine.html#geodesicDistance%28com.esri.core.geometry.Point, com.esri.core.geometry.Point, com.esri.core.geometry.SpatialReference, com.esri.core.geometry.LinearUnit%29) - both in the same namespace. I see in the Quartz API we have distanceBetween, which is a third permutation. Similarly, Geometry.dropAllAttributes is public in the geometry API but default in the Android SDK.

An ideal way forward would be to have well defined base classes (open source as the geometry library that everyone can use throughout their private code but ALSO enables them to easily access the ESRI SDK methods.

@shellygill

[stolstov]

@snodnipper Thank you for comments. This project is a pure java code all the way, while the Android SDK is not anymore. Even if API signatures still match, a conversion would be required between the classes. The different Runtime SDKs share common C++ code and are calling into native binaries. See "What are ArcGIS Runtime SDKs?" here https://developers.arcgis.com/en/arcgis-runtime/
Use the github project when the pure java is required. Use Android SDK if you are working on Android platform.

[snodnipper]

@stolstov thanks for your initial thoughts. My comments are primarily around creating pure Java abstractions that can be used in all Java and Android projects if easily possible.

Pure Java is useful for Android development as that code can be tested extremely quickly. That is in contrast to Android dependant code (android namespace / native), which is often prohibitively slow - hundreds of pure Java unit tests can run within a second whereas an Android build typically takes 5 - 30 seconds.

To my mind, Point could be pure Java (x, y, z + srid) along with many of the other base classes. We could interact with the Android SDK using those abstractions, which might be mapped onto or converted into an Android implementation within the SDK (e.g. Point).

The same is true for services - presumably "GeometryEngine" could be bound to either GeometryEngineJava or GeometryEngineAndroid - which is what we typically do with Dependency Injection frameworks like Dagger and Guice.

The new API looks lovely and clean and my comments aren't to suggest unnecessary abstraction.

My thoughts are that many folk have reusable Java libraries that are used in both Android and Java code bases. Users would ideally like a standard set of geometry classes to simplify interface code - and certainly not have to deal with namespace collisions, which doesn't appear to be a problem with quartz but is with the current production 10.2.7 Android SDK.

[shellygill]

I would echo @stolstov 's comments - Android has been using core C++ libraries for map display, but in Quartz all of the runtime APIs are being reengineered to make much more use of shared C++ libraries for almost all of their APIs. This means the runtimes will be converging across platforms, but also means we cant diverge to use different base classes for Android and Java.

What we can do however, as we work through the beta releases, is reflect on what we can learn from the pure Java geometry API. Realistically, different factors may influence the final API so we wont always make the same API decisions. In the case of the geodesic functions you mention, we will be adding geodesic options back in to the Quartz APIs (e.g. there were geodesic functions in Android 10.2.x, but not yet in Quartz); distanceBetween is not a geodesic function. One thing we can look at might be how to facilitate conversion between Quartz runtime API geometry and pure Java API geometry, and vice versa. If you are attending the European Dev Summit then do stop by the Android SDK booth to discuss.

[snodnipper]

Thanks Shelly, I might be going to the Dev Summit - I'll certainly pop by if I do go.

Clearly a lot is possible but much ultimately comes down to effort. I have been prototyping a few things (mostly around Android) and I have run into numerous exciting problems - namespaces being one of them. Avoiding the collision (with Quartz) is a great step as folks like me could always wrap the SDK with something more abstract such as a pure Java Point. The thing is, many of the new design choices are really nice but haven't been backported to this library, such as having a spatial reference on any given Point - which makes concurrent code easier to work with.

Thanks for chipping in.

[stolstov]

@snodnipper It is generally the case that geometries share spatial reference inside datasets. Having spatial reference on geometry require to carry an extra pointer on each point. In addition a correctly written code would need to check the spatial reference whenever geometry is processed - in relational operations, in topological operations - everywhere. Most of the time this checks would be redundant. This makes the code less efficient. If you have a case that requires to carry spatial reference with the geometry, use MapGeometry class.

[kjkrum]

My two cents as an Android developer:

The gigantic size of the ArgGIS Runtime SDK for Android is a compelling reason to avoid using it. The use of native libraries on Android should be viewed as an interim, transitional solution. To support Android going forward, the entire native library should be ported to pure Java.