How to quarantine async

Question

Hi,

Esri's usage of async looks all very well for completely new code.

However, we have a very large existing code base that runs on ArcGIS and a couple of other platforms. We are struggling to see how we can use a lot of our existing code within both the new ArcGIS Pro async model and sync platforms like ArcGIS, AutoCAD & Microstation.

Async can be a bit like a virus in a codebase - once you start putting it in you have to follow it right through the codebase. That's fine for tiny little apps but for a large existing codebase - major rework.

Any advice on how we can turn async back to sync safely without breaking ArcGIS Pro.

Thanks in advance,

Adam

AdamDavis · Answer

Hi Charles,

Thanks for that.

I was thinking of something a little more complex.

We have products that have similar functionality on AutoCAD, Microstation and ArcGIS. We abstract away the differences by creating an abstract CommonPlatform that binds to an AutoCADPlatform, a MicrostationPlatform, a FileGDb platform or an ArcGISPlatform depending on the underlying product.

The plan is that as we add new platforms either from new vendors or updated API's then it is a relatively simple matter of implementing the new platform calls. That's what happened when Microstation recently released a Beta of their new API. Recent AutoCAD can be used async but it's optional anyway. We are adding an ArcGISProPlatform but it's proving a bit painful due to it's async nature but I'm sure we'll get there in the end.

2 separate codebases could be created (in our case 6). Any new updates to our functionality have to be replicated on all codebases. Never been keen on that solution which is why we went with the platform idea.

We, probably like many ESRI Partners, are looking at Pro and wondering how best to refactor our codebases in the most efficient and cost effective way possible. Any tips, examples etc that help us towards tha goal will save a monumental amount of time and resources in comparison to us all reiventing the same wheel.

Thanks

Adam

CharlesMacleod · Answer

Hi Adam,

This is not possible. 10.x .Net SDK APIs are 32 bit ArcObjects (AO), single threaded and (must) reference PIAs installed as part of the AO SDK. Pro is 64 bit and multi-threaded. Pro Add-ins do not use the AO PIAs and are not COM.

The closest you can come to a single codebase would be if you were developing exclusively in python on top of arcpy.

You can find an FAQ here which explains more of the new Pro API and transitioning from ArcObjects:

http://github.com/Esri/arcgis-pro-sdk/wiki/FAQ

AdamDavis · Answer

Hi Thomas,

Thanks for your reply.

That was precisely my point.

If we use await in a function then that function has to be marked as async and so it goes on up the entire stack. At some point we want to sync up and also be guaranteed, for instance, that the FeatureClass we create in code (annoyingly via Geoprocessing) has been created before we make a field, before we then add a row etc etc.

That's fine for greenfield development but adding this to a large existing codebase is going to require major rework. The time (and therefore also cost) of updating the code to work with Pro will affect both when we can release a version for Pro and and indeed whether it is commercially worth it.

Given that Esri decided to go all asyncy with it latest API; does Esri have any tips on how best to manage a single codebase that functions under both ArcGIS and Pro? Perhaps a reasonably complex example that can be compiled to cover both platforms.

Thanks,

Adam