For me, the most significant development at Esri’s 2012 Developer Summit was the pre-release of ArcGIS Runtime. ArcGIS Runtime represents a new direction for building lightweight, focused mapping applications with Esri technology. The resulting applications are responsive, trivial to deploy, cloud friendly, and optimized for their target platforms – be they mobile or desktop.
The first hints about Runtime came at the 2011 DevSummit, more was revealed at the 2011 UC (see especially the third slide for platform support), and this year’s Esri Federal GIS Conference brought a demo and technical overview.
I see Runtime as a natural extension of two larger trends: Esri’s focus on a web service architecture (e.g. the transition towards ArcGIS Server and ArcGIS Online), and the proliferation and success of small, focused applications on mobile devices.
What is ArcGIS Runtime?
ArcGIS Runtime is a framework for developing map-centric applications with functionality added via widgets (for editing, geoprocessing, introspection, etc.). The user experience and programming model is consistent across desktop and mobile devices — “Desktop is just another device” — but is optimized for each platform’s capabilities and programming model. This means great user and development experiences on any one platform, but no portability of Runtime applications between platforms — a wise trade in my view. Map data and geoprocessing functionality can be accessed over the web (via ArcGIS online or an ArcGIS Server) or locally in tile, map, and geoprocessing packages.
The programming model closely matches existing web service APIs and treats local and remote data identically — a trick that’s accomplished by spinning up a tiny embedded ArcGIS Server to manage local resources. This web-service-centric approach implies coarse-grained interfaces and is naturally parallelizable (think performance, responsiveness).
Highlights
I found the following aspects of Runtime most interesting:
- Performance. In the demos, application start-up, map pan/zooms, and graphic animation were all extremely fast. These are recent improvements — they talked about redoing the drawing code for a huge increase in performance — and were well received. Getting the best performance (especially for start-up time) requires taking control of when the embedded services are started and stopped, a minor additional effort over this otherwise automatic activity.
- Deployment. It’s as easy as copying a folder, and nothing is left on the target machine. The minimum configuration is 10 Mb, and you add only the additional packages you need.
- Embedded Server. As above, the benefits are a consistent interface to local and remote data and processing, and good alignment with ArcGIS Server and ArcGIS Online. As a developer, I also find the minimalistic embedded web server and common C++ core (leveraging process-level parallelism and shared memory) cool.
Licensing
The most commonly asked questions about Runtime were around licensing. Some of the responses were inconsistent (and all were subject to change), so take the following with a large grain of salt:
There is a free (i.e., no extra cost to deploy) version, and a non-free one, along with three optional extensions (Network Analyst, 3D Analyst, Spatial Analyst). Licenses are purchased in packs of 25 (or possibly 50) and follow an honor system. (You embed the license key into your app, and then pay Esri based on the number of times you distribute it.) The non-free license is expected to be similar to MapObjects and in the “low hundreds of dollars” per deployment. Maplex labelling is included. If the customer already has an ArcObjects license, nothing further is needed.
Coming Soon
Two major upcoming features in Runtime were announced: 3D viewing (right now you can do 2D viewing and 3D analysis), and improved support for offline or partially connected scenarios.
Future Thoughts
One of the questions I’m left with is, “What does it mean for a future ArcGIS Desktop to be based on Runtime?”. I missed the ending session where Scott Morehouse revealed this would be the case (but my colleagues didn’t; see also Dan Levine’s comments on the GISi blog). Perhaps it means we’ll see ArcGIS Desktop on Linux or Mac? Is it possible to build such a rich editing experience on top of the coarse-grained Runtime? All will be revealed in time.
We’re also thinking about how FME might leverage Runtime’s new capabilities. Could we use Runtime as another option for reading and writing File and SDE Geodatabases? For now, the answer is a tentative no (especially as there is no advantage over File Geodatabase API for the former). What about exposing the included Geoprocessing capabilities in FME Desktop? (Runtime is off-limits to FME Server which would have to use ArcGIS Server.) Again, the answer is a tentative no, as there isn’t a good alignment between that use case and how Geoprocessing works in Runtime. (You define geoprocessing packages with logic and data in ArcGIS Desktop, and then pass small amounts of data to/from the Geoprocessing Tasks in Runtime.)
Conclusion
ArcGIS Runtime is a significant leap forward for building and distributing focused, map-centric applications based on Esri technology. It’s well aligned with the overall Esri ecosystem (including the increasingly highlighted ArcGIS Online), and represents a deep commitment for the web services architecture – both locally and over the web. It will be very interesting to see how these technology bets pay off.
Are you planning on investigating ArcGIS Runtime? Can you see ways of us using the runtime in FME that I’ve missed? How do you think this successful mobile paradigm (many small focused applications) will affect desktop computing in future?
Paul Nalos
