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 ArcGIS 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.
Functional changes
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.
Maps and scenes
The Map object has been split out from the view that displays it, to represent the model or viewmodelcomponent in a Model-View-Controller (MVC) or Model-View-ViewModel (MVVM) architecture. These important objects are at the heart of the ArcGIS Runtime and have an API that follows the ArcGIS Web GIS information model. They contain operational layers, basemaps, bookmarks, pop-ups, and other ArcGIS-specific data to be leveraged in your apps. They also include APIs to instantiate maps from URLs, portal items, or default basemaps. For details on how to add views and maps to your 100.x apps.
Views
The GeoView interface, implemented by MapView, is solely responsible for display and interaction, separating concerns from model objects, e.g. ArcGISMap. The Views contain graphics overlays, as well as operations, to easily identify features and graphics without having to write any layer type specific code. There is a lot you can control with the GeoView.
Loadable
The
Loadable
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.
Common use cases for using
Loadable
are explained and demonstrated through code examples in the topic Loadable pattern for asynchronous resources.
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
ArcGISFeatureTable
return
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 overlays and graphics
Graphics are used to display temporary or ad-hoc geographic data on top of a map. In 10.2.x, you added graphics to your map using a Graphics. Graphics are now added to Geo as overlays. This ensures that graphics are always displayed on top, even when map layers are reordered. This also makes it convenient to switch out maps while keeping the graphics in place.
Also at 100.x, there is a easier pattern for identifying graphics within graphics overlays. The identify method on Geo (Map or Scene) identifies visible graphics in the specified graphics overlay, near the provided screen point. The Identify graphics code example demonstrates the usage of this method.
Feature tables
ServiceFeatureTable
now has a Feature that is similar to the 10.2.x Mode property (Snapshot or O). 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.
Offline
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 ahead-of-time workflows provided since 100.3.
See the
MobileMapPackage
class in the API reference and the Offline maps, scenes, and data topic for a thorough description of how to create and work with Mobile Map Packages.
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.
Authentication
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.
Portal
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.
The ArcGIS organization portals document provides more information on the use of portal. For an example of saving and updating web maps stored in your portal, see the Create and save map sample.
Error handling
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.
Licensing changes
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.