Now that we've learned about the API, how to test our app, and how to make sure it is performant, it's time to turn our attention to providing the app to our users. In order to do this, we want to think about options related to configuration, licensing, and deployment. In this chapter, we will discuss these options and provide some guidance on how to best provide your apps to your users so that they can be configured and licensed, and how best to deploy them. We will discuss the following topics:
- Configuration
- Licensing
- Deployment
One of the considerations you're going to have to bear in mind is how you want to allow your users to configure the app. In earlier chapters, we used a simple JSON file that was stored locally on disk. While this was fine for learning ArcGIS Runtime, it is by no means a good solution, especially for Enterprise Mobility, where you will deploy your app to dozens or even hundreds of users. How will you address this issue? There are a few options to consider:
- Providing users the ability to configure locally on a device
- Providing users the ability to configure using a web map from Portal for ArcGIS (Portal)
- Providing users the ability to configure on a device and with a web service
Let's discuss each of these so that we understand them. Providing users the ability to configure locally is a nice option, especially if they need to work offline for extended periods of time. Throughout this book, we've shown a simple solution to accomplishing this, using a JSON store. Of course, in order to do this effectively, a UI needs to be built for the app that allows the user to change the app to fit their particular needs and tastes. Of particular importance is how you will provide the user the ability to configure what layers to turn on or off, and how to display them. Do you need to create a symbology tool that allows users to set and save the symbology for each layer or do you just accept the default symbology that was created for the layer in ArcGIS Desktop or Pro?
Another option is to provide users the ability to configure the app using a web map. There are at least two ways of going about this, and each has their pros and cons:
- Using a web map from Portal for ArcGIS (Portal) or AGOL
- Creating a web service that is specific to ArcGIS Runtime
It's very possible to take a web map from Portal and have your app read in its contents to configure your app. This would require that you read in the contents of the web map file stored in Portal's content directory, or by some other automated means, and then load in the configuration to configure the ArcGIS Runtime map or scene with its contents. For example, you could add a layer in Portal, then configure the layer's name, symbology, definition expression, and so on so that your Runtime app could then use those same settings. There are some advantages to this approach:
- You won't have to build your own configuration format or file
- It seemingly aligns well with the notion of the Platform; in this, Portal is the frontend of your Enterprise GIS, while an ArcGIS Runtime app is just one of many consumers of this content
- Most importantly, this approach allows an end user to design the map using Portal for many ArcGIS Runtime users
With that said, there are some cons too:
- A Portal/AGOL web map and the ArcGIS Runtime API don't align their contents perfectly. For example, there's no such thing as
RenderingMode,LocalMapServer,LocalGeoprocessingService, and so on in a Portal map. In other words, these are two different concepts that don't correspond perfectly. - If you change the ArcGIS Runtime configuration locally, how do you apply that change to the web map? Perhaps, you could alter the web map format, but then you risk corrupting the Portal web map. Also, how would you make that change? Obviously, you don't want more than one user making a change to the web map from their device, because everyone would get the same configuration.
- If you upgrade Portal, you'd have to potentially update the web map, which means you'd have to update the way your ArcGIS Runtime app reads in the web map.
A web map is just a JSON file itself, so at first, it seems tempting to use it. For example, here's what the web map looks like:
{
"extent":
{
"xmin": -12933906.537,
"ymin": 3993856.886,
"xmax": -12933371.998,
"ymax": 3994375.189,
"spatialReference":
{
"wkid": 102100
}
},
"scale": 1234.5,
"rotation": -45,
"spatialReference":
{
"wkid": 102100
},
"time": [1199145600000, 1230768000000]
}For more information, see here:
http://resources.arcgis.com/en/help/rest/apiref/exportwebmap_spec.html
The other approach is to build a web service, where you build your own configuration file format and expose it as a web service. This is independent to Portal for ArcGIS. This also has some pros and cons. The pros are as follows:
- You can make the file format perfectly match the ArcGIS Runtime API. It would contain configurable items for
RenderingMode,LocalMapServer, and so on that are specific to ArcGIS Runtime. - With this option, you'd have the ability to allow each user have their own configuration on the server so that they won't have the ability to overwrite a web map as we discussed earlier. In other words, this would be a two-way configuration. A user could update the web service, and then see the change in the app, and likewise, a user could change the app's configuration and see the change in the service.
Some cons are as follows:
- You'd have to build this service and maintain an entire configuration format around the ArcGIS Runtime API. This alone is another piece of technology your team would need to build and maintain.
- As the Esri platform grows and evolves, you may find that Esri eventually develops something like this into Portal for ArcGIS or even ArcGIS Online, so you may find that you're spending a lot of money and time on something that will eventually come as a part of the platform.
In an ideal environment, it would be nice to include the ability to configure the app locally, and then send those configuration changes to the server. Then, if you go offline, you can still make changes locally and keep working. Once you go back online, you can then upload your local changes. Another scenario that may occur is that individual users have more than one device and they want to have two different configurations, depending on what they do with each device. The user could also have more than one ArcGIS Runtime app running on the device too. The user may want application A to have a different configuration on device 1 and 2, and post both of those configurations to a web service. Needless to say, these kinds of options need to be carefully considered, and then implemented so that users have as many options as required, while at the same time having the ability to do their work.