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:
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:
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:
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:
With that said, there are some cons too:
RenderingMode
, LocalMapServer
, LocalGeoprocessingService
, and so on in a Portal map. In other words, these are two different concepts that don't correspond perfectly.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:
RenderingMode
, LocalMapServer
, and so on that are specific to ArcGIS Runtime.Some cons are as follows:
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.