IzzyOnDroid improvements

[ChunkyProgrammer]

Followup to #71
IzzyOnDroid
FreeTube cordova has been accepted into IzzyOnDroid
https://gitlab.com/IzzyOnDroid/repo/-/issues/328

Url to app (will be availaible at 7pm UTC): https://apt.izzysoft.de/fdroid/index/apk/io.freetubeapp.freetube

Please select what topic your discussion is about.

• Bug/Feature tracking

ToDo

• the French short_description.txt is a bit too long, as it exceeds the limit of 80 chars. I've truncated it to "un lecteur YouTube open source construit avec la confidentialité à l’esprit" (no need to repeat the name of the app, as that's usually put in context)

• the full description lacks a single line break to be processed as valid Markdown. Could you add an empty line between "Features" and the bullet-point list?

• add link to izzondroid in readme

• add shield to readme

• bug: package.json version should be different for each nightly release (might be a good idea to differ from FreeTube's versioning for this or maybe it could be automated somehow in the build:cordova script maybe allow passing at optional version parameter that it'd use instead of the package.json version)

• cleanup of release workflow

[ChunkyProgrammer]

@MarmadileManteater I'm not really sure what you'd want to do to fix the versioning. I should be able to work on the other points in the meantime

[ChunkyProgrammer]

I also just realized I think I might have misunderstood #76 (comment) . Did you want it added to IzzyOnDroid at a later date or were you okay with it being added now?

[MarmadileManteater]

I am okay with it. I'm sorry if I wasn't clear.

What I meant by cleanup of the release workflow is that I want to separate nightly into two environments: a true nightly which updates like usual and release which is more aimed at production environments. I also need to make sure the release build is built with the release flag rather than the debug flag.

When the environments are fully separated into two, it might be worth adding IzzyOnDroid to the installation method drop-down in the bug_report.yml issue template.

Something I also need to 🧠remember is that the current 🔑key for ✍signing nightly needs to become the release signing key; otherwise, users who have already installed the app may find themselves unable to install an update without fully uninstalling the app.

As far as the version codes are considered, I wonder if the build number could be used as part of the version code proper: 0.18.0.76 instead of 0.18.0-nightly-76. From what Izzy said: "To me it looks like 1800 is used for the entire 0.18.0-nightly line." That makes me think the build number isn't currently being recognized as part of the version, and 🤔maybe, that is because it thinks the build number is part of the nightly suffix.

[IzzySoft]

I wonder if the build number could be used as part of the version code proper: 0.18.0.76

versionCode is an integer. But yes, that could be used, in a way. Let's map that to something of the pattern used in semantic versioning: major.minor.patch.build, a possible way to calculate a versionCode from that could be:

major x 10000000 + minor x 100000 + patch x 1000 + build

assuming "build" to be max 3 digits and the others max 2 digits – otherwise adjust accordingly. For your example: 0 + 1800000 + 0 + 76 = 1800076. Three notes on this:

• remember versionCode can never be decreased again (i.e. decide wisely before applying a pattern)
• deciding wisely includes a good guess on how many digits which part might need in the future (build might well reach 5 digits – but then, just increase the multiplicator: it would make versionCode larger, but that's fine)
• that "calculation pattern" is no invention of mine – I've seen it with multiple projects already (though usually only with major.minor.patch aka SemVer), so it's nothing "uncommon"

And yes, I came here today as my updater once more complained about the update has not increased versionCode properly 🙈

As for ApplicationDebuggable: starting with Android 12 I'd almost consider that a feature, as it re-enables users to have the data of the app included with adb backup (Google decided backups do no longer belong to the user at all, which I feel is nuts; the arguments used do not convince me). But yes, the backup issue aside I see the (minor) risks involved with an app being set to debuggable so I agree "production builds" should not have that.

signing key

Indeed that is an issue. A possible alternative would be letting the app have proper export and import features, so switching would still be possible without data loss. Then also consider using a separate applicationId for the nightly (e.g. append .nightly so it becomes io.freetubeapp.freetube.nightly) – which then would permit installing both versions side-by-side. That might be useful in the "bug solving workflow" as you could ask users to confirm a fix – without them having to be afraid the "unstable nightly" might break their data.

[ChunkyProgrammer]

I believe this is now done

[IzzySoft]

Cool – and looking great! 🤩 Thanks!