Best practices for populating overlays asynchronously

[JustinSteventon]

Hi folks,

My app shows a map and populates graphic overlays from my local database. It is a data collector app and over time there can be a lot of data. Today, I populate it from the main thread and so this means it can take a while to load.

Should I move the work to a background thread, or would you recommend something like dynamically creating a geodatabase so the framework can manage everything?

Thanks!

[JaredCaccamo]

Hey @JustinSteventon, thank you for posting this question!

Should I move the work to a background thread

Loads should be asynchronous so this shouldn't be necessary and i don't believe it would improve the loading speed.

Could you provide a code example of your workflow so I can better understand what is going on?

Cheers!

[JustinSteventon]

Sure, I've attached an example. You will need to add an api key.

This is just the sample template with populating a GraphicsOverlay in setMapView.

[JaredCaccamo]

Thank you for providing this. May I ask what you experienced in terms of "take a while to load"?

[JustinSteventon]

Hi Jared,

The sample shows that there is a large startup delay, due to adding a million points to an overlay on the main thread. This is representative of what I am doing.

Is it recommended that I simply move this work to a separate thread and then move the created objects back to the main thread before handing them off to the engine?

Since the SDK is closed, it is hard to know the most efficient method based. Maybe it is better to dynamically create a temporary geodatabase so all the memory management and caching is handled internally? My scenario seems fairly mainstream, so looking for best practices.

Thanks!

[JaredCaccamo · Accepted solution]

Hey @JustinSteventon ,

I discussed this with a colleague and got some feedback I wanted to share.

1. Since you are reading a lot of data from a local database, that could be a choke point.
2. If you are adding graphics to the overlay as you are reading them in, then you would definitely want to use a side thread for that.
3. Generally you workflow sounds like it would be a good candidate for using a Feature Service which can be easily used in offline mode as well. This workflow is much more optimized. There are a handful of ServiceFeatureTable samples which you can reference, https://github.com/Esri/arcgis-maps-sdk-samples-qt/tree/main/CppSamples/Features

I would investigate more as to where exactly the slowdown is happening and where most of the time is being spent. Once we know which part that is, we can narrow down more on improvements for your use case.

Cheers! 

[JustinSteventon]

Thanks Jared, this is helpful.

The ServiceFeatureTable is in-memory and not persistent, so I would need to build it every time - much the same as the GraphicsOverlay.

It looks like a more scalable solution is to maintain an asynchronously built geodatabase as a cache. I will have to figure out good ways of ensuring it is properly synchronized with my database, but at least that gives the engine the best shot and managing memory and rendering quickly.

Cheers,
-Justin