Tasks overview
Often times, geographic information system (GIS) web applications need to include geospatial functionality that goes beyond simple map display and interaction. You might, for instance, need to give your users the ability to view the locations of projects that are on schedule, find parcels that are within a certain distance of a river, or plot the area within a five-minute drive of a proposed store location. For these types of functionality, the ArcGIS API for Windows Phone provides a set of task classes. These classes allow you to easily write application-specific code to extract information from ArcGIS Server services and present that information to your users. The application programming interface (API) includes the following tasks:
- Query—Get features from map services that satisfy attribute queries.
- Identify—Get features from map services that intersect a location.
- Find—Get features from map services that contain a particular value in their attributes.
- Address locator—Get the location of an address (geocode) or the address of a location (reverse geocode).
- Geometry—Perform geometric operations such as buffering, projecting, and simplifying.
- Geoprocessing—Perform complex GIS analysis by executing geoprocessing models that have been published as geoprocessing services. See What is ModelBuilder? for information on geoprocessing models, and An overview of geoprocessing with ArcGIS Server for information on geoprocessing services.
- Route—Solve routes and provide directions between a defined set of stops while taking into account parameters such as barriers, stop order optimization, time windows, U-turn restrictions, and impedance.
Usage
While the functionality of the tasks provided by the ArcGIS API for Windows Phone varies widely, the use of each is standard in many ways. First, tasks do not define user interfaces (UIs), so to allow users of your application to interact with a task, you must provide an interface for specifying the task's input and displaying the task's results. Second, the task classes will always be created in the non-visual areas of your application—either in a Resource Dictionary or in your application's .NET code (that is, code-behind). Third, tasks will always be manipulated in code-behind. This is because each task encapsulates a piece of GIS execution logic that is independent of any visual components. In Windows Phone development, an application's .NET code is the place for execution logic, making .NET code the appropriate place to manipulate the task classes.
Beyond these broad similarities, the code required to execute and process the results of each of the different tasks also follows a pattern. To initialize any task in code, you'll always pass the URL of the service or layer that the task will use to the task's constructor. The following code is an example of initializing a Find task:
FindTask findTask = new FindTask("http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Demographics/ESRI_Census_USA/MapServer/");
Before using one of the task's operations, you need to define the operation's input parameters. These parameters will vary depending on the operation. The following code is an example of initializing the parameters for the Identify task:
IdentifyParameters identifyParameters = new IdentifyParameters();
identifyParameters.LayerOption = LayerOption.all;
identifyParameters.MapExtent = MyMap.Extent;
identifyParameters.Width = (int)MyMap.ActualWidth;
identifyParameters.Height = (int)MyMap.ActualHeight;
identifyParameters.Geometry = args.MapPoint;
The Query, Find, Identify, and Route tasks can each perform one operation. For the first three of these tasks, the method to initiate the task's operation is called ExecuteAsync. For Route, the operation is called SolveAsync. In each case, the method accepts one argument that defines the operation's parameters.
queryTask.ExecuteAsnyc(queryParameters);
For these tasks, an event is fired when the task's operation is complete. The name of the event follows the name of the operation. So for tasks with an ExecuteAsync operation, the completion event is called ExecuteCompleted. For the Route task, the event is called SolveCompleted. The task's results are passed to the second parameter of this event's handlers as shown in the following code:
// Wire the ExecuteCompleted handler.
findTask.ExecuteCompleted += FindTask_ExecuteCompleted
.
.
.
FindTask_ExecuteCompleted(object sender, FindEventArgs args)
{
// Handle the task's results.
}
The first three of these tasks—Query, Find, and Identify—also have a property, LastResult, that contains the most recently generated set of results. This property is useful for using Silverlight data binding to automatically update results displays whenever a task has executed or for storing the set of results for later reference.
The other three tasks—Address Locator, Geometry, and Geoprocessing—all follow a similar usage pattern, except that each of these provides access to multiple operations. So for these tasks, the execution methods are called <operation name>Async, the completed events are called <operation name>Completed, and the results properties are named <operation name>LastResult. For example, the Address locator task has an operation called AddressToLocations. The method to initiate the operation is AddressToLocationsAsync, the event fired when the operation is complete is AddressToLocationsCompleted, and the property that holds the last set of results is AddressToLocationsLastResult.
Each of these tasks is explained in greater detail in the other topics included this section.