Flash: As of Flash Builder 4.5.1, apparently you’re golden. It does iOS, Android, and BlackBerry apps as well.

JavaScript: ESRI’s JS APIs work in mobile browsers too. Sprinkle some PhoneGap goodness in the mix to access select native APIs and deploy as a native app.

C#: MonoTouch and MonoDroid let you deploy C# applications to iOS or Android devices.

Overall Object C is a hard sell when – in many cases – you can recycle your existing codebase into a mobile application.

• Direct binding from DataGrids (and other things too!) to the FeatureLayer
• Supports easy client-side text-based querying
• Support for custom, function-based querying
• Supports spatial-filtering for grid-results based on map extent
• Supports feature hiding/showing based on grid-results
• Grid items “===” FeatureLayer items, no reassembly necessary
• Usable without a grid for rich, client-side control of feature visibility

Presenting “GraphicsLayerStore” v 0.1.

I’ll spare you the inlined code, just compare my example with the ArcGIS Server Blog’s example.

There’s some decisions to make when using a Dojo DataGrid and ArcGIS JS API Map. First off, the Dojo DataGrid doesn’t act alone, it needs a data store like an ItemFileReadStore or a QueryReadStore. A ItemFileReadStore is like running a FeatureLayer in SNAPSHOP, where you’re storing all the data in memory and can query it on-the-fly. A QueryReadStore is like ONDEMAND mode, where you’re frequently querying for new data.  Note the additional parallel between the user-interface only elements of DataGrid/GraphicsLayer, versus the DataGrid+Store/FeatureLayer solutions which also query and store data.

So if you’re using a DataGrid, you’ll have at least some data duplication between your FeatureLayer and your DataGrid’s store. You should never need to use a QueryReadStore and an ONDEMAND FeatureLayer at the same time; there is no reason to download data twice.  Similarly, it makes little sense to fully populate a DataItemStore and a SNAPSHOT FeatureLayer.  It is most sensible to duplicate only the slice of data which the other needs.  But which user-interface item drives which?  Do map events feed data to the grid or visa versa?

Lets first examine the DataGrid.  Deciding what subset of data to share with the map is difficult. Out of the box, the Datagrid cannot page data, nor easily determine what items are visible on screen (fix: override grid.scroller.repositionPages() and recalculate grid.scroller.firstVisibleRow). The ItemFileReadStore doesn’t support spatial queries, only regular-expression type queries (fix: override ItemFileReadStore._fetch()).  Finally, JSON loaded into a ItemFileReadStore gets “normalized” into arrays, in other words, terribly mangled.  Put a Feature into a ItemFileReadStore, it won’t come out as a Feature per-se, and will require some cleanup to be added to the map (fix: essentially rewrite ItemFileReadStore).

If I haven’t deterred you from even thinking about populating a GraphicsLayer from a DataGrid/ItemFileReadStore, lets look at the alternative. FeatureLayers do not support sorting. Your grid requires sorting, and it also requires reading from a Dojo.Data.Read API source… You’ll be re-populating an ItemFileReadStore during either onUpdateEnd or onExtentChange, so the grid can access it. SNAPSHOT FeatureLayers cannot filter clientside by “text” or “where” clause, and will force an ONDEMAND style query. Another useful point here that Querying an ONDEMAND FeatureLayer for data doesn’t automatically change Feature visibilities like setDefinitionExpression(), so any clientside-filtering-solution must be wired up by hand.

I  have found that populating a DataGrid/ItemFileReadStore from a FeatureLayer is usually the easiest solution. This option could be made more interesting by extending the FeatureLayer class to support the Dojo.Data.Read API, allowing the DataGrid to read directly from the FeatureLayer.  However, there are certain circumstances where populating a GraphicsLayer from a DataGrid/ItemFileReadStore becomes an intriguing.  Supporting non-ArcGIS-Server datasources or allowing robust clientside querying are two potential reasons — but be prepared to rewrite ItemFileReadStore.  That said, if you’re attempting either of these hacks, go full-barrel and do them both.

Try, for instance, to draw 600 circle features on a map. For probably 80% us, it’ll perform quite nicely. These 80% of us use Firefox. Performance in IE simply doesn’t make sense… why should panning the map cause a ~1 second delay? Well, firing up the JavaScript profiler we can track the issue to a little function called _applyTranform().

Dojox.gfx.Shape._applyTransform() gets run from esri.layers._GraphicsLayer._onPanHandler(). It individually repositions each feature, whenever the map pans. Let me say that again. It individually repositions each feature, whenever the map pans. Worse yet, _applyTranform() is not run only on pan-end, its is run multiple times throughout the pan. Panning for approximately 5 seconds resulted in _applyTranform() running 40 times, for 2.7s of the 3.3s of total JS runtime. Most of this seems to be DOM/CSS manipulation, though matrices manipulation and Number.toFixed() also factor in.

Two quick alternatives were checked: bulk replacement of the VML, versus moving the entire drawing surface via CSS. Bulk VML replacement via DOM.innerHTML showed no subjective benefit on initial testing.  Panning the drawing surface instead of each feature DID show a significant subjective speed improvement.

Clearly, the performance of Graphics rendering in the ArcGIS Server Javascript API is poor in IE/VML. This issue is literally built upon the Dojox.gfx API; which needlessly complicates the task at hand.  OpenLayers, for instance, does not exhibit such beleaguered panning performance.

An ItemFileReadStore asks the server for data once, and then supplies chunks of it to the DataGrid as needed. If your dataset is small enough to cache/filter clientside, it’s your ticket. ItemFileReadStore implements the Dojo.Data.Read API, which allows you to supply queries to filter your data. Using the ItemFileReadStore’s query functionality is the intelligent alternative to repopulating the ItemFileReadStore’s data every time we change map extents. Except you can’t use ItemFileReadStore’s for spatial queries … it is limited to simple text and regular expression queries.

Instead of living with this limitation, we can subclass the ItemFileReadStore to add functionality. Although this involves overriding the private function “_fetchItems”, the use of “_fetchItems” is specified within the SimpleFetch mixin, and is therefore less likely to change as Dojo grows.

/* subclass ItemFileReadStore so that we can override the _FetchItems method to support custom queries */
dojo.declare("custom.QueryReadStore", dojo.data.ItemFileReadStore, {
    _fetchItems: function( keywordArgs, findCallback, errorCallback) {
        /* substitute this code into ItemFileReadStore's _fetchItems code around 32 lines in */
        if(typeof value == 'function') match = value(arrayOfItems[i]);
        else if (!self._containsValue(candidateItem, key, value, regexpList[key])) match = false;
        /* end substitution */
}}};

/* wire up events to refresh the DataGrid when the map's extent changes */
/* note that the filter must be explicit set each time; calling render is not enough, */
/* we are filtering on dynamic variables; the DataGrid caching mechanism weren't built for this */
dojo.connect(myMap, "onExtentChange", function (extent, delta, levelChange, lod) {
    myGrid.filter(customQuery: function(item) {
        return myMap.extent.intersects(item.geometry[0]);
   }, true);
});

Another, perhaps more interesting option would be to subclass ESRI’s GraphicsLayer. Implementing the Dojo.Data.Read and Dojo.Data.Identity APIs would allow the DataGrid to be driven directly from the GraphicsLayer feature data attributes.

ArcGIS can clearly reproject raster imagery; the trick to getting these Mercator tiles into ArcGIS Server. The solution is to pretend that these tiles come from *another* ArcGIS Server. I’ve written about creating custom code to impersontate ArcGIS Server for feeding ArcGIS Desktop. Using this method, its quite simple to create an MXD that consumes Google Earth tiles, and then publish this to ArcGIS Server. (Note that this must be published as an MXD, MSD-based services allow only local data).

Summarizing the basics here we have 1) getting tiles into ArcGIS Server for reprojection 2) reprojecting and delivering these tiles with ArcGIS Server. The first part is accomplished by pretending to be ArcGIS Server, while the second step is performed by an actual ArcGIS Server. I’ll spare the lecture on how actually doing this would violate dozens of laws, copyrights, terms of use, etc….

Can anyone recommend any XSD-cleanup tools or processes? Thanks in advance.

ArcGIS Server ships with WSDLs. They’re pretty nice, really. You can hit them with your favorite stick (svcutil.exe comes to mind) and you’re got a pretty nice client library for talking to ArcGIS Server. With the same stick, could equally created a web-service that looks just like ArcGIS Server.

Some tech tips: Not much tweaking is necessary to get svcUtil-generated code up and running. Note that ArcDesktop uses the same SoapAction header for all AGS requests. In WCF, this means you need a custom Route Dispatching behaviour. Verify that you’re using basicHttpBinding in your web.config. Also, watch your namespaces… initial requests come in looking for ArcGisServer/9.0, later namespaces will reference your current version.

That’s it. Now when can I see this in MapServer and GeoServer? In the Cloud?