GetFeatureDataAsync obsolete?

[StephenDickinson]

Hi,

Using the MobileService class I get informed by Visual Studio that several methods are obsolete including methods used in previous versions to download data from the server to the mobile cache.

I can still use these methods but should I now be doing things differently given their marked status?

Thanks,
Steve

[StephenDickinson]

Hi,

Still waiting to hear back on this...

Has the recommended way of synchronizing data using the ArcGIS Mobile SDK changed from 9.3.1?

Thanks,
Steve

[JU]

http://resources.esri.com/help/9.3/arcgismobile/adf/ESRI.ArcGIS.Mobile~ESRI.ArcGIS.Mobile.MobileServ...

Not seeing anything in the help that states to use something different but the above link contains all the overloaded methods that pertain to this particular method.  Try using some of those and see if it likes them better.

[JohnHauck]

It was my understanding that the MobileCacheSyncAgent was the new way to handle synchronization.

Here is a brief example:

    MobileCache m_mobileCache1;

    private void button_Click(object sender, RoutedEventArgs e)
    {
        m_mobileCache1 = new MobileCache(@"C:\YourCache");
        createOpenCache();
        //openExistingCache();
    }

    private void openExistingCache()
    {
        m_mobileCache1.Open();
        Map.MapLayers.AddRange(m_mobileCache1);
    }

    private void createOpenCache()
    {
        if (m_mobileCache1.CacheExists)
        {
            m_mobileCache1.Close();
            m_mobileCache1.DeleteCache();
        }

        MobileServiceConnection con = new MobileServiceConnection();
        con.Url = @"http://YourServer/arcgis/services/testsearch/MobileServer";
        con.CreateCache(m_mobileCache1);

        m_mobileCache1.Open();

        MobileCacheSyncAgent agent = new MobileCacheSyncAgent(m_mobileCache1);
        agent.MapDocumentConnection = con;
        agent.DownloadExtent(m_mobileCache1.GetExtent(), 0, 0);

        Map.MapLayers.AddRange(m_mobileCache1);
    }

[StephenDickinson]

Thanks for your reply.

Looking at the MobileCacheSyncAgent Class there is a big reduction in the number of available methods to sync data when compared to the 9.3.1 MobileService class.

I also see the MobileCacheSyncAgent Class has a Synchronize method.

I'd really like some more info on how the DownloadExtent and Synchronize methods work e.g. what they do, when to use which, etc.  Do you have any further details?

Thanks,
Steve

[StephenDickinson]

Just to follow up on this, each layer now has its own layer sync agent object which can be configured independently regarding sync behaviour.  This takes the place of the various overloads and parameters that existed previously for the sync methods of the MobileService class.

[DavidMarley]

Yes, from what I have heard, this is true about the layer synch agents.  These layer synch agents are supposedly much more flexible and powerful than the synchronization options we had at 9.3.1 and before -- which would be welcome news if this were true. 

I have not had the opportunity to check out the version 10 layer synch agents in detail though, so I don't know anything in the way of specifics.

[StephenDickinson]

Dave,

My initial investigations have shown that these seem to work well.  One behavioural change that stands out is that changes made in the geodatabase can now be downloaded to the mobile cache upon synchronization automatically.

On the face of it this is really good as it does away with the need to have one or more supplementary (non ArcGIS Mobile SDK) processes that fulfill the role of identifying changes between mobile cache and geodatabase pre SDK synchronization request.

However, I have found that quite a bit of traffic is communicated upstream during the synchronization.  I guess this is currency information being pushed from the mobile cache to AGS so a call can be made on what data to send back down the wire.  For small extents of data this doesn't seem to be an issue but for large extents of dense data this can be expensive in terms of upstream data volume and synchronization duration.  A case in point is were there are no changes to the data but all the currency data for the extent in question has to be communicated to AGS in order to determine this fact.  I assume this has to be done as no state information is maintained server-side so the currency landscape for a given mobile cache instance needs to be built up for the requested layers and extent each synchronization request.

This leaves me still thinking about implementating a supplementary process (AGS API, custom web service, etc) to determine what has changed that feeds into the SDK sync methods to get just the data I want.

Steve