stuartpb
commented
8 years ago I think, ahead of trying to implement a capture interface, it might make sense to just implement a stopgap in the form of opening local files and reading the QR code from an image file as a Blob. That way, users can use their phone's regular camera app to capture a QR code (I think there's even an option to take a picture among file import options), and whatcardboard's code can take it from there.
Similarly, if we don't recognize the URL, we can work around the issue with a "Please follow this link and paste the URL here", with links for "Why?" and "Please tell us about this headset" - the "Why?" link could link to an issue explaining the problem and inviting people to contribute less-hacky fixes.
This might entail pinging a third party service due to the QR codes being structured as shortened links going through goo.gl (whose destinations are most likely not discoverable inside a
fetch).In any case, the internal headset database should be able to match many headsets just by finding their QR code's URL in its records.
The real challenge is in wrangling the recording device so that the forward-facing camera gets selected instead of the front-facing camera. (There's also likely to be some UI headaches in making it work naturally - should the iframe try to nab full-screen?)