Barcode scanning from a web page.

[Paul Stokes]

Hi Peeps,

I've read the wiki entry re scanning from a web page (http://
code.google.com/p/zxing/wiki/ScanningFromWebPages) and would like to
clarify a few points to see if I understand it correctly.

I have a QR code with the URL "http://goo.gl/icZkm" embedded within.

I have downloaded the latest version of Barcode Scanner

I have set up a link as follows <a href="http://zxing.appspot.com/scan?
ret={CODE}> scan </a>

If I understand correctly, when I click on that link whilst viewing it
using the default browser (using an Android phone with the latest
version of Barcode Scanner already installed - any limits on the
Android version BTW?) then the browser detects the http://zxing.appspot.com/scan?ret=
address and knows to launch the Barcode Scanner app rather than load
the web page because the app registered itself as being the
appropriate handler when it was installed.

The scanner launches, allows the user to scan, and then returns the
result of the scan (in my case http://goo.gl/icZkm as that's the code
I'm scanning) to the web browser which substitutes it for the place
holder {CODE} and which in turn responds as if a link (to anything
after the ?ret= parameter) had been clicked.

The http://zxing.appspot.com/scan?ret= address is hard wired into the
app (so even if the site disappeared for whatever reason the app could
still be launched by clicking on the link - albeit without the nice
download page for those without the app).

The SCAN_FORMATS= parameter is optional? Does it help / make the scan
quicker to restrict the scanning to one format (e.g.
&SCAN_FORMATS=QR_CODE)?

Is all that right?

I know that this sort of functionality isn't set-up for other OS, but
there are are versions of the Barcode Scanner for other OS (such as
iOS). Does anyone know if/when other OS will be catered for in this
way to make the "scan from a web page" functionality truly cross
platform (in my personal opinion such functionality would make it a
killer app!)

[Sean Owen]

That is all correct. I don't know that it is possible in the same way on iOS.

[Kerem]

I am the developer of Qrafter for iOS. Actually, I am really
interested In doing this on iOS and this can be done easily if we can
establish a standard for this.

On iOS, you can register custom URL schemes like, say "qrcode://". If
Android also has the same capability, we can set a scheme for scanning
a code, give the URL of the code like qrcode://scan?code=<URL of
image, URL encoded>&parameters=<Optional parameters>.

Any scanner software willing to support this scheme then would support
scanning from the web.

Any thoughts?

Kerem

[Lachezar Dobrev]

Not a bad idea in general, but it would fail if the user has no
application to manage the protocol. The current address points to a
landing page for users without a barcode scanner installed. The custom
scheme is not suited for that, since it's not browsable.

Android does support registering a custom scheme. And I don't see
any harm registering it _BESIDES_ the current URL.

However I see some weird parameters to the custom scheme URL. What's
the idea of the code=<Image>? The request should have a browse-back
URL to point the user to after a successful scan. Optionally a list of
supported/requested barcode types. If you expect the application to
scan a bar-code from the web, I think someone has expressed security
concerns for that.

I still see a seriously degraded user experience for new users.

Is there any way for a web server to detect if the calling device
supports a qrcode scheme? Any headers?

2011/7/11 Kerem <kerem...@gmail.com>:

[Kerem]

>   Not a bad idea in general, but it would fail if the user has no
> application to manage the protocol. The current address points to a
> landing page for users without a barcode scanner installed. The custom
> scheme is not suited for that, since it's not browsable.

Yes, that's one downside for it. But there is no other way of doing
this on iOS. See my comment about a landing page below.

>   Android does support registering a custom scheme. And I don't see
> any harm registering it _BESIDES_ the current URL.
>
>   However I see some weird parameters to the custom scheme URL. What's
> the idea of the code=<Image>? The request should have a browse-back
> URL to point the user to after a successful scan. Optionally a list of
> supported/requested barcode types. If you expect the application to
> scan a bar-code from the web, I think someone has expressed security
> concerns for that.

For iOS, you need to support the URL to the image to be scanned, so
that the app fetches the image from the URL, save it, then scan it.
That's why there is a "code=" parameter. Be aware that I just made up
the parameters from my head. They should be discussed and shaped
accordingly if we are going to be serious about establishing a
standard.

Also, on iPhone you can't have a browse-back URL. But the user will be
presented with standard choices from the app after a successful scan,
like the code was scanned using the camera.

>   I still see a seriously degraded user experience for new users.

Perhaps the user can be directed to a landing page first, which
redirects to the qrcode:// scheme. And that page can have explanations
on what to do if a "cannot open page" error occurs. This should be
done by the website owner though, and it wouldn't be a part of the
standard I am proposing.

>   Is there any way for a web server to detect if the calling device
> supports a qrcode scheme? Any headers?

I don't think this is possible.

Kerem

[Lachezar Dobrev]

In-line.

2011/7/11 Kerem <kerem...@gmail.com>:

>>   Not a bad idea in general, but it would fail if the user has no
>> application to manage the protocol. The current address points to a
>> landing page for users without a barcode scanner installed. The custom
>> scheme is not suited for that, since it's not browsable.
>
> Yes, that's one downside for it. But there is no other way of doing
> this on iOS. See my comment about a landing page below.

Pity.

>>   Android does support registering a custom scheme. And I don't see
>> any harm registering it _BESIDES_ the current URL.
>>
>>   However I see some weird parameters to the custom scheme URL. What's
>> the idea of the code=<Image>? The request should have a browse-back
>> URL to point the user to after a successful scan. Optionally a list of
>> supported/requested barcode types. If you expect the application to
>> scan a bar-code from the web, I think someone has expressed security
>> concerns for that.
>
> For iOS, you need to support the URL to the image to be scanned, so
> that the app fetches the image from the URL, save it, then scan it.
> That's why there is a "code=" parameter. Be aware that I just made up
> the parameters from my head. They should be discussed and shaped
> accordingly if we are going to be serious about establishing a
> standard.
>
> Also, on iPhone you can't have a browse-back URL. But the user will be
> presented with standard choices from the app after a successful scan,
> like the code was scanned using the camera.

Well... This is not what the application work-flow is like.

1. The web-page requests a barcode scan via a special URL

2. The OS catches the special URL, and opens a LOCAL application.

3. The Barcode Scanner application scans a bar-code

4. The Barcode Scanner application forwards the user to the
browse-back URL with the code filled in.

There is no image stored anywhere, nor processed outside the scanner
application. The barcode scanning is done exclusively on the device.
No piece of the process is done at the server. That's the whole point!

>>   I still see a seriously degraded user experience for new users.
>
> Perhaps the user can be directed to a landing page first, which
> redirects to the qrcode:// scheme. And that page can have explanations
> on what to do if a "cannot open page" error occurs. This should be
> done by the website owner though, and it wouldn't be a part of the
> standard I am proposing.
>
>>   Is there any way for a web server to detect if the calling device
>> supports a qrcode scheme? Any headers?
>
> I don't think this is possible.

I took a quick look over The Internet, and came to a similar
conclusion. There is a way for an application to check for the barcode
scanner, but not for a web page...
I do not own any iOS devices, but here's a thought: if one embeds an
inner frame in the web page and points it to qrcode:// what happens?
Can a JavaScript check the content of the frame, and see if there is
something that can tell one if a scanner is present? I am going to
perform a similar check on an Android device.

Perhaps in the end we can work around most of the problems with a
JavaScript tool?

> Kerem

[Kerem]

>   Well... This is not what the application work-flow is like.
>
>   1. The web-page requests a barcode scan via a special URL
>
>   2. The OS catches the special URL, and opens a LOCAL application.
>
>   3. The Barcode Scanner application scans a bar-code
>
>   4. The Barcode Scanner application forwards the user to the
> browse-back URL with the code filled in.
>
>   There is no image stored anywhere, nor processed outside the scanner
> application. The barcode scanning is done exclusively on the device.
> No piece of the process is done at the server. That's the whole point!

The process will also be free from the server side on iOS, but it must
be different on iOS.

The webpage has a QR Code (say it resides on http://example.com/code.png)
on it that has a href to a qrcode:// scheme (or a landing page as I
mentioned). My proposed scheme would be like:

qrcode://scan?code=http://example.com/qrcode.png (the parameter should
be urlencoded though)

The user clicks on the code. When the device is redirected to such
URL, iOS looks for an app that registered this scheme and calls it.
Then the app fetches the image from the code parameter, scans it and
displays options to the user. It is impossible to get back to the page
that initiated the scan automatically.

It won't be the same experience on both platforms, but this way, at
least a person will be able to scan an image by just clicking on it
instead of tapping and holding on it, saving it, opening the scanner
app manually, selecting to scan from the photo albums. :)

> >>   I still see a seriously degraded user experience for new users.
>
> > Perhaps the user can be directed to a landing page first, which
> > redirects to the qrcode:// scheme. And that page can have explanations
> > on what to do if a "cannot open page" error occurs. This should be
> > done by the website owner though, and it wouldn't be a part of the
> > standard I am proposing.
>
> >>   Is there any way for a web server to detect if the calling device
> >> supports a qrcode scheme? Any headers?
>
> > I don't think this is possible.
>
>   I took a quick look over The Internet, and came to a similar
> conclusion. There is a way for an application to check for the barcode
> scanner, but not for a web page...
>   I do not own any iOS devices, but here's a thought: if one embeds an
> inner frame in the web page and points it to qrcode:// what happens?
> Can a JavaScript check the content of the frame, and see if there is
> something that can tell one if a scanner is present? I am going to
> perform a similar check on an Android device.
>
>   Perhaps in the end we can work around most of the problems with a
> JavaScript tool?

This can be done I suppose.

Kerem

[Lachezar Dobrev]

In-line.

2011/7/11 Kerem <kerem...@gmail.com>:

> The process will also be free from the server side on iOS, but it must
> be different on iOS.
>
> The webpage has a QR Code (say it resides on http://example.com/code.png)
> on it that has a href to a qrcode:// scheme (or a landing page as I
> mentioned). My proposed scheme would be like:
>
> qrcode://scan?code=http://example.com/qrcode.png (the parameter should
> be urlencoded though)
>
> The user clicks on the code. When the device is redirected to such
> URL, iOS looks for an app that registered this scheme and calls it.
> Then the app fetches the image from the code parameter, scans it and
> displays options to the user. It is impossible to get back to the page
> that initiated the scan automatically.
>
> It won't be the same experience on both platforms, but this way, at
> least a person will be able to scan an image by just clicking on it
> instead of tapping and holding on it, saving it, opening the scanner
> app manually, selecting to scan from the photo albums. :)

You INSIST on scanning a barcode that's on an image available on the
Internet. That is definitely _NOT_ what the application is about. The
application is expected to help the user scan a barcode that's
available on a real-life media (paper, screen, wall, window, etc.)
using the built-in camera.

Scanning a barcode that's available on a web-page is *completely*
useless, since the image can be a link, pointing to the target URL.
The user should simply click the image. Going through a scanner is...
Well... USELESS!

The Web integration is designed to help a web application
effectively scan a barcode that the user is looking at. That will
reduce the clutter a user has to go through to enter information in
the device. QR codes are but one case, product codes are another.

>>   Perhaps in the end we can work around most of the problems with a
>> JavaScript tool?
>
> This can be done I suppose.

That's good to hear.

> Kerem

[Kerem]

>   You INSIST on scanning a barcode that's on an image available on the
> Internet. That is definitely _NOT_ what the application is about. The
> application is expected to help the user scan a barcode that's
> available on a real-life media (paper, screen, wall, window, etc.)
> using the built-in camera.
>
>   Scanning a barcode that's available on a web-page is *completely*
> useless, since the image can be a link, pointing to the target URL.
> The user should simply click the image. Going through a scanner is...
> Well... USELESS!

Ah, OK! I misunderstood the intent here then. Well, on iPhone you can
still call an app for scanning using a custom scheme, but it will
never be able to return to a callback URL.

I still think scanning a QR Code that is on a webpage is not
completely useless, because people already add vCard information or
information alike that can populate information.

Kerem

[Lachezar Dobrev]

In-line...

2011/7/11 Kerem <kerem...@gmail.com>:

>>   You INSIST on scanning a barcode that's on an image available on the
>> Internet. That is definitely _NOT_ what the application is about. The
>> application is expected to help the user scan a barcode that's
>> available on a real-life media (paper, screen, wall, window, etc.)
>> using the built-in camera.
>>
>>   Scanning a barcode that's available on a web-page is *completely*
>> useless, since the image can be a link, pointing to the target URL.
>> The user should simply click the image. Going through a scanner is...
>> Well... USELESS!
>
> Ah, OK! I misunderstood the intent here then. Well, on iPhone you can
> still call an app for scanning using a custom scheme, but it will
> never be able to return to a callback URL.

The browse-back URL is not «returned», but rather opened! That way
the user feels as if part of the web application works on his device,
and has a very smooth transition between screens. Can't an application
on the iOS open an arbitrary URL in the browser? I will be VERY
surprised if it's not possible...

It's a very neat «trick» the developers of ZXing implemented. I
suspect MANY web application developers would like the integration
with iPhone.

> I still think scanning a QR Code that is on a webpage is not
> completely useless, because people already add vCard information or
> information alike that can populate information.

Well... I consider linking to a .vcf file a better way, since QR
Codes use the bit limited ME-Card format. Also the device may have a
nice application that does .vcf import (hTC devices do). Currently
sharing a contact card via QR-Code/ME-Card has quite a few drawbacks
(mostly due to limited Android API). With the .vcf way I can import
pictures, multiple addresses and phone numbers, VoIP numbers, Instant
Messenger addresses, and much more, that is not available otherwise.

> Kerem

[Kerem]

>   The browse-back URL is not «returned», but rather opened! That way
> the user feels as if part of the web application works on his device,
> and has a very smooth transition between screens. Can't an application
> on the iOS open an arbitrary URL in the browser? I will be VERY
> surprised if it's not possible...

OK, that can be done. For example Qrafter has an in app browser that
can open URLs. It can also redirect the user back to Mobile Safari.
This is solved then.

>   It's a very neat «trick» the developers of ZXing implemented. I
> suspect MANY web application developers would like the integration
> with iPhone.
>
> > I still think scanning a QR Code that is on a webpage is not
> > completely useless, because people already add vCard information or
> > information alike that can populate information.
>
>   Well... I consider linking to a .vcf file a better way, since QR
> Codes use the bit limited ME-Card format. Also the device may have a
> nice application that does .vcf import (hTC devices do). Currently
> sharing a contact card via QR-Code/ME-Card has quite a few drawbacks
> (mostly due to limited Android API). With the .vcf way I can import
> pictures, multiple addresses and phone numbers, VoIP numbers, Instant
> Messenger addresses, and much more, that is not available otherwise.

Good luck with linking to a .vcf file on iOS. Safari cannot open .vcf
files natively. That's why I added a .vcf parser to Qrafter that lets
people open them using Qrafter. It is also the best vCard parser on
all mobile platforms, better than any parser on any app including the
official ones (yeah, I am THAT confident here). OK, I did enough
advertisement here, so I will stop. :)

Kerem

[Paul Stokes]

Hmmmm,

Kerem, you did miss the original point, but your suggestions have set
me thinking. Lachezars point re making the user experience smooth is a
good one ("...the user feels as if part of the web application works
on his device,
and has a very smooth transition between screens.") and is exactly
what I was trying to achieve.

I'm envisaging an environment where there are a series of QR codes
that a user can scan with their mobile phone, each leading to a web
page with relevant information. After the first QR code scan has
launched the web browser I'd like the user to be able to initiate the
next scan from within the web page. I'd rather not have them exit the
browser, launch the scanner, scan, view the next page, repeat. Quite
apart from anything else embedded scanning makes the use of session
variables easier as well as making the user experience simpler.

Using Lachezars work flow as a starting point it, in web browser
scanning (or rather in web browser launch of scanner) work flow would
be for Android:

1. Launch scanner application
2. Scan code
3. view web page
4. Initiate next scan by clicking on a link causing the web-page to
request a barcode scan via a special URL
5. The OS catches the special URL, and re opens the LOCAL Barcode
Scanner application.
6. The Barcode Scanner application scans a QR code
7. The Barcode Scanner application forwards the user to the browse-

back URL with the code filled in

8. Repeat from 3.

(One thing I'm not clear about is is the new URL loaded in the current
browser window or a new browser window (i.e. will the back button
work?))

Now Kerem says "Well, on iPhone you can still call an app for scanning
using a custom scheme," (I'd love to know how please), and later on
suggests Qrafter. That being the case then my problem is partially
solved.

The whole user experience for an iOS user will be subtly different,
but still usable nonetheless. The fact that the scanner doesn't
automatically "forward the user to the browse-back URL with the code
filled in" is not insurmountable. Most scanner apps, when they've
scanned a QR code containing a URL, open the web browser and launch
that page anyway. The difference here, if I understand it correctly,
is that the URL will be in a new window (pity there's no way of
implementing a target= parameter - or is there?). (I'll be
downloading Qrafter after I've sent this to see how well it copes with
my content)

So the work flow for iOS will be:
1. Launch scanner application
2. Scan code
3. view web page
4. Initiate next scan by clicking on a link using a custom scheme (how
please Kerem) to launch the scanner
5. The Barcode Scanner application scans a QR code
6. The Barcode Scanner application opens a new browser window and
displays the URL
7. Repeat from 3 until you get to 8 windows (for Safari)
8. Start overwriting older windows

This just leaves me with the problem of ensuring that users use the
right QR code scanner.

In an ideal world I'd like to avoid asking users to download anything
at all (that's one of the reasons for using a web interface in the
first place) and have the web page call the "default" QR code scanner.
Unfortunately I don't think its possible to have such a "default" on
iOS (correct me if I'm wrong). Unfortunately again, I think any
requirement to download a app in the environment I'm envisaging will
cause many users to fall by the wayside. Asking them to change an app
is even more of a no no.

I'd welcome your thoughts/contradictions.

PaulS

[Romain]

The way iOS handles custom URL scheme is a bit technical. Functionally
speaking, this results in being able to launch the app using its
registered URL scheme (like qrcode://). Technically speaking, you just
declare the URL scheme in your info.plist. See the documentation here:
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/StandardBehaviors/StandardBehaviors.html

I do see a limitation in the qrcodes:// proposition in the sense that
scanner apps are usually meant to handle several barcodes format. On
iOS, zxing algorithms are mostly capable of scanning QRcodes, but we
may see improvements in the next few months.

Personally, I think the way Android allow an app to override a http://
url is really horrible.

However, I have tested a few js based approaches that allowed to
detect if a custom url scheme is present from safari mobile. This
technique could well be used in <a href="http://zxing.appspot.com/
scan?
ret={CODE}> scan </a>, such that when the user agent is an iPhone AND
the appropriate URL scheme is detected, the user is redirected to the
app. Otherwise this page would be used to give instructions to
download a Scanner from the AppStore

[Christopher]

We're using the url scanning feature in a web shop web app. In Android browser the callback URL is opend in the same browser window which is the desired behaviour for us. In iOS / mobile Safari a new tab is used.

Is there any way to eighter open the URL in an existing tab or close "old" tabs? I had a look at the iOS API documentation some time ago but didn't find anything helpful.

[argrithmag]

And it appears that with android, you can't use the window.close() on the new tab/page.  I was able to write the new page to create a cookie in the browser, but there's no way to get that page to close itself down.

Can zxing be updated to call a web/REST service instead? and not use the browser?  then i can take the data from the scan and store it serverside.

On Friday, July 13, 2012 12:45:30 PM UTC-6, Kivi wrote:

Hi Christopher,

We're finding that even in Android the callback URL is opened in a new tab.  How did you make it open in the same browser window?

[Sean Owen]

The return request could contact a REST API, sure. It is just making a GET request.