Xamarin Forms - MapView.SketchEditor.StartAsync right after pinch to zoom

Question

Ok so we have the mapview.sketcheditor.startasync with a freehandpolygon in a loop and we can draw the polygon and geometry is returned, we can then keep drawing polygons one after the other with no problem.  We then pinch to zoom the map and the first mapview.sketcheditor.startasync after that doesn't draw a freehand polygon but instead pans the map and returns a null geometry,  after the pan we can then draw a polygon.

This feels like an Esri bug.

1. Has anyone else experienced this?

2. What did you do to get around it?

Thanks

Paul

PaulFarrow1 · Answer

So I tried this before in our application and had issues.  I tried it in my little example I gave you guys and it appears to work but within our application I hit what I hit before which is I  seem to have a cascading cancel exception which doesn't allow the sketch to continually loop.  I have put a couple of days effort into this over the week since you posted and I still cant get it to succeed successfully in our application.  Is this something I could screen share with you or are we closer to getting a proper fix for this?

RichZwaap · Answer

I believe I've found a workaround for this issue.  Essentially, it involves listening for the MapView's NavigationCompleted event, then, when fired, forcing completion of the current freehand polygon sketch, replacing the MapView's SketchEditor instance with a new one, and starting a new freehand polygon sketch with the completed sketch's Geometry.  I've attached a sample that encapsulates this workaround in an extension method to the MapView called SketchFreehandPolygonAsync.  That method can be called in place of MapView.SketchEditor.StartAsync.  Although stopping and starting the sketch session and replacing the SketchEditor on navigation completion seems a bit heavy-handed, it seemed to work without any notable side effects in the bit of testing I did on an Android and iOS device.

Hope this helps.

FreehandSketcher.zip

PaulFarrow1 · Answer

UPDATE: Just in case any one else is facing this issue - I logged a support call and ESRI agreed its a bug in the 100.2.1 runtime and has been marked as a bug with the tracking id of BUG-000114899.