It's referenced only by installExternalAddon, which is in turn called only once.
We're lucky: installExternalAddon checks in the list provided as an argument, which is:
The code is explicitly checking downloadId, which is the number ID in the URL (the one that if you forget to update download the old NoScript version ).
I have a possible solution (pierov/firefox-android@0c3a7898), which is going back to Firefox's standard provider for addons.
The problem is that it doesn't show addons before bootstrapping (but if I understand correctly it's a UI thing).
I tried to reimplement our adapter to use the JSON we provide only to show addons if we are offline and don't have a cache.
It more or less work, but NoScript isn't recognized correctly and the user is even presented the opportunity to uninstall it (!).
It might be that I have a stale cache and maybe an old NoScript in the APK, but the reimplemented adapter seems too risky and confusing.
My favorite solution is to show "no addons" and an error before the bootstrap.
My favorite solution is to show "no addons" and an error before the bootstrap.
I like this too. Maybe rather than showing a different list depending on the connection status, we could just disable the Add-ons button until bootstrapped?
If you visited the addons before and the cache is still valid you will see the addons.
Maybe we could do it to avoid issues about this (fwiw, with the previous bootstrap you couldn't even get to the addons settings without bootstrapping, so we could even hide it until you bootstrap).
unless the connect button pops you back up the ui stack to the bootstrap page it's... not so simple as we're working in all of connection assist. so I don't love that? but a "Back to bootstrap" link/button that does that would be fine? it'll just back you out of the settings to the bootstrap page
This seems like a relatively niche issue? only on first run if someone goes into the menu to look at addons BEFORE they've bootstrapped? I'm not super worried about this one overall, so any minor UI papering over should be good just to explain why we can't show the info yet
A short error message is fine with me in the short term. We could do something more involved in future if necessary, but as others have already pointed out this is pretty niche.