Pitney Bowes MapXtreme - Manual (Page 503)

Appendix D: Extensible Data Providers
Building and Testing Your Data Provider
MapXtreme v7.1 510 Developer Guide
Building and Testing Your Data Provider
Building a data provider is a complex task and is difficult to debug because most of the calls into
your data provider code is made by MapXtreme. You will want to build up your data provider in
stages and test just the pieces that you have implemented as you go. To better control this, you will
probably want to start with a sample project that allows you to write code that exercises only what
you expect to be implemented and you can expand this sample as you expand your data provider.
You shouldn't include this directly into your data provider project; however, Visual Studio allows you
to create multiple projects within a single solution.
If you have a data source as part of your data provider model, you will want to start there. Create an
implementation of IDataSourceDefinition and IDataSource and try using the
Catalog.DataSources.OpenDataSource method to see if MapXtreme calls into your data provider
and ends up with your data source object in the DataSources collection.
The first major milestone for the table model is to be able to open a table and display the table's
metadata. You can develop and test this without writing any searching or cursor code which is far
more complex. You will need to create an implementation of ITableDefinition, ITable, and
ITableMetadata. Initially you can implement the search and modify interfaces to throw a
NotImplementedException. In your test application you should then be able to create and populate
an instance of your table definition class, instantiate a table by supplying this definition to a call to
Catalog.OpenTable and then examining the column definitions that are supplied by the table's
TableInfo property. The column definitions should accurately reflect the information your table
metadata supplies to MapXtreme including the appropriate coordinate system, data bounds, and
default view for your geometry column(s).
The next step to build out and test your provider is to add very simple search logic and a provide a
cursor implementation. In your test application, you can add a simple block of code like this:
Table table = catalog.OpenTable(myTableDefinition, "MyTable");
foreach (Feature feature in table)
{
// inspect the feature, write out values to the console, etc...
}
For this code to work, you will need to implement the ITable.SearchAll method and provide a cursor
implementation. You will also need to provide a key implementation and the features returned in the
code example above should reflect the appropriate value for your key (although values are
serialized to strings).
Once you have this basic level of code working you can start to test your data provider in a map so
that you can see visual results to see if the geometries are being returned as you expect, with the
proper styles, etc. You will require some implementation of SearchByEnvelope before you do. You
can ignore the areaOfInterest argument and return all records initially just to see how the data looks.
Your performance will be poor since every request will retrieve all of the features. You should turn off
the InfoTip property on your layer which will prevent MapXtreme from trying to display the InfoTip as
you move your mouse over the map. The InfoTip calls down into your data provider with a small
areaOfInterest around the point where the mouse is positioned and if you are returning all of the
table features your performance will be really bad. You will also not be able to test selections or
result set capabilities until you have a feature accessor implemented.