With ArcGIS version 10.1, Esri will introduce the ArcGIS Runtime and associated SDKs. There’s already a lot of buzz about the Runtime in the developer community, and for good reason. The runtime was been architected from the ground up with an eye on addressing some familiar challenges for GIS developers: exceedingly complex, fine-grained object models; complicated deployment; poor performance; large and memory intensive applications; lack of native 64-bit support … the list goes on. Esri hopes to eliminate many of these “pain points” with the new Runtime SDK, and I think most of us are also ready to let the healing begin. With its powerful yet coarse-grained architecture, it might be tempting to view the new ArcGIS Runtime as MapObjects and ArcGIS Engines love child, but there are (at least) five reasons why it’s more than that.
1) Simplified deployment
You may have already seen the now almost legendary demo where an Esri dev drags his Runtime project on to a thumb drive, walks it to another machine and fires it up without an install. It never fails to gets gasps from the crowd, and for good reason. How many times have you had to sheepishly tell your client “hmm, it works on my machine”? The ArcGIS Runtime eliminates complicated deployments by packaging everything required by the application into a (relatively) small deployment package. A simple tracking application I built with a pre-beta version of the runtime weighed in at about 175 megs. Since the Runtime is split into several “functionality sets”, you can keep your deployment lean by eliminating functionality your application doesn’t require. As a bonus, a Runtime application doesn’t care about other versions of ArcGIS you might have installed, and will happily run side-by-side with its progenitors.
The ArcGIS Runtime has been architected to take advantage of available CPU resources, including multiple processors and cores. It provides true multithreading and native 32 and 64-bit support. It also supports an asynchronous programming pattern (made possible by its multithreaded architecture) that contributes to an improved user experience. The ArcGIS Runtime display architecture has also been optimized for speed.
3) Connected and disconnected modes
Both local and Web data sources for the Runtime use the same programming model, which means it’s easy to build connected and disconnected modes into your application. Since your application’s data source can be based on map (or tile, locator, geoprocessing, etc.) packages, these data can be downloaded from ArcGIS.com on the initial load and then used locally thereafter. A common and effective approach is to use online data for your base map, while deploying a map package with your application to contain operational data. Editing can also be performed in a disconnected manner, using the geodatabase check-in/check-out replication model.
4) Intuitive object model
While functionally more powerful than MapObjects, the ArcGIS Runtime SDK is considerably more coarse grained than ArcGIS Engine. In other words, it delivers all the functionality that most GIS applications need without an overly complex object model. Under the hood, the Runtime uses REST for communication with both Web and local data sources. Developers who are familiar with any of the ArcGIS Web APIs should find the Runtime API very intuitive to work with right out of the gate.
5) Multi-platform support
The ArcGIS Runtime supports applications for 32-bit Windows, 64-bit Windows, and for 64-bit Linux. Windows applications can be built using the WPF, Java, or QT SDKs. Linux applications can be built using Java or QT.
While your applications still won’t be writing themselves anytime soon, the ArcGIS Runtime SDK should make GIS development a little more enjoyable. The time you may have had to spend smoothing out your deployment or pouring over a couple dozen object model diagrams can now be spent doing something fun (or at least productive), like fine-tuning your cartography or making tweaks to your application’s UI.