As we said in the Quartz intro post, the Quartz release of ArcGIS Runtime is a significant release. You will see many new APIs that will allow you to build amazing Apps for your users on a wide variety of devices. This posts takes a look under the hood to highlight some of the architectural changes present within the runtime. While you, as a user of a runtime API, do not need to know about these details, we are after all builders and if you’re like me you love to understand what makes something tick, so let’s take a look at the internal architecture of the runtime at Quartz.
The ArcGIS Runtime’s architecture is design to fully exploit the capabilities of the platforms it runs on and the APIs that you code against are designed to integrate seamlessly with the other native APIs that you use on these platforms. This is a challenge, but by combing native C++ code with platform specific API code it has been possible to achieve.
The diagram below is a high level overview of the ArcGIS Runtime’s architecture.
The C++ runtime core is compiled natively on each platform and therefore offers the best possible performance. It full utilizes the hardware of the platform including the GPU to ensure high performance both for map display and analytical calculations, all while being as efficient as possible on battery usage. The C++ core is not exposed directly to you but via APIs specifically built for each platform. These APIs are designed to ensure that they expose the full capabilities of the core.
The initial releases of the ArcGIS Runtime were primarily focused on providing a high performance mapping engine for the display of content delivered to the client via web services and to provide a native client side API for working with remote GIS services, such as geocoding, routing and analysis. These web services are typically implemented using ArcGIS Server, ArcGIS Online or when running on a desktop ArcGIS Runtime’s Local Server.
With the 10.2.3 release of ArcGIS Runtime the C++ runtime core grew significantly in terms of the GIS functionality that it supported. At 10.2.3 local data management was added with the development of the runtime geodatabase (managed in a SQLite database). The runtime geodatabase supports the simple feature model and enables you to build sophisticated editing solutions that can optionally sync changes back to feature services. In addition, the ability to find directions and address based on local content was also introduced. These additions to the runtime have allowed you to build many kinds of apps that function fully disconnected from, fully connected to, and partially connect to the internet.
The 10.2.3 release heralded a new era for you as ArcGIS app developers who need to build sophisticated apps that required mapping and GIS technology. In the past your only choice was to use ArcGIS Engine running on Windows and Linux desktops. At 10.2.3 ArcGIS Runtime made this type of app development possible on all the supported ArcGIS Runtime platforms. Over the last year subsequent releases continued to add more capabilities, however, as many of you will have seen these capabilities have not been available on all platforms.
Evolving the ArcGIS Runtime Architecture
The Quartz release will be the largest release in terms of new capabilities that the runtime has seen. New layer types, more renderers and symbols, support for reading and writing web maps, 3D, local vector and raster layer support and GPU based spatial analysis are all included.
All this new functionality means there are many new APIs for you to use. It also means some changes to existing APIs to accommodate a number of fundamentally new concepts.
Here is a diagram that shows the 10.2 API Architecture
As discussed earlier, the native APIs wrap the functionality of the C++ runtime core. In order to achieve this there is a certain amount of interop code required. Some of this interop code is mandated by the technologies at play, for example, in the case of Java and Android; Java Native Interface (JNI) code is required to enable Java to call into the C++ runtime core. Some platform APIs do not require this interop layer, for example, the Objective C used by iOS and OS X APIs allows for direct calling of C++ code. Even in these cases where direct calls are possible it is not simply a matter of exposing the C++ runtime core API to you as it has many concepts important to the implementation of the core, but not important to you as a consumer.
These API interops are designed and built for each specific native API, and while that allows for an API that looks and feels like all the other native APIs for a specific platform, it also allows for differences to creep into the Runtime APIs. Those of you who have developed for more than one runtime API are only too aware of these differences. Differences due to platform design patterns are acceptable, however, differences in logical model caused by 2 different designers implementing the same API on a different platform are not.
Over the last several releases the runtime’s architecture has evolved. It has adapted to new platforms, exposed new ArcGIS capabilities and it has moved on from being a pure web service client to a powerful GIS runtime capable of performing many operations solely on the device . All this has been achieved by modifying and growing the existing architecture, and while this has been done successfully the process has exposed limitations, both internally to the architecture as well as externally to API consumers.
Quartz API Architecture
As stated earlier the Quartz release is a large functional release for the runtime resulting in many new APIs. Because of this and the fact that we knew of architectural limitations with the 10.2 architecture the Quartz release will see a new internal architecture. There are many benefits to this new architecture but 4 will be obvious to you as consumers of an API; API consistency in terms of its logical model and behavior, higher quality, improved performance and the delivery of functionality on all platforms in a more synchronized way. While some interop code is required to enable cross-architecture calls the goal of the new architecture is to keep API specific interop code to a minimum. In order to achieve this we have created a new internal common API for the runtime core illustrated in the diagram below.
This common API encapsulates the implementation that maps the public API’s logical model to the runtime core’s implementation. Since this is now in one place all the APIs share the same logical model with the same behavior. It also ensures that the API specific interop code (shown in green in the diagram above) is kept to a minimum. This means that there is less duplicated code across the APIs, which in turn improves quality and means that new functionality can be rolled out across all the APIs in a more consistent way.
Despite this new architecture differences between the APIs still do exist, but these differences are minimal and caused by the specific platform’s architecture and capabilities; after all it is important that this is not a generic least common denominator API.
The API teams have taken great care to ensure that the common conceptual model of the runtime common API is exposed to you on your platform of choice using appropriate design patterns that will feel natural for you.
Impact of New Architecture on Existing APIs
As discussed above there are significant advantages to this new architecture, however, there is a cost in terms of API changes from 10.2.6; due to the API harmonization. Not every API has changed, but there are changes to the Mapping, Geometry and Portal APIs. These changes will be covered in detail in subsequent articles.
No one likes change for change sake, but we feel that the architectural changes we have made at Quartz have significant benefit and are worth the effort, and as we roll out the Quartz release we are confident that you will agree.
Article Discussion: