Android versionCode field

[hadeutscher]

Hey

Pinning versionCode to 1 causes issues when deploying the app to Google Play because they require version codes to advance with each deployment. I'm not sure exactly what to do since Rust doesn't have a semantic like versionCode; I thought converting the semver to versionCode like this might be a decent compromise (the downsides are that the semver prerelease field doesn't get projected, and that we clamp the range of each semver component from 64-bit to 1000).

Other options I can think of - setting it from [android] in Dioxus.toml (seems kind of clunky since it's far from where the crate's version is defined); requiring a metadata section in the crate's Cargo.toml to specify the version code.

Let me know what you think.

[nicoburns]

Hmm... this definitely needs a solution, but I'm a little skeptical of computing it from Cargo version. I think for regular Android builds it's completely decoupled from the app version? (and IIRC it's common to bump the versionCode without bumping the semver-style version for development builds?)

[hadeutscher]

Hmm... this definitely needs a solution, but I'm a little skeptical of computing it from Cargo version. I think for regular Android builds it's completely decoupled from the app version? (and IIRC it's common to bump the versionCode without bumping the semver-style version for development builds?)

Yep, that's correct - that's why I said there's no matching concept in Rust; Cargo crates only have a semver. Do you think it's better to have the user set it in Dioxus.toml manually?

[hadeutscher]

I encountered a few other Android-specific settings that are currently not configurable and are blockers for my ability to publish a real app using this framework; As a temporary workaround, I'm now building my app with a private fork of dioxus-cli where I've added a few environment variables to be able to control these (to be clear, I don't think environment variables are a good solution for this, it's just the easiest way for me to inject those values on my builder machine).

@nicoburns if you're up for discussing how you would like to see these sorts of settings being set, I'd be glad to write an implementation and contribute my code upstream. The current list of settings I'm missing and had to hijack with an env var:

• version_code (hard blocker for publishing an app since it has to be changed)
• App name (the current code derives it from the crate name; this is not good for me because I need a user friendly name)
• App icons (the current code autogenerates a res folder with the stock android logo)

[nicoburns]

@hadeutscher I'm definitely interested in all 3 of those (for the same reasons as you are: Play Store publishing):

• App name seems straightforward: it probably ought to be an option in the Android section of the Dioxus.toml (and it could fall back to the existing logic if not set there)
• version_code is awkward. It could also be in Dioxus.toml, but it seems non-ideal to have to update that so frequently. But I don't necessarily have a better idea. Could also be an environment variable?
• I would be inetersted to know how you want to specify app icons (PNG vs. SVG vs. VectorDrawable). There is this PR for this: https://github.com/DioxusLabs/dioxus/pull/4063/changes which seems decent, but it's not entirely ideal that it pulls in resvg for SVG -> PNG conversion. Or that it has a hacky SVG -> VectorDrawable conversion built in. I wonder if we can get away with only VectorDrawable? And have the CLI look for one in the icons array?

[hadeutscher]

@hadeutscher I'm definitely interested in all 3 of those (for the same reasons as you are: Play Store publishing):

• App name seems straightforward: it probably ought to be an option in the Android section of the Dioxus.toml (and it could fall back to the existing logic if not set there)
• version_code is awkward. It could also be in Dioxus.toml, but it seems non-ideal to have to update that so frequently. But I don't necessarily have a better idea. Could also be an environment variable?
• I would be inetersted to know how you want to specify app icons (PNG vs. SVG vs. VectorDrawable). There is this PR for this: https://github.com/DioxusLabs/dioxus/pull/4063/changes which seems decent, but it's not entirely ideal that it pulls in resvg for SVG -> PNG conversion. Or that it has a hacky SVG -> VectorDrawable conversion built in. I wonder if we can get away with only VectorDrawable? And have the CLI look for one in the icons array?

For version code - there's a third option of putting it in Cargo.toml using the metadata table, see e.g. this example of flutter-rs. It's slightly less cumbersome that having to modify Dioxus.toml but it would require introducing the concept of having a package.metadata.dioxus table with settings that your CLI uses and deciding where to parse it and how to lay it out etc. and that's a bit too much of an architectural decision than I'd like to get into with this PR. Maybe I should just place it in Dioxus.toml for now and you can add the issue of supporting settings from the crate's metadata to your backlog for the future?

For icons, I don't really mind, I use PNG icons which I've generated from an SVG myself and I think that's good enough, I don't think adding complex SVG to %s conversions is required at this early stage and VectorDrawable is an annoying format to work with (even the official SVG to vector conversion in Android Studio messes up my icons beyond repair, so I don't use it). I also think it's a decent compromise to just let the user specify the res folder with the Android drawables and copy them from there for now.