Select to view content in your preferred language

Excessive time to post single update - windows mobile app

3088
4
11-17-2010 10:23 AM
DavidCarpenter
Occasional Contributor
We are in the process of testing ArcGIS Mobile for some of our field activites. To do this we are using ArcGIS Mobile v10 build 2475 and both out-of-the-box Windows and Windows Mobile OS clients. We are connecting to ArcGIS Server Adv Enterprise v10 SP1.

The feature class we are editing is large: 500,000 features (lines). Despite the FC size the application still performs well in both Windows XP and Windows Mobile environments since most display and editing is done at a large scale. The issue we are having relates to posting the updates from the Windows Mobile client (running on a Trimble Juno SC) via a wireless connection to our network.

Testing:
- When we edit one feature's attributes and post the change from the Windows XP client via a wireless connection with all 500,000 features having been downloaded prior....the process takes 3 seconds.
- When we edit one feature's attributes and post the change from the Windows Mobile client on the Trimble via a wireless connection with all 500,000 features having been downloaded prior....the process takes 40 min.
- When we edit one feature's attributes and post the change from the Windows Mobile client on the Trimble via a wireless connection with only a small subset of features (8km around current location) having been downloaded prior....the process takes 3-4 seconds.

We are trying to figure out why the Mobile application running on the Trimble takes so long to post one change only when we have the 500,000 features downloaded on the device. As we understand the synchronization process, only the changes are posted to the server. For this solution to work the field users/ contractors need the complete dataset loaded (500,000 features) but will only be updating a few features per day depending on where they are working.

Any insight as to what might be causing the excessive amount of time to synchronize one attribute change to the server would be helpful so we can figure out our next steps in this trial.
0 Kudos
4 Replies
AngelGonzalez
Occasional Contributor II
I am also noticing that in 10 it is taking longer to do a post to the server. I have a windows mobile app on a laptop written in 9.3 that I am converting to 10. In 9.3 when doing a post to the server on two layers (with no changes) it will take 1-2 second to complete. Doing the same post to the 10 server (two layers and no changes) using Synchronize() it take almost two minutes to complete. I also was under the impression that Synchronize was looking for changes only.

I am testing the Mobile 10 application on my desktop so I have no wireless issues and all caches are preloaded in the cache directory in the  mobile app. Anyone else have "Excessive time" issues?
0 Kudos
DavidCarpenter
Occasional Contributor
We have tested our laptop using wireless and wired connections to our network, as mentioned it performs well in both cases when posting updates.  The Juno can only connect to our network via a wireless connection.  As mentioned the only time it struggles to post an update is when we have all 500,000 features in our editable feature class downloaded.  We are not using the mobile map cache, we connect to the Mobile project on our server and download the data, it is also our only operational layer in the app. 

For our base map we are actually using an ArcGIS Server Cache which works really well.
0 Kudos
AkhilParujanwala
New Contributor III
This is what Buddha said in on of my threads:

If you start looking under the hood at what mobileSync is doing through debugger- it basically ends up looping through each feature layer and calling a full featurelayersyncagent on each one.
What you can do instead is loop through each feature layer, create a featurelayersync and set download direction and download filter. These greatly speeds up the sync process time.
If you still do not see the new data- try calling a map refresh.
You could also dive into your featurelayersynresult and see if any exceptions are occuring. I have found any exceptions that happen in the sync do not bubble up to the application. You have to wrtie code to check all the exceptions and if any display the error.


Mind you this was for my download data procedure, I believe something similar should work for posting updates.
0 Kudos
DavidCarpenter
Occasional Contributor
Just an update, we ended up working with ESRI Canada support and ESRI to get a hotfix which we have implemented and thoroughly tested.  This hotfix has solved the issue, posting updates takes seconds now.
0 Kudos