Mobile editing design

The ArcGIS Runtime SDK for Windows Mobile is used for building focused applications to visualize, inspect, collect and maintain spatial information in the field. Some example editing applications you can build include facility mapping, street sign inventory, fire perimeter mapping, building inspection, meter reading and inspection, and so on. The editing components and local cache data model, combined with the power of geodatabase data and the transaction model, cater to a variety of field editing solutions and workflows. Using the sketch, geometry, and data access components you can 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 discussed in this topic help with your application design and implementation. For further details on developing the actual tools to perform the editing task, see related topics on editing or the API Reference.

Editing application design

To build a focused mobile application, you must understand not only what and how your field workers perform tasks in the field but also what terms are used to describe the tasks they need to accomplish. Also, consider environmental conditions:

How

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 need to sell the value of using a device and your application to the field worker. Incorporate existing workflows as much as you can and use the terminology your field worker uses. Consider the most critical tasks that field workers perform. All of these factors determine not only how you design your application but how you define the field database schema, and supporting map services within ArcGIS. Building targeted applications that focus on a specific set of related tasks are more effective for the field worker than having one generic application that requires considerable training on how to use it, and how the generic terms used to support multiple workflows apply to specific tasks.

Remember, all mobile editing applications have some common parts, which include: the database, local data cache, and the editing framework. The geodatabase that supports the mobile editing functionality must have a GlobalID field and conform to some basic requirements as outlined in the Building Mobile Geodatabases topic. 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 synchronization of 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 custom or built-in sketch tools.

Mobile editing choices

The development pattern for editing within a mobile application is intuitive. Your editing application design is similar to a map viewing application because your data and its schema exists within a mobile cache, and you have a valid map service URL to connect and synchronize changes, when needed and/or available. When deploying your application to a device, build and deploy a mobile data cache for as large an extent as your field worker travels, to minimize wireless data transfer.

In building any ArcGIS Runtime for Windows Mobile application, there are basic requirements such as working with 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 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 the features of the ArcGIS for Windows 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, it's expensive in monetary terms for data transfer. Thus, to minimize the amount of data transfer, the system uses basemap layers, which contain data that does not change often or need to be edited. These basemap layers are included to provide visual guidance and enhance the map's appearance; layers such as water bodies, roads, and government boundaries.

The layers your application uses to edit or query are called operational layers. Operational layers are used in the synchronization process, if there are changes made. This division of data layers is made when the mobile map is created. As not all ArcGIS feature types can be edited, see the operational layers topic for the list of supported ones. The feature layers to be edited must be selected from the feature sources in the local data cache. If no layers are present in the local cache, you cannot start editing; therefore, your application needs to check if the local data exists, and retrieve it if it does not exist. Once the map is open, to start editing your application, determine if the feature source is editable. Even though the layer is in an 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 source 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, 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. Editing restrictions are set when publishing the mobile service, yet the developer still needs to ensure the application adheres to these limits. Properties on the FeatureSource can be used to check for the allowed modification type. If you are going to allow the creation of new features, your application must ensure creation of the correct geometry for the FeatureDataTable. In addition, the new feature’s attributes need to be checked for allowable values, as certain field types can be null or empty when added to the table, but produces 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 such as 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 may be 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 the developer's responsibility 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 text note, the developer needs to use external APIs to integrate software for a camera or laser-range finder.

The FeatureDataTable.SaveInFeatureSource() or FeatureSource.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 (upon successful completion of the synchronization).

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

Input options

Input options 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 determines how you can edit. As different devices 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, a message should inform the user, and guide them to a solution such as a Bluetooth connected GPS, or perhaps, a GPS receiver as 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 checks for its existence and enables additional menu items or pages to utilize this functionality. As each platform requires its 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 data table. The FeatureDataTable.SaveInFeatureSource() or FeatureSource.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 FeatureSource.HasEdits property allows you to check 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 to 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 data changes made in the field be received in the office instantaneously, you could incorporate logic into the code so when an editing task is completed, synchronization occurs automatically.

1/7/2015