Feature request: Barcode scanning

cdjgreen

Something that I implement and utilize in my current web app is barcode scanning using a camera from a mobile device. This is one of the last things I would need in order to switch from Xojo. Xojo's recent barcode scanner is good enough and is pretty reliable as far as scanning goes, but does have some weak points.

It would be very handy if there could be a way to extract which camera a user selects to be able to save that to a cookie or a user settings table. The current Xojo implementation does not offer this and it creates a headache for users having to constantly re-select the right camera device. Graffiti Suite seems to only offer a rear facing camera in my testing, but that could just be my device.

Another point of feedback I've heard is auto focus issues. It could be a longshot, but if it's possible to be able to tap to focus, that would be another awesome improvement.

Garry

Thanks for explaining the use case, especially the camera selection and focus issues. Objo currently supports barcode generation, but doesn’t yet have a built-in camera barcode scanner for Web apps. This is something I’d be interested in exploring.

I agree that a scanner should expose the selected camera and let your app request it again, so you can remember the user’s preference for that device and browser. Browser privacy rules mean camera identifiers can change when site data is cleared, so it would also need a sensible fallback when the saved camera cannot be found.

Tap-to-focus is something I’d want to prototype and test on actual phones before promising support. I’d need to establish which camera controls are available through the target browsers.

Which barcode formats do you need to scan, and which phones and browsers do your users typically use? That would help me scope the feature and test it against your workflow.

cdjgreen

Thanks for the quick reply @Garry! Glad to hear this is something you're interested in!

I would be happy to test on some devices once you have a prototype you're happy with.

For us, currently we're just using the ones that Xojo supports, which is QR and Bar128. More specifically we're reading 1D barcodes in UPC-A format and Xojo reads these just fine. UPC-A is 12 digit barcodes. UPC-A format can also be referred to as EAN. In the future, we may need QR barcode, aka 2D, support as 1D barcodes for retail in the US are being phased out by the GS1.

As for the devices and browsers, it's mostly going to be iPhones with Safari. We also have some Androids with a mix of Chrome, Edge, Firefox, etc. As long as the main 4, Chrome, Edge, Safari, Firefox, work for both iOS and Android, that will be good enough for 99% of users. That's really all I'm interested in supporting anyway. If it's easier to start with just Chrome and Safari to start, that would probably cover 90-95%.

Garry

Thanks, that’s helpful detail, and thank you for offering to test on your devices.

I’ve logged barcode detection in Web apps for future consideration. I’ve captured your UPC-A requirement, potential future QR use, target browsers, and the camera selection and focus concerns in the notes.

I haven’t scheduled the work or settled the scope, so I can’t give you a timeframe or confirm particular capabilities at this stage. Your examples and offer of device testing will be useful if I take this forward.

cdjgreen

Of course! Happy to help make Objo better!

Sounds good, I will keep a lookout for when you're ready for some testing.
Looking forward to what you come up with!

Garry

@cdjgreen I've now implemented this for the next release of Objo Studio.

The new BarcodeScanner class opens a camera preview, reads one barcode and returns the decoded text, detected format, scan status and selected camera ID. You can request another scan when you're ready for the next item.

It supports:

UPC-A, EAN-13, EAN-8, Code 128 and QR codes.
Camera selection, with the actual selected camera exposed through CameraId. Your app can save that value and request it on a later visit using PreferredCameraId.
Browser-local decoding. Camera images stay on the device; they aren't uploaded to the server for recognition.
String results that preserve leading zeroes. UPC-A results always contain 12 digits, including when the decoder recognises the equivalent zero-prefixed EAN-13 representation.

Camera preferences belong to the relevant device, browser and site. If a saved camera is no longer available, the scanner falls back to the rear/default camera and reports the actual selection.

For focus, the scanner requests continuous autofocus when the selected camera and browser expose it. Tap-to-focus is not included in this implementation, so I'd particularly welcome feedback on focus behaviour with your devices and product labels.

I've successfully scanned the UPC-A sample on my iPhone over HTTPS. Camera access requires HTTPS when testing from a phone, even if the app is running on another computer on your local network.

I've also added a Web Barcode Scanner example under Web Apps, with sample labels, camera selection, preferred-camera handling and scan results. That should give you something practical to try when the release is available.

Thanks again for explaining the workflow and offering to test. I'd be interested to hear how it performs on your iPhone and Android devices.

Barcode detection in Web apps on Feedback