FontlosandJonathan Kelley
bfb0642a1d
* fix(cli, breaking): Align Android applicationId with user's `bundle.identifier`
This commit fixes the Android `applicationId` generation to accurately reflect the user-configured `bundle.identifier` when provided. It also refactors the logic by removing the `full_mobile_app_name` function, with `bundle_identifier` now being the direct source for the Android `applicationId`.
The `bundle_identifier` function now operates as follows:
1. If `bundle.identifier` is explicitly set by the user:
- It validates that the identifier has at least three segments (e.g., `com.example.app`).
- The user's `identifier` is then returned and used directly as the Android `applicationId`.
2. If `config.bundle.identifier` is not set by the user:
- It defaults to `com.example.{PascalCaseExecutableName}`. The `executable_name` (e.g., "my-app" derived from a project name like "MyApp") is converted to `PascalCase` (e.g., "MyApp") for this default.
**BREAKING CHANGE**:
This change primarily affects Android builds and may alter the final `applicationId` for users who had a custom `bundle.identifier` set, particularly if its casing or final segment differed from the PascalCased `executable_name`.
- **Previous Behavior**:
The Android `applicationId` was derived from `full_mobile_app_name`. This function effectively used the first two segments of the `bundle_identifier` (user-configured or default) but then **always** appended a PascalCased version of the `executable_name` as the final segment.
Example Scenario:
- User project name: "MyApp" (CLI set `executable_name` to "my-app")
- User configured `bundle.identifier` in Dioxus config: `"com.custom.myapp"`
- `bundled_app_name()` (from "my-app"): "MyApp"
- Old `applicationId` (via `full_mobile_app_name`): `"com.custom.MyApp"`
- **New Behavior**:
With the same user configuration (`"com.custom.myapp"`), the `applicationId` will now be: `"com.custom.myapp"`
This change ensures the `applicationId` respects the user's explicit `bundle.identifier` string. However, if users were unknowingly relying on the previous behavior where the last segment was always a PascalCased version of the `executable_name` (potentially mismatching their intended lowercase final segment in `bundle.identifier`), their `applicationId` will change upon updating the CLI.
According to Google's Android documentation, the `applicationId` must not be changed after an app is published, as this causes Google Play to treat it as a new application. Users who have published Android apps and utilized custom `bundle.identifier` configurations should meticulously verify their `applicationId` after this update to ensure it remains consistent with their published versions or to take appropriate action if a change is detected.
* fix: relax validation for bundle.identifier
1. Contains at least one dot ('.').
2. Does not start with a dot.
3. Does not end with a dot.
4. Does not contain consecutive dots ('..').
e.g., `com.example` or `com.example.app`
---------
Co-authored-by: Jonathan Kelley <jkelleyrtp@gmail.com>
📦✨ Dioxus CLI
Tooling to supercharge Dioxus projects
The dioxus-cli (inspired by wasm-pack and webpack) is a tool for getting Dioxus projects up and running. It handles building, bundling, development and publishing to simplify development.
Installation
Install the stable version (recommended)
cargo install dioxus-cli
Install the latest development build through git
To get the latest bug fixes and features, you can install the development version from git. However, this is not fully tested. That means you're probably going to have more bugs despite having the latest bug fixes.
cargo install --git https://github.com/DioxusLabs/dioxus dioxus-cli
This will download the CLI from the master branch,
and install it in Cargo's global binary directory (~/.cargo/bin/ by default).
Install from local folder
Note: The CLI will fail to build projects in debug profile. This is currently under investigation.
cargo install --path .
Get started
Use dx new to initialize a new Dioxus project.
It will be cloned from the dioxus-template repository.
Alternatively, you can specify the template path:
dx new --template gh:dioxuslabs/dioxus-template
Run dx --help for a list of all the available commands.
Furthermore, you can run dx <command> --help to get help with a specific command.
Dioxus config file
You can use the Dioxus.toml file for further configuration.
Some fields are mandatory, but the CLI tool will tell you which ones are missing.
You can create a Dioxus.toml with all fields already set using dx config init project-name,
or you can use this bare-bones template (only mandatory fields) to get started:
[application]
name = "project-name"
# Currently supported platforms: web, desktop
default_platform = "web"
[web.app]
title = "Hello"
[web.resource.dev]