QR code from Moodle opens app, but does not trigger download

[fwild]

We have this feature in Moodle that you can get a link to the activity to start it. It seems it has stopped working for me. Pointing the native OS camera app at the code gives me the link, and the link opens the app (as it is correctly registered for the new protocol "wekit://"), but the app does not initiate the download of the activity.

I have tested: with app not started (starts the app, but no download trigger); with app already started (doesn't download or open); with app already started and activity already previously downloaded (activity is not started).

[fwild]

I restested today on the last development build I have installed, and this is still the case. It does not open.

[robhillman97]

I have been testing this issue and there are a few things going on.

I know the "wekit://" protocol is working correctly as if you press the launch button in Moodle on a device with Mirage installed the app will be opened, the activity will be downloaded and opened. You do however have to be connected to the correct Moodle server in app, so if you are opening the activity from here "https://arete.ucd.ie/mod/arete/view.php?id=87" then you have to go into the in app settings and connect to the ARETE Moodle repository. Also if you're using a build with the new UI the app opens on the "New UI or Old UI" page which messes up the download. I am working on a fix for this but to get around this for testing you can have Mirage open and on the activity selection page in the background when you press launch.

The bigger issue is that the QR codes on Moodle are broken somehow. Using inspector on chrome I can see that the launch button opens the following link: wekit://load?download=1/mod_arete/arlems/917361878/Greet%20the%20principal.zip&id=session-2021-06-23_14-37-38

Which is the download path and the session ID for the activity this is what the app is expecting. However when I scan the a QR code I get the following options;

if I select "View full text" it shows this: wekit://load?download=1/mod_arete/arlems/917361878/Greet the principal.zip

For some reason the QR code link is cutting off the "&id=session-2021-06-23_14-37-38" part and therefore the app never receives the session ID and the activity can't be found.

I made a new QR code using an online generator with the full link: wekit://load?download=1/mod_arete/arlems/917361878/Greet%20the%20principal.zip&id=session-2021-06-23_14-37-38

When scanned it opens the app and the activity (as long as I am connected to the ARETE repo and have the activity selection menu open in the background as mentioned before)

@fwild If you get a chance could you try this QR code and see if it works for you?

[fwild]

Can we add a dialogue message for the case of the "wrong server"? To tell the user to register and logon to the another server? And display the server domain name?

[fwild]

I tested this briefly now, but could not open the QR code - my camera app now copies this to the clipboard (with dialogue message that it has been copied to clipboard), something must have been wrong in the installation process when I sideloaded the last pipeline build. Will test later with proper release, then it should work.

My take: if we have the dialogue message, and we know a workaround when and how to make it work, then we can find a smarter way in the future (to bypass the onboarding slides or anything else that prevents download). As long as we can get it to work, and as long as we can notify users which server to use.

[fwild]

I have tested this now with the release version 1.9 from the store (android), and I find the following:

• the QR code above does not work on my phone, it recognises it as "text" and does not try to open it via a browser.
• If I copy & paste the link into firefox and into chrome, nothing happens, the protocol seems not to be registered.
• When I log in to the arete server and use the play button, while the app is already open on the activity screen, then it will download and open the unit as intended.

Not quite sure what went wrong with the protocol registry, and I can try a custom built again, maybe we did something wrong in the release process (and forgot to register the protocol)?

But I stick with the above: let's add a dialogue message with an error message if you are not logged in or on the wrong server. And otherwise leave it as is - but check why the protocol sometimes works and sometimes not? If you give me another test version that works for you, I can rule out whether it is my phone.

[fwild]

And, yes, it is weird that one day the protocol works, the other day not.