MLMarkerTracker default "settings" prevents starting the tracker

So I ran into a bit of confusion at first when switching from the old MLBarcodeScanner to the new MLMarkerTracker and figured I'd give a piece of feedback. Previously, you could create a new MLBarcodeScanner.Settings and then pass that into StartScanningAsync and it would start up the scanning provided that the EnableBarcodeScanning is false (since that is not a field to start the barcode scanner but rather a status field as to if it is currently scanning). The new marker tracker keeps this paradigm but there is some weird behaviour that seems to be happening due to the way that the instance calls StartAPI.

When calling MLMarkerTracker.StartScanningAsync to start the scanner, it checks the Instance.settings.EnableMarkerScanning for if it is true. This instance subsequently instantiates the lazy singleton, which in turn calls StartAPI. StartAPI's implementation calls MLMarkerTrackerCreate with the settings field, which is set at class creation to "Settings.Create(true, MarkerType.All);". Back in StartScanningAsync, the check then sees that EnableMarkerScanning is true, and it subsequently returns silently.

Ergo, if the user simply does "await MLMarkerTracker.StartScanningAsync();", which previously would work, the api does nothing.

Ultimately, the solution here is probably to have the Settings.Create set the EnableMarkerScanning to false (it's not turned on by default) OR it should do a check to see if instance is null and then pass that EnableMakrerScanning test (probably not possible due to protection level but i suppose you could create a general "HasInstance" property or something) but additionally it may be worth having that EnableMarkerScanning return a bool through the Task stating if it successfully started.

A current workaround is to call SetSettingsAsync beforehand and explicitly set EnableMarkerScanning to false in the passed MLMarkerTracker.Settings parameter. This call also can silently fail, for what it's worth (based on permissions, likely) and this will also fail silently when it actually has a resultcode that could be passed back out through the Task.



@peter.nolen Thanks for the insight. I'll make sure our SDK team sees this. Currently, the recommended method to use the Marker Tracking component is detailed here: Magic Leap but your feedback is greatly appreciated!

1 Like