Migrate to 100.x from 10.2.x
When you compile your unchanged 10.2.x application code against 100.x libraries for the first time, you will see compilation errors. Conceptually, you'll need to consider 100.x as a different product from the previous versions of ArcGIS Runtime. In reality, it is the same product, but it will best serve you to think about it as a different API, at least from the beginning. The ways your workflows are achieved has been re-designed in many cases to fit better with the ArcGIS platform and the Web GIS model as it has evolved today.
This topic outlines areas of the API that have undergone considerable changes, and provides guidance for re-factoring 10.2.x code for a 100.x app. Although this topic doesn't cover every change, it will help you get over some major migration hurdles. It will also help you decide whether functionality required for your app is available in 100.x.
Since the architectural changes for version 100.x were implemented at the lowest level of ArcGIS Runtime, most of the changes described in this topic apply to all ArcGIS Runtime products. There are some, however, that apply specifically to ArcGIS Runtime SDK for .NET. Many .NET-specific changes are related to the APIs for individual platforms, how they are delivered to your development projects, and so on. For more information related to this release, refer to the Release notes.
ArcGIS Runtime SDK for Xamarin APIs are now part of the ArcGIS Runtime SDK for .NET. The SDK now contains APIs for the following platforms.
- Windows Presentation Framework (WPF)
- Universal Windows Platform (UWP) - Replaces the 10.2.x Windows Store and Windows Phone APIs.
- Xamarin.Forms - Supports cross-platform development for Android, iOS, and UWP.
Each of the APIs listed above can be added to your project from packages hosted on nuget.org. You do not need to install the SDK to access these packages.
The SDK can be installed locally on Windows using a VSIX file. This will install the same NuGet packages locally on your machine as well as add Visual Studio project templates. See Install and setup for more information.
Local Server is now a separate install. When developing an ArcGIS Runtime app, you can use a lightweight client API to work with classes in Local Server. The Local Server components themselves are installed separately with ArcGIS Runtime Local Server SDK. See Install Local Server for details.
.NET requirements continue to change. Check the system requirements for the minimum required version of .NET and the Visual Studio workloads required for the platform(s) targeted by your app.
The process for creating a deployment for your app has been greatly simplified since 10.2.x, and no longer requires an ArcGIS Runtime .NET Deployment Manifest. See Deployment for details.
In many cases where functionality appears to be missing from 100.x, it is available but has been implemented differently. These changes require you to change your code to use new programming patterns or classes. The following sections describe some of the functional areas of the API where these types of changes have been implemented.
In ArcGIS Runtime SDK for .NET, at 10.2.7, the
Scene objects were split out from the controls that display them (MapView and SceneView) in order to facilitate a Model-View-ViewModel (MVVM) architecture for your apps. At 100.0.0, this change was adopted by all ArcGIS Runtime SDKs. If your app was created with ArcGIS Runtime SDK for .NET 10.2.7, this will not affect your migration to 100.x.
GeoView base class, inherited by
SceneView, is solely responsible for display and interaction, separating concerns from the model objects (
Scene) and allowing the APIs to be simplified and harmonized between the 2D and 3D worlds. GeoView contains graphics overlays, as well as operations, to easily identify features and graphics without having to write any layer type specific code. At 100.0.0, this change was adopted by all ArcGIS Runtime SDKs. If your app was created with ArcGIS Runtime SDK for .NET 10.2.7, this will not affect your migration to 100.x.
ILoadable interface was introduced at 100.0.0. Its design and purpose is intended for those workflows that involve accessing lots of data over the wire from connected online resources. All resources that load metadata asynchronously to initialize their state (such as maps, layers, and tasks) adopt the loadable pattern. The loadable pattern makes the behavior of loading state more consistent and explicit. Loadable resources do not automatically load their state. They load lazily when loaded by your app code or loaded by other objects that depend on them. This becomes useful for cases where, for example, you need to obtain information from a map resource without having to visualize it first. You can explicitly load the map resource without first associating it to a map view. The status of a loadable resource is easy to monitor to determine whether it is loading, has loaded successfully, or has failed to load. Your app can retry loading it if the resource failed to load due to a transient or recoverable condition.
If 10.2.x versions of your apps performed editing tasks involving feature services, it's important for you to fully understand the new loadable pattern. For example, retrieving features from an
ArcGISFeature object which implements the loadable pattern for increased efficiency. When getting
ArcGISFeature objects for rendering and query purposes, a minimum set of required fields is returned, such as identifiers, geometry, fields used for symbolizing, and so on. You must first load the feature that you want to edit, or the edit operation will fail. For complete details and code examples of loading features in editing workflows, see the Edit features topic.
Graphics are used to display temporary or ad-hoc geographic data on top of a map. In 10.2.x, you could add graphics to your map using a
GraphicsLayer. At 10.2.7, the introduction of
GraphicsOverlay allowed graphics to be displayed as part of the map view or scene view.
GraphicsOverlay ensures that graphics are always displayed on top of everything else in the view, even when layers are reordered or the map is changed. Graphics in an overlay are also reprojected, conforming to the spatial reference assigned to the view. Starting at 100.0.0, graphics may only be displayed in a
GraphicsLayer is no longer available.
Also at 100.x, there is a easier pattern for identifying graphics within graphics overlays. The
IdentifyGraphicsOverlayAsync method on
SceneView) identifies visible graphics in the specified graphics overlay, near the provided screen point. The Identify graphics code sample illustrates this technique.
ServiceFeatureTable now has a
FeatureRequestMode that is similar to the 10.2.x Mode property (
OnDemand). The value determines how features are requested from the service for use in the client.
- On Interaction with Caching - Features are requested and stored in the table when needed based on user interaction (panning or zooming to different extents, for example). Features are cached to reduce the number of requests for features.
- On Interaction without Caching - Features are always requested from the service. There is no caching of features, so this consumes the largest amount of network bandwidth.
- Manual Caching - Features are only requested when explicitly requested by the app. All queries are made to the local version of the data.
ServiceFeatureTable no longer has
OutFields properties. To filter the data returned from the service, you can call
ServiceFeatureTable.PopulateFromServiceAsync with values for those parameters.
GraphicsOverlay no longer have a
HitTestAsync method for identifying features or graphics (
GeoElement objects) that intersect a geometry. Instead, you should use one of the following methods on
GeoView to do the equivalent.
IdentifyGraphicsOverlayAsync- Identify graphics from a single GraphicsOverlay in the view.
IdentifyGraphicsOverlaysAsync- Identify graphics from all GraphicsOverlay objects in the view.
IdentifyLayerAsync- Identify features from a single Layer in the view.
IdentifyLayersAsync- Identify features from all Layer objects in the view.
See Identify graphics sample for an example of using these methods.
Geoprocessor class has been replaced with
GeoprocessingTask in 100.x. The task can create a geoprocessing job that tracks progress of the server processing. You can listen for status changes as the job progresses, and respond when it's complete by reading the results (outputs) from the job. The process is outlined in the following steps.
- Create a new
GeoprocessingTask. Pass in the Uri for the geoprocessing service endpoint.
- Create a new
GeoprocessingParametersobject to store the inputs to the task.
GeoprocessingTask.CreateJobto return a
GeoproccessingJob. Pass in the
- Set up a listener for the
- Start the job by calling
- In the
JobChangedhandler, check the job status.
When the status is
GetResultAsync to get the results, which includes a dictionary of outputs and (optionally) a map image.
At 100.2.0, a new
EncLayer displays content from ENC (Electronic Navigational Charts) data in S-57 format. In addition to displaying and identifying features, you can change various display settings for view groups, text, and other elements (such as isolated dangers, contours, color scheme, and so on). In 10.2.x, this functionality is available in the
Esri.ArcGISRuntime.Hydrographic namespace. At 100.2.0, you'll find the same API in
One of the big differences with 100.x is that the APIs for common operations such as editing, searching, geocoding, or routing are the same whether you are online or offline. You just need to specify whether your data source.
With respect to packaging maps and taking them offline, ArcGIS Pro lets you create and share offline mobile map packages. See Share a mobile map package. A Mobile Map Package (.mmpk), represented by the
MobileMapPackage class, is a set of items bundled together into a single archive file for easy transport. The items are one or more maps, their associated layers and data, and optionally networks and locators. A mobile map package also includes metadata about the package that you can glean useful information from using the new API. You don't need a Local Server to access these packages. You can also take the map offline directly using the on-demand and preplanned workflows provided since 100.3.
You can also take your connected ArcGIS based feature and tiled layers offline on demand with dedicated tasks and associated jobs, just as you were able to with previous versions. However, you might find that the class names and methods differ slightly from previous versions. The
GeodatabaseSyncTask works with ArcGIS feature services to take features offline in a mobile geodatabase (.geodatabase file) and allow them to be edited and synced. The
ExportTileCacheTask extracts tiles from a tiled ArcGIS map service as a tile package (.tpk file) and allows them to be viewed offline.
The Edit features guide topic provides code examples and in-depth discussion for editing both online and offline with the new API.
The pattern for generating a local geodatabase has changed at 100.x and you'll need to make some changes to this code if migrating a 10.2.x app.
GeodatabaseSyncTask.CreateAsyncto create an instance of the
GeodatabaseSyncTask. Pass in the Uri for the feature service endpoint.
- Set some of the same 10.2.x options, such as
GeodatabaseSyncTask.GenerateGeodatabaseto return a
- Set up a listener for the
- Start the job by calling
- In the
GenerateGeodatabaseJob.JobChangedhandler, check the job status.
- When the status is
JobStatus.Succeeded, read the contents of the database, add feature layers to the map, and so on.
All security and authentication related aspects are managed by a new
AuthenticationManager class which helps to unify and centralize how authentication is performed, regardless of the security solution in place. It allows the developer to decide how much control to exercise over authentication-related events handled by an app. It also caches credentials by default, reducing the number of times a user is prompted for credentials. The authentication manager issues an authentication challenge whenever authentication-related events occur. Developers can monitor these challenges and respond with appropriate credentials to get access to secured resources, or allow the authentication manager to prompt the end user for credentials.
One change you will notice from the previous
IdentityManager is that Uri objects are generally now used to represent URL endpoints (instead of using URL strings).
ServerInfo.ServerUri is now set with a
System.Uri rather than a string. Likewise,
Uri objects as arguments instead of strings.
The mapping API has been refactored for better integration with the portal API. This API allows you to load maps stored in a portal (web maps) into your app, make updates to web maps, and save changes back to the portal item. Also, your app can save maps created by your app as a new portal item. These web maps can then be used elsewhere within the ArcGIS system.
WebMapViewModel classes are no longer used to load a web map from a portal. At 100.x, the Map class has constructors that take either a
PortalItem or a
Uri representing the web map.
With 100.x, it's easier to determine where errors occur in the stack so you can provide better error messages to your Runtime app users. A new standardized error domain property indicates whether the error occurred client-side within the ArcGIS Runtime, or server-side from an ArcGIS Server service or web service. A consistent error code property can be used to further diagnose the error's cause or determine what error message should be displayed to the user. For a complete list of error domains and codes, see the Platform error codes topic.
Like earlier, you have access to all the capabilities during development and testing, however the licensing model for deployment has changed to include 4 levels - Lite, Basic, Standard, and Advanced where each level unlocks a different set capabilities. You can license your app either by using a license key or a by logging into a portal with a named user. More details are available in the License topic.
Many of the breaking changes you will encounter when migrating your app from 10.2.x to 100.x are due to classes moving to a different namespace or changes to class or member names. This section describes some of the reorganizing and renaming in the API between these versions.
Some of the namespaces that were available in 10.2.x of ArcGIS Runtime SDK for .NET have been removed. Usually, the classes that existed in these namespaces have been moved elsewhere. Sometimes, the same functionality exists at 100.x but has been implemented in a new class.
Esri.ArcGISRuntime.Layersno longer exists. The classes found here at 10.2.x are now in the
Esri.ArcGISRuntime.Controlsno longer exists. Classes like MapView and SceneView are now in the
Esri.ArcGISRuntime.UI.Controlsnamespace. Others, such as GraphicsOverlay and map grids are now in the
Esri.ArcGISRuntime.UInamespace. Things like
Camerahave been moved to the new
Esri.ArcGISRuntime.Symbology.SceneSymbologyno longer exists. The corresponding 100.x classes are in the
Esri.ArcGISRuntime.WebMapno longer exists. Many of the classes found here at 10.2.x have been moved to
- At 10.2.x, the classes for working with Electronic Navigational Charts (ENC) are in the
Esri.ArcGISRuntime.Hydrographicnamespace. In 100.2.0, you'll find them in
Esri.ArcGISRuntime.Hydrographic(as well as an
Several classes, properties, and methods have been renamed at 100.x for clarity and succinctness. The following table lists some naming changes in the API.
|MapView||Events: ||These events are now defined on the GeoView base class: |
|These properties are now defined on the |
|Symbology and renderers||3D Marker symbols, such as ||Use |
|SceneView and Scene|