Although there has been a great blog on this subject already (see: http://esriaustralia.wordpress.com/2011/02/17/the-new-arcgis-runtime/ ) there still seems to be a bit of confusion over what the ArcGIS Runtime actually is and what you can do with it. First of all ArcGIS Runtime is actually a series of 6 runtimes, each based on a specific platform. These cover IOS, Android, Windows Phone, Windows Mobile, Windows and Linux. So we have 4 runtimes for mobile and 2 runtimes for ArcGIS Desktop. When people refer to the “New ArcGIS Runtime”, most are referring to the Desktop version(s) and this is where I will focus this blog.
So what is it for?
ArcGIS Runtime will enable developers to build custom applications that can be easily distributed to users. Such applications may be required to deliver custom interfaces and/or automate of a set of tasks . Additionally there is a LOT of functionality within ArcGIS Desktop, but most users use only a fraction of it. Being able to strip out unrequired buttons, menus and the underlying code, libraries etc is a big bonus. Not only does this make an application more intuitive and streamlined, it also has the potential to reduce the size of the installation footprint and decrease licensing costs.
Is it another ArcGIS Engine?
Well not quite. ArcGIS Engine has access to all the fine grained ArcObjects that form the basis of Desktop. Therefore you can build applications that can do anything (or everything!) that Desktop can. ArcGIS Runtime on the other hand is more coarse grained in terms of its programming language. This will make things slightly easier to code, but it does limit its functionality in comparison. In this respect, ArcGIS Runtime is positioned in between ArcGIS Mobile and ArcGIS Engine (from low to high functionality).
What will you develop in?
You will have the choice of one following SDKs:
- WPF (.Net)
- Java (Java)
- QT (C++)
Those with web development experience should find the transition to these APIs relatively gentle (says ESRI). Additionally, you will be able to leverage the power of geoprocsseing models and in doing so, reduce the amount of coding you have to do. In fact, leveraging geoprocessing models is about to get easier. In Desktop 10, we have already seen the Map Package (packaging up maps and data for sharing), but there are more packages on the way in 10.1. These include the Tile (pre-rendered tiles); Locator (for geocoding); and Geo-processing (models and data) packages. The workflow will be to create your package in Desktop and provide them to ArGIS Runtime to utilise.
What is special about it?
Developers will be excited about the following:
- Has a small installation footprint and is and easy to deploy
- Fast load up and display
- Supports native 32 and 64 bit code execution (ArcEngine only supports 32)
- Both utilises hardware and scales well
- Supports asyncronous programming only
For the rest:
- Integrates well with ArcGIS maps and data
- Supports Maplex labelling and cartographic representations
- Supports editing in File Geodatabases and SDE (for Simple Features)
- Supports Geocoding
- Supports Geoprocessing
Deployment is where ArcGIS Runtime really excels. There is no install required, no need to register dlls and admin privileges can be ignored (this is not true of ArcGIS Engine). The whole deployment (.exe/dlls/packages/runtime) is contained within a single directory structure; so you can easily cut and paste the whole lot and even run your application off a USB stick. Ignoring data, the size of the directory is between 100 and 150 mb, depending on what functionality (or dlls) you include (ArcGIS Engine = 450 mb). Additionally, each ArcGIS Runtime deployment is independent of each other and of ESRI technologies. This means that you can have multiple implementations on a single machine and there will be no software version dependencies. From a developers point of view this is amazing, no need to test and update your code each time ESRI brings out a new version!
Any limitations?
- Less functionality/customisable than ArcGIS Engine (as I’ve said)
- Can’t edit Networks or Topologies
- No support for Custom Layers/Renderers/Symbols from Desktop
How does it work?
ArGIS Runtime = [Application (plus API) ] + [REST services and runtime]
The set up is much like ArcGIS Sever, but packages (Map, Tile, Locator or Geoprocessing) are used instead of web services. The application (API) talks to the runtime’s REST endpoints via http, and the the runtime uses an embedded web server to create/communicate with worker processes that do things like draw map (just like ArcGIS Servers SOM and SOC processes). ESRI say that this services based architecture comes with many benefits. Not only does it make ArcGIS Runtime scalable and efficient, it also makes it robust. If a worker process falls over, a new one can be spun up to replace it – without crashing the whole application. Additionally, the architecture enables a better use of resources (only using what is required at the time) and should facilitate the easy migration of your applications from Desktop to online.
Licensing?
Where ArcGIS Engine can be licensed by either Engine Runtime licenses or an available Desktop license, things are going to be going to be a bit different for ArcGIS Runtime. It has been said that ArcGIS Runtime will be licensed like the old Map Objects. If like me, you have never seen Map Objects, you could probably do with a bit of clarification. What this means is that you will buy batches of licenses, with one license being required per deployment. In theory the runtime should check for a valid license and only fire up if there is one.
There will be 3 levels of ArcGIS Runtime License:
- Basic (map drawing only – but free)
- Standard (ArcView level functionality, plus Geoprocessing tools, point to point routing and viewshed analysis)
- Advanced (ArcEditor+ functionality)
What this means is that you have the capacity to only pay for the functionality you require and licensing should be pretty flexible (i.e. not tied to a specific user or machine). Unsure of what level of licensing you will need? – ESRI have thought of this too. Like in Desktop 10 when you tick the option to upload your layer packages to ArcGIS Online (when saving them); in 10.1, when creating a Geoprocessing Package the can chose to ‘upload’ to ArcGIS Runtime. At this point an analyser will notify you of the licensing requirements for the Geoprocessing tools incorporated.
I should point out that licensing for ArcGIS Runtime has yet to be finalised – so the above could be subject to change.
So I’m sold, it sounds like ArcGIS Runtime will allow you to build focused, reusable, scalable easily deployable aps. Although ArcGIS Runtime does not have all of ArcGIS Engine’s functionality, it does overcome many of its limitations – offering a sleeker and potentially more cost effective solution.
How do I get it?
If you’re not on the Beta program – you will need to get it through EDN once it is released (http://www.esri.com/software/arcgis/edn/index.html).
John H
Esri Australia Technical Blog 