Using the application framework (Windows Mobile)—An overview

The application Framework gives developers the ability to extend an out-of-the-box mobile application. With the framework, you can create a task or project extension. You can extend existing functions within the application or embed new functions with your own business logic. This document will give you more details on the architecture of the framework design.

Note:

The application framework is made available in ESRI.ArcGIS.Mobile.Client.dll; keep in mind that it is dependent on the ArcGIS Mobile core framework (which is available in ESRI.ArcGIS.Mobile.dll). Learn more details on setting up a development environment for working with the application framework.

Note:

ArcGIS Mobile provides an application framework for both tablet and Windows Mobile applications. Both are available through ESRI.ArcGIS.Mobile.Client.dll but are located in different folders. When you start developing tasks or extensions, make sure you choose the right assembly for your target platform.

By default, the application framework assembly for the Windows Mobile platform is located at

C:\Program Files\ArcGIS\Mobile10.0\DeveloperKit\CompactFramework\ESRI.ArcGIS.Mobile.Client.dll.

By default, the application framework assembly for the Windows platform is located at

C:\Program Files\ArcGIS\Mobile10.0\bin\ESRI.ArcGIS.Mobile.Client.dll.

If you are new to the out-of-the-box mobile application, familiarize yourself with the basics of the application. The task-centric, workflow-driven design is the key for you to better understand the architecture of the application framework.

Framework architecture

The application framework exposes APIs for you to access various function areas inside the mobile application. The diagram below shows the architecture of the application framework at a high level and the relationships between key classes.

The following section will give you more details on the key concepts of the framework.

MobileApplication

At the very top level, the application framework provides a class, MobileApplication, which represents the out-of-the-box mobile application that runs on your device/emulator. MobileApplication exposes an application-level GpsConnectionManager, allowing you to hook up a GPS management module. It's assumed that each device will have, at most, one GPS device.

Through the Project property, MobileApplication also gives you access to the current mobile project that is open in the application. It's very common that you get lists of project extensions, tasks, and other project-related information for a mobile project through this property.

Typically, a field task requires interaction with the mobile application before it's completed. With the Collect Features task, for example, you start by choosing a feature type that you want to collect data for, followed by options for the geometry collection method (using GPS, a map, or x,y coordinates). After you collect the geometry, you will be taken to another page where you can edit attributes. The task will be completed only after you click OK at the end of this workflow. This design philosophy exists for at least two reasons. First, by breaking a task down into separate pages, the workflow becomes well guided, and each page is easier for you to understand what you can do and what choices you have. Second, this design is due to the limitation of screen real estate on many mobile devices.

To navigate from one page to the other, the MobileApplication class provides two useful methods—Transition() and ShowDialog(). Transition() can be used when you need to show a new page while there might be some other processing going on behind the scenes (for example, a new page that shows a list of features that are within five miles from a certain point). ShowDialog() should be used when input is definitely needed before anything else can be done (for example, a login dialog box that requires a user name and password). Transition() takes a page that inherits from a Page class, which provides default visual elements such as the title bar and left/right soft menus. ShowDialog() takes a Windows form by default. If you want to have the same look and feel for your dialog box as other pages, you can also use a Page class.

With both the Transition() and ShowDialog() methods, the MobileApplication class will take care of how to show the new page, hide the previous page, and make this transition seamless without any flickering on the screen. What's more, since Transition() takes a form that inherits the Page class, the form by default owns left and right soft menus. The left soft menu will show Back unless changed and, when clicked, will automatically navigate to the previous page. Note that this doesn't require the developer to write any code. If the previous page is the Select Task page, the left soft menu will show Tasks and navigate back to the Select Task page when clicked.

Project

As mentioned above, field tasks and associated data are organized by mobile projects in the mobile application. Through Mobile Project Center, you can create, edit, or delete projects. You can specify data sources for your mobile project (mobile service and/or basemap data); customized names and descriptions for built-in tasks; whether each field from each layer is editable, viewable, or searchable; and GPS quality filters for layers that you can collect data for. Mobile Project Center also allows you to add additional tasks or extensions from third-party assemblies.

When you open a mobile project, the application loads the project's configuration file. With the framework, you can access the project by the MobileApplication.Project property. From the Project class, you can get a list of available project extensions through the ProjectExtensions property or a list of tasks through the Tasks property. You can also get the full extent or spatial reference used in this mobile project or be notified through a FeaturesChanged event when features are changed.

The project also fires up a CreatingFeatureActionItems event when feature action items are being created on certain pages. This typically happens when you have a list of features on a page and you tap it to show available actions that you can apply to the activated feature. Through this event, you will get a chance to modify the ActionItems collection.

There are a few built-in pages and tasks for the application, such as the Select Task page, Settings page, View Map task, and WorkList task. The Select Task page contains a full list of tasks available for this mobile project. It serves as the home page for the project.

Task

The mobile application is a task-based, workflow-oriented application that provides a well-guided user experience for field-workers. Therefore, field workflows are conceptualized into different tasks. The ability to view geospatial information on the map can be found in the View Map task. The most commonly required field data collection and feature inspection workflow is available in the Collect Features task with all necessary guidance for collecting/updating geospatial information in the field. Each of these built-in tasks, or any task you develop, is represented by the Task class within the application framework.

The following is a list of built-in tasks provided by the mobile application:

• View Map
• Collect Features
• Search Features
• View Work List
• Manage Edits

All these tasks are in the Task class, which is in the ProjectExtension class. In this sense, Task is actually a special type of ProjectExtension. One unique characteristic of a task is that it is listed on the Select Task page, while a normal project extension isn't.

The application framework provides access to each of the above tasks as shown below.

A task has a name; a description; and, optionally, a customized icon. If you don't specify a custom icon, the mobile application will use a default icon for it. The icon needs to be 36 by 36 pixels in dimension.

If there is a need to store additional information for a task, you can choose to also inherit your Task class from IXmlSerializable. By doing this, you can put your information inside an ArcGIS Mobile extension file that's paired with your custom task. By implementing your own ReadXml and WriteXml methods, you will be able to read your information from the project configuration file or write to it.

Keep in mind that creating a new task and listing it on the Select Task page is only part of the story. Typically, a task consists of a few pages that field-workers would need to go through to get the job done. Therefore, as a developer, you will need to create those separate pages to interact with as a guide through the whole process. To navigate from one page to other, use the MobileApplication.Transition() or MobileApplication.ShowDialog() methods.

ProjectExtension

In the application framework, ProjectExtension is a general term for extending the mobile application by introducing new functions or workflows. In other words, you can change the behavior or properties of existing tasks by creating a project extension. For example, you could take the existing Collect Features task and add a geometry validation function to make sure collected geometry is within a certain boundary. You might also find it useful to change the default context menu on the map page and provide different navigation tools. The requirements might vary on a case-by-case basis.

Similarly to creating a new task, quite often you will need to create additional pages that embed your own business logic as a guide through a task.

Page

In the application framework, you can think of a page as a customized form that carries certain UI elements and behaviors. A task is broken down into different pages to form a workflow. On each page, an interface is provided for interaction with the application. The application framework provides the Page class for such purposes. Many pages inside the mobile application inherit the Page class to keep a consistent look and feel, so you will have a title bar and default left/right soft menus on your form. This makes it easy for your UI to be consistent with other pages in the application. Moreover, you can use MobileApplication.Transition() to easily navigate from one page to the other and return to previous pages if need be. This page navigation approach requires the least amount of development effort and can cut development time tremendously.

As a matter of fact, SelectTaskPage also inherits the Page class with a customized list view box for listing all tasks.

The application framework also provides a few other classes that inherit from the Page class with additional implementations. The View Attributes page, for example, will display a feature's attributes on a page for viewing purposes. Therefore, you don't need to worry about how to organize the attribute information on the page or anything else. The List View page is another example, which has a built-in list view on the page that can hold a ListViewItem collection.

MapPage

MapPage is widely used inside the application. It provides the main real estate for presenting geographic information. For example, it's used in the View Map task for map viewing and the Collect Features task for data collection.

As resources on mobile devices are rather limited, creating your own form or page that encapsulates a map component will be very expensive and hence affect application performance. Therefore, you should always use the shared MapPage when you need a map.

Get more details on how to customize MapPage.