Collector Crashing on iPad while in offline mode

[EmilySangster1]

Hello,

One of our field crews is experiencing frequent crashing of the collector app on the iPad and also lots of lagging.  The iPad is iOS 8.3 and is up to date and the service has about 2500 points with 290 attachments.  There's about 50gb of space available on the iPad so I don't think it's a storage space issue and it works fine in other iPads and in a connected environment.

We're using ArcMap 10.2.2, ArcGIS server 10.2.2 and SQL Express 2008 R2 to store our enterprise geodatabases.

If anyone has any tips or solutions it would be greatly appreciated!

Cheers,

Emily

[ScottPrindle]

Hey Emily,

What is the area of interest you selected when downloading the data compared to the full dataset? Also, has the schema of the feature service been changed at all (eg. new fields added, domains updated, etc.)? What are you attempting to do when Collector crashes, is this when the app is opened, when attempting to collect a feature, when syncing, etc? Does the same behavior exist on other iPads when downloading the data to edit in a disconnected environment? Any clarification you can offer may help us to better dissect the issue.

Thanks,

-Scott

[EmilySangster1]

Hi Scott,

Sorry for the delayed reply! Here are the answers to your questions.

What is the area of interest you selected when downloading the data compared to the full dataset?

The area of interest was fairly large since our field crew was going to have limited access to internet and didn't want to sync, delete and download a new area each night.  The area is pretty huge.  It's ~32,000 km.  Is that too large?

Also, has the schema of the feature service been changed at all (eg. new fields added, domains updated, etc.)?

The schema did change but the service was overwritten and the map was deleted from the iPad and downloaded again to get that update. 

What are you attempting to do when Collector crashes, is this when the app is opened, when attempting to collect a feature, when syncing, etc?

The main issue seems to be a huge lag when submitting a point.  Our crew takes 2-4 photos per feature and to submit that point to be stored on the device takes ~3 minutes when I try in the office.  The app had also crashed upon opening. In the office I caused it to crash through the measure tool. 

Does the same behavior exist on other iPads when downloading the data to edit in a disconnected environment?

It's been replicated on an iPad in the field as well as in two different offices.

The iPad takes photos which are ~2 - 2.5mb.  Could photo size be problem? I can't find a way to take lower resolution photos with an iPad. 

Are there any ways to optimize the project to speed it up to prevent lag?

Cheers,

Emily

[ScottPrindle]

Hey Emily,

The size of data being downloaded shouldn't be a limiting factor, but I would recommend downloading data for the area they will be working in to ensure that isn't the case. To test this out, can you use one of the mobile devices that exhibited this behavior in the office and delete its downloaded dataset? When downloading the data again, choose a smaller area of interest, closer to the area a field worker would cover in one day. Does the application delay in the same way it did previously? About how many features/attachments were downloaded to the device?

Since you've overwritten the service and deleted the disconnected dataset from the device, there should not be a difference between what exists in the service and what exists on the device. As an additional step in this process, could you also create a new web map to see if the behavior remains after a new service, new web map, and new download are used?

What does the data look like that you've published to ArcGIS Online for this service? Are there many related tables? Are there any SQL reserved words for field names (ex. FILE, ADD, SCHEMA, etc.)?

The size of the photo attachments should not be a concern. It sounds like the slow performance you're seeing is occurring on the device itself when committing edits and attachments to disk. The tests and questions above can help us narrow down where the issue may be occurring. Please let me know if you have any other questions or additional information.

Thanks,

Scott

[EmilySangster1]

Hi Scott,

There are two maps in question which are experiencing the same lag which are referencing different feature classes. The feature classes for both maps share the same gdb on our server, have the same domains and the same symbology. I checked the field names for reserved words and there aren't any as far as I can tell.  The only related tables for the data are the attachment tables since each layer has attachments enabled. 

When either map is downloaded with a smaller study area the submission of a point takes about 5 seconds.  When the downloaded map is deleted and the map is edited while connected to WIFI the submission of a point is also ~5 seconds. 

I created a new service and map for each of the two versions and am experiencing difficulty downloading them with the full study area.  I've attempted on multiple devices and the download fails or creates an incomplete map.  The first map has 1669 points with 1839 photos attached and the second map has 905 points with 949 photos attached.  Some of the layers have many points while some have less than 10. 

Would it be beneficial to create a separate service and map for each layer to see if a specific layer is causing the issues?

Thanks,

Emily

[ScottPrindle]

Hey Emily,

It can definitely be helpful to separate layers and try to isolate any problematic ones in their own feature service/web map. This can help determine if the performance issue you are encountering is data specific, or if it is elsewhere.

When this data is successfully downloaded to your device, what is its size on disk? This can be found by connecting the device to your computer and going through iTunes for iOS or a file explorer for Android. In the directory for ArcGIS Collector, there should be an "offline_data" folder. In here, there will be folders for each user that has logged in and downloaded data for disconnected editing. Within the user's folder, there will be other folders corresponding with each web map that has been downloaded for disconnected editing. Could you tell me the size of the folder associated with your problematic dataset?

Thanks,

Scott

[PeteCrosier]

We've seen this (3 minutes to add an attachment, black screens / lock-ups) on Android (and things you describe on iOS) with a fairly large area offline and using attachments. As you increase the amount of data taken offline the problems are amplified. Currently we're working through things with UK and US support to try get to the bottom of it - anything you can get through to the Collector team would be great!

[ScottPrindle]

Hey Pete,

How large is the area of interest being downloaded, and how many features/attachments are being downloaded? Do you have any related tables in your feature service?

Best practice is to only download an area relevant to the field worker's task. Downloading too much data can be unnecessary, and depending on surrounding field workers this can cause feature conflicts in the sync process.

That isn't to say that the behavior you are seeing is expected. I would recommend you continue working with support to uncover what exactly is causing the slowdown in your environment.

-Scott