Release notes for 200.4

Snapping

The GeometryEditor now supports feature snapping when interactively creating and editing geometries. Snapping allows you to create geometries that connect and are coincident, so that interactive edits are more accurate, with fewer errors. When snapping is enabled in the SnapSettings, visual cues indicate to the user when edits have snapped to features. See SnapSource for information about configuring layers to be valid SnapSourceSettings.

Snapping can be used during interactive edits that move existing vertices using the VertexTool. It is also supported for adding new vertices for input devices with a hover event (such as a mouse move without a mouse button press).

Using the magnifier with a vertex move allows users of touch devices to clearly see the visual cues for snapping.

The snapping functionality provides one of a series of geometry editing enhancements that will roll out in future releases.

Support for OGC 3D Tiles Layer

This release of ArcGIS Maps SDKs for Native Apps adds support for a new layer type Ogc3dTilesLayer. The layer is based on the OGC specification for 3D Tiles. With Ogc3dTilesLayer, you can add 3D Tiles data from a public service, portal item, or a local file that includes .3tz files. The layer behaves similar to ArcGISSceneLayer and can also participate in 3D analyses.

Clustering support for GraphicsOverlay

This release adds support for clustering point graphics on a GraphicsOverlay in dynamic rendering mode. In addition, there are new APIs to highlight an aggregate geoelement in a clustered FeatureLayer or GraphicsOverlay and get access to the underlying geoelements.

Dynamic entity track line rendering

With this release, track line attributes have been enhanced to include the entity ID attribute that uniquely identifies the track. This means you can now apply a renderer to setTrackLineRenderer in the TrackDisplayProperties that highlights or distinguishes between tracks using one of the attribute-based renderers.

New field types

ArcGIS Maps SDKs for Native Apps now supports fields to store the following types of date and time values:

• Date only—Store values that indicate a day, month, and year. No time values are stored for date only fields.
• Time only—Store values that describe a moment in time (hours, minutes, and seconds).
• Timestamp offset—Store date and time values that include the time offset from the Coordinated Universal Time (UTC).

Big integer and 64-bit ObjectID fields are also now supported.

Relative date and time queries

Relative date and time queries are now supported with all date fields (except time only) by providing the intervals in the query. Relative date queries can be performed relative to the current date or to a specified (anchored) date.

Support for shortest path traces while offline

ArcGIS Maps SDKs for Native Apps now supports the shortest path trace type for offline utility networks. This type of trace requires two starting points and a network attribute (such as shape length) and returns the shortest path based on the provided attribute. This means that utility networks with full topology from a stand-alone or sync enabled mobile geodatabase now support all of the trace types that utility networks from a feature service support.

Licensing changes

A Utility Network extension license is no longer required to analyze (trace) utility networks, and has been removed from these methods: UtilityNetwork::traceAsync(), UtilityNetwork::queryNamedTraceConfigurationsAsync(), and Map::namedTraceConfigurationsFromUtilityNetworkAsync().

A new Advanced Editing extension license is now required to edit utility network features as well as create a version and edit features and tables in a branch version enabled feature service. This extension requires a minimum ArcGIS Runtime license level of Basic. Detailed information about the licensing changes made for ArcGIS Maps SDKs for Native Apps 200.4 and the specific methods that will require this license extension can be found in the License levels and capabilities topic in this guide.

Indoor positioning definition property on maps

An IndoorPositioningDefinition property is now exposed from the Map class. For an IPS-aware map, it provides all information needed to create an IndoorsLocationDataSource and conforms to the Loadable pattern.

New constructor for an indoors location data source

This release adds a new constructor to the IndoorsLocationDataSource that takes an IndoorPositioningDefinition. This provides a consistent and straightforward approach for creating an IndoorsLocationDataSource using IPS information stored with an IPS-aware map.

Indoors location data source configuration

An IndoorsLocationDataSource can now be configured using an instance of the new IndoorsLocationDataSourceConfiguration class.

Support for Arcade 1.26

This SDK now supports Arcade 1.26

The following linear referencing functions have been added:

• DistanceToCoordinate

• MeasureToCoordinate

• PointToCoordinate

• DefaultValue and HasKey have been updated to support checking nested dictionaries, arrays, and geometries.

Notes: KnowledgeGraph functionality which is available in Arcade version 1.26 with support in Pro and Online will be available in a future ArcGIS Maps SDKs for Native Apps release. The profile variables, $userInput and $graph, added to the PopUp and Popup Element profiles are currently set to null. A non-null $userInput implementation is planned for an upcoming release.

Coordinate systems and transformations

Available coordinate systems and transformations have been updated to EPSG v11.003. These include the Equi7 projected coordinate systems, which divide the world into seven continental areas and are designed for imagery use. New vertical transformations based on geoids, quasi-geoids, or other conversion grids can transform to or between gravity-related vertical coordinate systems for the British Isles, Corsica (France), Finland, New Zealand, St. Helena Island, and the United States. The National Geodetic Survey's historic geoid models (GEOID99, GEOID03, GEOID06, and GEOID09) and VERTCON 3.0 conversion grids for the United States are now supported. Vertical transformations using VERTCON 2.1 grids are deprecated but remain available. Transformations using VERTCON 2.1 grids appear at the bottom of the list of transformation paths.

Android x86_64

Android x86_64 architecture has been added to modernize testing options for developers targeting Android. Android x86_64 is an architecture primarily used for running Android emulators on Intel chipsets. Additionally, a limited number of physical devices use the x86_64 architecture. Previously, ArcGIS Maps SDK for Qt only supported x86 architecture.

Callout now supports dynamic entities

CalloutData now automatically updates its geometry, title, and description in real-time when attached to a DynamicEntity. Set a DynamicEntity to CalloutData::setGeoElement. Additionally, configure the CalloutData::setTitleExpression and CalloutData::setDetailExpression with an Arcade expression that accesses the element's attributes. The geometry and expressions will be reevaluated and update the callout when there is an update from the DynamicEntityDataSource.

Magnifier support with GeometryEditor

GeometryEditor elements can now be moved using the magnifier. This is particularly useful on mobile devices. To display the magnifier, set MapView::setMagnifierEnabled to true, start editing a geometry, and press and hold on a selected vertex to show the magnifier. While continuing to hold your finger down, drag the vertex to the desired location and release.

Portal async APIs now support QFuture

Asynchronous Portal "tasks" that relied on signal and slots now have a new variation of the method to make working with asynchronous code easier. The new methods contain the suffix Async, for example Portal::findItemsAsync(), and will return a QFuture. QFutures offer many benefits, including more centralized and concise code, chaining tasks together with .then(), and improved error handling. The original non-QFuture methods will be deprecated in an upcoming release, in favor of the QFuture-based methods. All new APIs will use only QFuture-based async tasks.

There are no breaking changes with this release.

• ArcGIS Pro 3.3 introduces the ability to define output fields (Reverse Output Fields) for reverse geocode operations. With locators created using ArcGIS Pro 3.3 and later, only fields enabled in Reverse Output Fields are returned from a reverse geocode operation in 200.4 and later. Supported output fields for geocode operations (including reverse geocode) are listed in the REST API under Geocode Service output fields. For locators created before ArcGIS Pro 3.3, reverse geocode results contain all output fields. In a future release of ArcGIS Maps SDK for Qt, all locators will only be able to return supported output fields in reverse geocode results.

• Following the deprecation of VERTCON 2.1 and introduction of VERTCON 3.0 by National Geodetic Survey, vertical transformations using VERTCON 3.0 grids will now be returned from appropriate TransformationCatalog calls. Vertical transformations using VERTCON 2.1 grids remain usable and will still be returned from TransformationCatalog::transformationsBySuitability calls but will now appear at the bottom of the returned lists which are sorted by suitability. To make use of transformations using VERTCON 3.0 grids, the required grid files must be deployed with your app. These can be found in the Projection Engine Data download for this release. See the Projection Engine updates section for additional coordinate system and transformation enhancements introduced with this release.

Version 200.4 of ArcGIS Maps SDK for Qt is the last release to include QML API, it is deprecated.

• Apps should migrate to the C++ API. ArcGIS Maps SDK for Qt comprises two different APIs: QML API and C++ API. The QML API offers a "pure QML" experience, where no C++ code is written, and everything is written with QML and JavaScript code. This was convenient and allowed for rapid prototyping but had several drawbacks and limitations to the APIs and functionality delivered. The C++ API allows apps to be written with either a QML UI or Qt Widgets UI (for desktop apps), both using the same C++ backend code. The C++ API is more flexible, faster, and follows the best practice patterns promoted by Qt Group. Developers will find that the C++ API offers the best scenario: building responsive UIs with QML and leveraging the full power of Qt with the backend C++ APIs available directly through the Qt Framework.

200.4 is the last release to include ArcGIS Extras, it is deprecated.

• This helper library augmented QML shortcomings by exposing Qt functionality that was only available in C++ to QML. This announcement follows the QML API deprecation. Apps should migrate to use the underlying Qt APIs directly.

See the QML API Deprecation and Roadmap Blog for more details.

• Support for iOS/iPadOS 15 is deprecated. The last release to support this version is 200.4. A minimum of iOS/iPadOS 16 will be required at the next release.

• Support for macOS Monterey (version 12) is deprecated. The last release to support this version 200.4. A minimum of macOS Ventura (version 13) will be required at the next release.

• Support for Qt 6.5.2 is deprecated. The last release to support this version is 200.4. A minimum of Qt 6.5.6 will be required at the next release.
• Support for Xcode 14 is deprecated. The last release to support this version is 200.4. A minimum of Xcode 15 will be required at the next release.

Issues addressed in this release are listed below.

• Geodatabase methods for managing transactions (beginTransaction(), commitTransaction(), and rollbackTransaction()) have been made thread-independent. Any thread can end a transaction started by any other thread, integrating with modern language and platforms' concurrency models.

• BUG-000163316: Some QFuture async methods can deadlock with Qt 6.6

Known issues or limitations for this release are listed below.

• BUG-000166643: A sceneview containing a scene with vector tiled layer can result in a crash if it's created and destroyed repeatedly. A possible workaround is to avoid using a vector tiled layer as a basemap, for example as an imagery basemap.

New samples

• Validate utility network topology
• Configure basemap style language

Enhancements

• Added Callout support to Add dynamic entity layer