Mobile editing design

The ArcGIS Mobile SDK is used for building focused applications to visualize, inspect, collect and maintain spatial information in the field. Some example editing applications you can build with the Mobile SDK include facility mapping, street sign inventory, fire perimeter mapping, building inspection, meter reading and inspection, and many more. The editing components and local cache data model combined with the power of the Geodatabase data and transaction model cater to a variety of field editing solutions and workflows. Using the sketch, geometry and data access components you can quickly build tools and forms to collect new features, edit the shape of existing features, and capture and maintain attributes that leverage the added behavior of geodatabase domains, default values and subtypes.

The procedures described here will help with your application design and implementation. For further details on developing the actual tools to perform the editing task, see the related documents on editing or the API Reference material.

Editing application design

To build a focused application using the Mobile SDK, you must fully understand not only what and how your field workers perform tasks in the field but also what terms they use to describe the tasks that they need to accomplish. Also, think about environmental conditions (Can they use both hands? Are they wearing gloves? Do they dock devices in a vehicle or toss them on the seat? Do they use field devices today? How long will the device be running on battery power?). The most successful mobile applications are those that make the field worker's tasks easier. If you are building a new mobile solution that is replacing a paper-based system you will need to sell the value of using a device as well as your application to the field worker. Incorporate existing workflows as much as you can and use the terminology that your field worker uses. Think about what are the most critical tasks that field workers perform. All of these factors will determine not only how you design your application but how you define the field database schema and supporting map services within ArcGIS. You will find that building targeted applications that focus on a specific set of related tasks will be more effective for the field worker than having one generic application that requires considerable training time on how to use it and how the generic terms, used to support multiple workflows, apply to specific tasks.

Remember that all mobile editing applications have some common parts which include: the database, the local data cache, and the editing framework. The SDE database that supports the mobile editing functionality must have a GlobalID field and conform to some basic requirements as outlined in the Building mobile Geodatabases document. The local data cache allows the field worker to collect and edit data while disconnected from the server database and track those changes. The local data cache's ability to track changes combines with the mobile SDK synchronization with the server database functionality to form the database framework. The editing framework is built on the ability to modify the local data cache using ADO table functionality or the feature geometry via the sketch tools.

Mobile editing choices

The development pattern for editing within a mobile application is fairly simple. Your editing application design will be similar to a simple map viewing application in that your data and its schema exists within a mobile cache and that you have a valid URL to a map service so that you can connect and synchronize changes when need be. When deploying your application to a device, it is best if you build and deploy a mobile data cache for as large an extent as your field worker will travel, to minimize wireless data transfer.

In building any ArcGIS Mobile application, there are some basic requirements such as working with the local cache, displaying the map, and data synchronization. Beyond these generic development tasks an editing application requires additional functionality such as setting up the edit environment, performing the edits, saving the edits, and synchronizing those changes with the server database. In designing an editing application there are many parts, other than the code to be used in the client, that form the design. The Geodatabase structure, SDE setup, operational layers chosen, the map created and published all influence your editing application. Therefore, it is important to include these parts in your planning. For more information see Building a Mobile Map and Geodatabase design.

For building the client editing application your development depends on these choices:

Data considerations

One of features of the ArcGIS Mobile system is the ability to synchronize data changes to and from the server using a wireless or wired connection. This synchronization is expensive in terms of computer CPU load and for wireless and expensive in terms of real dollars for data transfer. Thus to minimize the amount of data transfer ArcGIS Mobile uses basemap layers which contain data that does not often change or need to be edited. These basemap layers are included to provide visual guidance and enhance the look of your map; layers such as water bodies, roads, and government boundaries. The layers that your application will be using to edit or query are called operational layers. These operational layers are used in the synchronization process, if there are changes found. This division of data layers is made when the Mobile Map is created. As not all ArcGIS featurelayer types can be edited, you should refer to the document on operational layers for the list of supported ones. The featuredatalayers that are going to be edited must be selected from the layers in the local data cache. If no layers are present in the local cache, you will not be able to start editing, so your application will need to check if the local data exists and possibly get it if not present. Once the map is open, to start editing your application will need to determine if the featurelayer is editable. Even though the feature layer is in a SDE database and has a GlobalID field, your application code should ensure that the data is editable before attempting edits. To provide more control over your data, the editing permissions on the feature layer can be set to allow new features, or allow modifications of features.

Types of editing

As noted above edits can be made on the geometry, the attributes or both parts of an existing feature. The other type of editing choice is whether new features can be added, as opposed to only being able to edit existing features. Deciding on editing restrictions occur when publishing the mobile service, yet the developer still needs to ensure the application adheres to these limits. Properties on the mobilecachelayer can be used to check for the modification type allowed. If you are going to allow creation of new features, your application must ensure creation of the correct geometry for the FeatureDataTable. In addition, the new feature’s attributes will need to be checked for allowable values, as certain field types can be null or empty when added to the table but will produce a synchronization error when trying to add the new feature into the geodatabase. Developers must be careful when a feature's geometry is being edited, since there are rules for certain shapes that need to be followed to maintain topology. For complex features like polylines and polygons, the order of the vertices is very important and is used to determine properties like inner and outer rings.

While only editing feature attributes may seem like a very simple task, it is important to use defensive coding practices to ensure data integrity. Since data attributes can range from a simple boolean true/false value to a photo stored as a blob, your application must be prepared to capture and validate the input data. For some attribute fields editing operations maybe restricted by a coded-value domain that was established in the database. While a coded value domain helps an end user edit an attribute it is up to the developer to ensure the display of the correct attribute values for the feature being edited. For editing other more complex attributes, such as a photo or a text note, the developer will need to use external APIs to integrate software for a camera or laser-range finder.

The FeatureDataTable.SaveInFeatureLayer() or FeatureLayer.SaveEdits() methods internally create, add, modify and delete tables containing your updates for the layer you are changing. The updates are stored in the mobile cache in delta tables until synchronized with the server, at which point the delta tables are erased.

You can always query a particular feature layer using an EditState. This returns a FeatureDataTable containing the features based on their status like original, current, deleted, modified or added.

Input options

The input options will depend on the platform and device on which you deploy your application. While the editing choices outlined above impact what you can edit, the device will determine how you can edit. For applications deployed to Smartphone devices, the lack of a touch screen means that a user cannot tap on the mapdisplay to specify a location or use a stylus to draw a line. The input on a Smartphone requires that the user be able to use the keys and/or rocker control of the device to control the cursor for input. As different Smartphones have different capabilities, an application needs be able to respond to different input methods or limit its install base. For example, if you are building an application that relies on a GPS signal, the application needs to check for a GPSConnection and provide feedback to the user. If the device does not contain a GPS receiver, than a message should let the user know this, and maybe even guide them to a solution such as a Bluetooth connected GPS, or perhaps a GPS receiver is a minimum requirement. This can also apply to inputs such as a photo from a camera, which is more likely found on a mobile device than a tablet PC or laptop. Other input types, such as a laser range finder, may require that an application check for its existence and enables additional menu items or pages to utilize this functionality. As each platform requires its own development environment, it is easy to develop with the generic device capabilities; however, it does mean you need separate applications for each platform.

A critical issue for input of feature geometry is ensuring new features properly transform to the spatial reference of the feature dataset. Geometry created using the geometry classes may represent anything from a point captured using a GPS location, a coordinate taken from an existing feature or a shape the user has digitized on using a stylus. It is necessary to use the spatial reference class that contains members for converting from one spatial reference to another.

When using input data to add or modify geometry using the sketch tools within the sketch framework, once the sketch is finished, the geometry needs to be saved into the feature datatable. The FeatureDataTable.SaveInFeatureLayer() or FeatureLayer.SaveEdits() methods internally create, add, modify and delete tables containing your updates for the layer you are changing. The updates are stored in the mobile cache in delta tables until synchronized with the server.

Synchronization considerations

As edits occur to the local data cache, they are stored in the data tables and flagged using the EditState enumeration. When you are preparing to synchronize your data, using the featurelayer.HasEdits property allows you to check quickly if the layer has edits. Typically, the goal is to minimize the amount of data being transferred keeping in mind that whenever a synchronization is required in the field, the bandwidth must be used conservatively. One way to achieve this is only synchronize the data once a day, while another is to limit the synchronization to only layers and features that have edits.

If your editing application requires that the data changes made in the field be received in the office instantaneously, you could incorporate logic into the code so upon completion of an editing task synchronization occurs automatically.


Copyright © 1995-2011 Esri. All rights reserved.
9/20/2011