Open wangjacsi opened 7 months ago
Here is an example project created with very good cli to save time on setting up flavors.
https://github.com/saawhitelife/very_good_alice_flavors-
There is AppInfo singleton in helpers package which reads package info on initialization and then returns a flavor based on the package id suffix.
Then in http_client package we add (or not) alice interceptor to dio basing on the current flavor.
The way very good cli sets up flavors (three entry point files) also allows us to set up AppInfo flavor class field on AppInfo initialization, it can be AppInfo(AppFlavor.dev) and so on.
Or you define that via an environment variable or file that you pass at compilation of the flavour. Based on that variable you either include Alice or don't. To achieve this you can use --dart-define or a package like flutter_dotenv or envied.
I'm currently implementing the Alice package in a Flutter application that operates across multiple environments (development, staging, and production) using flavors. My goal is to integrate Alice for network debugging purposes in development (de) and staging (stg) environments, but I want to ensure that it is not included or activated in the production (prd) environment.
Could anyone provide guidance or examples on how best to configure the Alice package to be excluded from the production flavor? Any best practices or recommendations for managing this kind of environment-specific configuration would be greatly appreciated.
Here’s the basic setup of our Flutter flavors:
Development (de): Uses Alice for in-depth network debugging. Staging (stg): Similar to Development, includes Alice for final checks before production. Production (prd): Should not include Alice to avoid unnecessary overhead and potential security concerns. I am particularly interested in any Flutter-specific approaches or patterns that could be recommended for toggling Alice's activation based on the build flavor.