As the page does not discuss the motivation behind the API, does anyone know why this is ”native” API and not just a generic image processing script implemented with JavaScript / WebGL / etc.?
Of course, it's a matter of perspective whether you want to see this as lovers of the free web helping webapps to feature parity with native apps; or Google churning out yet another low-effort standard that's easy for them and difficult for all their competitors.
At this point in time it's a pain point for me that Android devices don't usually have built-in QR reader software. I can tell iOS users to just "scan the code with the Camera" app but I have to tell Android users to find a QR scanner app on the app store.
My experience with an actual bottom-of-the-line prepaid phone was that the first QR scanner app I downloaded from Google Play worked right the first time but I had to try six different apps before I found one that worked with my Samsung Tablet.
A web-based scanner would be a possible answer, though really Google and the phone makers and the carriers should have prioritized a "just works" solution years ago.
I've been scanning QR codes with my Android phone for a long time. I know at least two native cameras work, Pixel's and Samsung's since 2019. But I am sure legacy phones with older android versions don't support it natively.
I have a flagship Xiaomi phone and the built in QR code scanner is garbage. I went to a restaurant with friends which only had a QR code for the menu (which turned out just to be a link to the root of their website - why not write the URL too?). In the end I had to take a picture of the QR code, then crop it, then open that in the scanner app.
I've had intermittent issues with my motorola's camera app. Sometimes it picks up qr codes at restaurants, sometimes it refuses, maybe because of lighting issues, though turning on the flash doesn't help. I ended up downloading BinaryEye from F-Droid and I just default to that now.
As always, some fragment of Android actually got there before Apple (to put it in the Camera app), but no, it's not standard.
My current phone (Nokia 3.4) doesn't have it, but previous one (Motorala One) did. Ironic, since I chose them for being about as close to stock as you can get, both in the 'Android One' programme (so also comparatively LTS).
Honest question: for what reasons do you ever need to scan a random QR code? I think I've used them to sign in to some apps (eg, WhatsApp) while logged in on a PC, and other than that exactly 0 times.
The Google camera app does support QR codes FWIW, but I don't know if any other vendors except Google use it.
> Honest question: for what reasons do you ever need to scan a random QR code?
In the past two years, due to COVID, a lot of restaurants and dining establishments got rid of paper menus and left people with "here is a QR code, scan it to see the menu". This is the most common situation I've encountered this in. It wasn't just a few restaurants that did this, it was heavy majority of places here (Seattle).
In general, assuming you have an easy-to-use QR scanner, it's easier to scan a QR code than type in a URL on a phone, especially a complicated one. A couple examples I've run into recently:
- Lately it's been pretty common for restaurants to replace their physical menus with a QR code on the table that links to their online menu.
- When I've taken COVID tests recently, the site gives me a sticker with a QR code that links to my results page.
- I encoded my wifi network/password into a QR code and printed it out, so guests can just scan it to join, rather than have to scroll and find the right network and type in a password.
They became very popular during the pandemic for restaurants to offer their menu as a scannable QR code instead of distributing and sanitizing hand-held paper menus. I think this is becoming less relevant now.
They're popular for street-level advertisements for (concerts, events, clubs, jobs) to provide a link to more information without the consumer having to type a url into the browser. This is more important if you don't want to pay for a pithy high-level domain as a landing page for the thing you are advertising.
I have also seen them for easily entering WiFi credentials to your device on a new network.
They can be used in museums to link to self-guided tour information on the artwork/exhibits you are looking at. This used to be done more with rentable/loanable walkman+headset kind of devices, but makes more sense to do on one's own mobile device now.
I print ‘three-sided cards’ that have a photo or art reproduction on one side, some documentation on the back, and more information if you scan the QR code. One series of the cards are ‘music cards’ that will play a song, another application is ‘constellations’ that let me stick anywhere from 3 to 40 cards on the wall (so far) and you can see the back sides and other narration by scanning a code.
So my use cases are (1) I am demoing the cards for people, and (2) I give the cards away for free (If it wasn’t for the supply chain crisis I’d be creating a new card design every day) or put up an installation somewhere and people interact with them. Either way I want it to be very easy for people.
In Argentina, QR codes is how you pay with your phone in super markets, pubs/bars, restaurants, everywhere - its their "apple pay", using Mercado Pago [0] app/service. Also, all the paper menus from restaurants are replaced with QR codes thanks to the pandemic.
Native code allows for performance gains that a script (even a performant one) may not be able to match. After all, this is fundamentally an image processing problem, one of the more computationally expensive things a browser has to do.
Isn't that the point of webassembly? Just seems like we are still moving in the wrong direction on trying to move the whole of NPM in to the browser web apis, rather than building a solid base you can build anything on.
High performance barcode decoding (e.g. scandit) uses the GPU.
After all, a modern cell phone could be producing 4k 30fps video, and high performance barcode decoders will detect linear barcodes with lines a single pixel wide, even in the presence of moderate noise/blur/overexposure (e.g. the barcode on a shiny can of coke)
Of course, I've got no idea if browsers will provide high performance barcode reading, or something simpler like zxing.
And I've got to say, it's not obvious to me why browsers would implement a barcode scanning API in preference to a more general accelerated image processing API. Plenty of other applications want to do real time video processing in the browser - such as video call background removal.
Do you have any examples of what a more general image processing API would feature? Everything between reading pixels and reading barcodes is a mystery to me.
I'm not a browser developer, but to wager a guess, it probably has something to do with the inertia of existing solutions being native, rather than in WebAssembly, which is still quite new as standards go.
It's a heavily standardized, very recurrent problem that can take a lot of advantage of native code and platform-specific optimization, so it's really an ideal target for a Web API.
To allow the implementation to take advantage of libraries provided by the operating system[0] (where available), without the web site developer needing to even know that it's happening.
Barcode detectors can be pretty big dependencies. Given that this will often just be forwarding directly so some kind of OS capability it makes sense to ship in browser.
Consider the following facts:
1. This was designed by Google
2. Google Play Services provides an API for detecting barcodes, faces and text https://developers.google.com/android/reference/com/google/a...
3. Chrome gets a shape detection API for detecting barcodes, faces and text https://web.dev/shape-detection/
Of course, it's a matter of perspective whether you want to see this as lovers of the free web helping webapps to feature parity with native apps; or Google churning out yet another low-effort standard that's easy for them and difficult for all their competitors.