Specify valid Barcode Symbology for a scannable column

I’m loving the barcode scanning capabilities - it’s in fact the reason we’re using AppSheet!

However the current barcode implementation is very aggressive with its detection, if multiple barcodes are in the field of view it’s impossible to control which one it picks up!

This often happens with courier labels which can contain multiple types of barcode on a single sticker.

So we are using fingers, hands, cardboard to mask out barcodes before we hit the barcode scan button which gets a bit ridiculous at times!

Am I missing a config option somewhere?

It would be HUGELY beneficial to be able to pick the allowed barcode type for a column when marking it as scannable. I’d picture an enumlist appearing when you mark a column as scannable so you could pick one or more valid types.

Eg to be able to say that the column “tracking number” is only Code128; that the column “order number” is one of QR code or Datamatrix; the column “vendor code” is any valid scan etc

This alone would solve most of our issues.

Even better would a validator function that prevents the scan modal dismissing unless a barcode is evaluated as valid.
Eg a valid barcode might be “type:QR” AND “starts with:ORDER” AND “length = 35
Chars”

You may not be aware, AppSheet is simply utilizing the built-in feature of the mobile devices camera to read barcodes and QR codes. AppSheet has no control over the targeting or sensitivity of that scanning.

There may be some way AppSheet can determine the type of the code scanned (I haven’t used QR codes so not sure how they behave) but for validation that would be on us developers…and in fact I think that is something we can do now within the Valid_If property.

But the above won’t help with targeting the correct code. Hardware changes, i.e. mobile device changes, would be needed.

For what it’s worth, I have read, some time ago, in the Community of others being able to successfully integrate a 3rd party scanning tool with AppSheet. Maybe that’s an option - integrate a dedicated barcode reader that has targeting capabilities?

1 Like

Hi John - I’ll experiment more with the Valid_If to see if it is flexible enough, it certainly can help prevent saving a bad scan, but I don’t think it can stop it making one in the first place.

With regard to built in scan behaviour not being modifiable, that’s not quite correct.

Both Android and iOS expose rich APIs regarding barcode detection to developers, AppSheet are then using https://www.scandit.com/ which is a wrapper around these to make it easier for them to integrate with both platforms from a single code base.

Scandit itself exposes this facility Configure Which Barcodes Are Read — Data Capture SDK 6.7.1 documentation so in theory, it should be pretty straightforward.!

Yes, I realized this was probably the case after I posted (I hadn’t given it much thought). I guess my main point was about targeting the desired barcode. Most stand-alone scanners have a targeting “cue” that dictates which barcode to read - point and scan. Mobile devices do not have that capability … yet.

I suppose you could implement it through software by allowing the user to touch the screen to indicate which barcode they wish scanned. Not as efficient. But then we are talking about convincing the 3rd party software provider to build in that capability OR for AppSheet to build their own scanning ability into the device-specific container apps.

It still is a good conversation to have and good Feature Request for improvement of the AppSheet platform.

Actually I’m not explaining it very well I suspect!

Currently, the scan window closes and returns a value as soon as it finds any proper barcode, if there are 5 in the field of view it could be any one of them.

In a typical app however you are searching for a specific type of barcode for that column - generally, one that you are printing elsewhere in the company. eg we use Code128 for inventory labels on our shelving.

So with that in mind, the desired behaviour is that when marking a column as scannable in the data tab, you would nominate the allowed barcode types that the scanner responds to as well.

Then when a user triggers any scan window for that column, it would only look for the nominated types and ignore all others.

It sounds a little complex, but it’s actually a very straightforward change with the scandit SDK as behind the scenes every scandit window instance is already asking for either a list of specific types to hunt for, or it defaults to looking for everything.

I run out my votes, but this is making sense.
Currently Appsheet is wise enough to scan any codes, but this intelligence may cause the problem. I leave pet bottle beside me and open the app to scan inventory , but before i shift to the product , it may wrongly scan the code on the pet bottle etc. etc.
It should be okey, to set all type of code by default, but wish to have control to define what type of the code is scannable by this field.

1 Like

I do understand and I believe beefing up the barcode usability is a great Feature Request. However, I am still unclear how what you have requested, specifying a barcode type for a column, will solve your problem of detecting the wrong barcode.

How do you select the correct barcode when there are 5 of the same type of barcodes in the view? Say 5 Code 128 barcodes? Which is probably most likely when using a scan sheet as companies tend to use the same bar code type for everything.

Quite correct, it wouldn’t!

It is however a relatively easy change that would help enormously for a lot of use cases :grinning_face_with_smiling_eyes:

The second part of the feature request was a bit more involved but aimed at helping with that scenario and that was to allow for custom string validation prior to dismissing the scandit instance.

So as an example, our order number QR code’s always start with the prefix “OLC-“ or “SSO-“ so we you would say that a scan is valid only if it is of type QR and starts with either prefix.

If it’s not valid keep scanning until a match is found or the scan is manually canceled. This would work very well for a lot more scenarios.

A real use case we have today is scanning our outgoing parcels for tracking, this involves detecting 2 codes that are generally always in the same frame, our order code (known format and type) and the carriers code (one of 4 variable formats and types). Right now this is really painful, but either of the tweaks I’ve described would fix it.

Now of course there are still cases where multiple valid codes could be in the same field of view - eg imagine having a purchase order where each line item has a barcode of its sku against it. There could be a dozen on a single page.

Well it turns out scandit have a couple of optional modes to help with this too, redline scanning and scan and confirm: Scandit Barcode Scanner for Android: Select one barcode among many

All in all there’s a lot of opportunity for easy tweaks to the existing scanning system to significantly improve it without having to completely reimplement it :grinning_face_with_smiling_eyes:

image