ArcObjects or the ArcGIS Runtime SDKs for Java and WPF—which is right for you?

There has been lots of  excitement about building custom applications for the desktop with the new Runtime SDKs for Java and WPF, there are also important questions from our developers, like “Should I migrate from ArcGIS Engine?” and “If I migrate, what pieces of my code will I need to rewrite?”

New developers are also asking questions, like, “Since both ArcObjects/ArcGIS Engine and the new Runtime SDKs support development of custom desktop GIS applications, which is right for me?”

If you’re migrating

Esri will continue to have updates to ArcObjects. Version 10.1 was released earlier this year and 10.1 SP1 became available in October.

If your application is in Java, you’ll likely want to take advantage of the overwhelming benefits that ArcGIS Runtime SDK for Java has over ArcObjects for Java. To help you with this effort, here’s the first article in a series to help make the move to ArcGIS Runtime.

If your application is in .NET, the decision of whether or not to migrate should depend on the capabilities in your existing application that you want to keep. Not all the capabilities of ArcObjects is supported by the Runtime SDKs, so you’ll want to have a good understanding of what is and what isn’t supported before you migrate. If you’ve created any custom ArcObjects, such as custom renderers, custom data sources, or custom symbols, you cannot migrate those to a ArcGIS Runtime application.

If you’re starting fresh

Below is a list of capabilities that you can include in your custom desktop application if you are programming with ArcObjects. These capabilities are not available in ArcGIS Runtime SDK for Java and WPF at this time, so you must use ArcObjects to get them:

  • 3D visualization. Although you can perform 3D analysis in the Runtime SDKs, you cannot display 3D in your application at the current release.
  • Data management and complex features. If you want your application to create, manage, or maintain geodatabases (whether file or enterprise) you must use ArcObjects. Runtime SDKs support reading all aspects of the geodatabase and editing/updating simple features only. Editing of complex features (parcels with topologies, the parcel fabric, network datasets, and geometric networks) is not supported in the Runtime SDKs but is supported in ArcObjects.
  • Building a map that is a map authoring product or cartographic product requires ArcObjects. For example, if you have your application start with a blank screen, have the user browse for data, symbolize the data, set up the labeling, rendering, and scale dependency—this all requires ArcObjects.
  • Some extensions are not available in the Runtime SDKs. Schematics and Data Interoperability are available only with ArcGIS for Desktop and ArcGIS Engine.

Here are some resources to help you get started with ArcGIS Runtime SDK if you are new to ArcGIS or an existing ArcGIS Engine developer.

Getting Started with ArcGIS Runtime SDK for WPF

Getting Started with ArcGIS Runtime SDK for Java

This entry was posted in Developer and tagged , , , , , . Bookmark the permalink.

Leave a Reply

3 Comments

  1. coloncm says:

    Very helpful article!
    Is it possible to add map raster and/or vector data to an existing geodatabase’s mosaic dataset that references the data from a geoprocessing package in order to later run a Runtime App that displays the updated map package that contains the dataset?

    Thanks in advance.

  2. jjbrownbpa says:

    “If you’ve created any custom ArcObjects, such as custom renderers, custom data sources, or custom symbols, you cannot migrate those to a ArcGIS Runtime application.”

    Where can I find out more about supported data sources for WPF runtime? Is it limited to packages? Or can it pull in data an ODBC source?

    Thanks you!

    • mbranscomb says:

      Hi,

      The ArcGIS Runtime supports almost all the datasources supported by ArcGIS, via packages. Any data formats that can’t be maintained in their original format will be converted to a File Geodatabase. ODBC sources may be supported via packages too (when packaging, check the box to reference the original datasource). Packages and services are the primary data sources, but you can also use the DynamicLayers capability of the RuntimeLocalServer (or ArcGIS for Server) to add Shapefiles, File GDB, Enterprise GDB and Rasters. You can also use the GraphicsSource property of the GraphicsLayer to create custom classes which expose a collection of Graphics – this might be one way to get ODBC data into your application. Additionally you can subclass one of the Layer classes (i.e. Tiled, Dynamic or Graphics) to create your own layers.

      Cheers