Floating-Dartists
[Feature] Modify siteId after initialization
Like for the url, I would like to change the siteId after initialization, so we can dynamically change environment (prod / staging).
Wouldn't using flavors to have different build environments for your app do the same? I'm not sure that being able to change siteId on the flight would bring much benefits 🤔
While your are right Flavor would be the cleaner way - it's NOT the easier and more practicle way. I have several medium-size projects were team is very small, and publish flow is very simple, do not requires using Flavors. Instead of having to rebuild each time we need to change environment (or generate several builds), we just have a basic in-app developper menu that allow to change some settings, like the API environment. That way is way more flexible and greatly reduce CI usage. So yes, setting siteId dynamically would be nice.
Is it hard to implement ?
I thought I coulnd otherwise dispose the Matomo instance and create a new one with another siteId, but the whole package seems very "static", we don't have access to the constructor.
Is it hard to implement ?
It's more about: "Do we need to add more code to maintain to an already large codebase?"
Back to your initial problem, if you don't want to setup flavors for your project you can still use environment variables and inject your stideId with it:
{
"siteId": "<my-site-id>"
}
flutter run --dart-define-from-file=prod.json
class EnvVariables {
static const siteId = String.fromEnvironment('siteId', defaultValue: "<staging-site-id>");
}
I know that thanks, but it doesn't solve our distribution flow : each team user, testing or using the app, must have the abillity to change API env dynamically, as I explained. There are not developers, they "just" run app from TestFlight or Google Play Store. That's why the dev menu is so handy ;)
After discussing this with the maintainers, we believe the quickest workaround for you is to store your siteId in SharedPreferences. This way, your QA team can easily modify the value directly from the app, and the initialization should use the value retrieved from SharedPreferences. QA team will have to restart the app to initialize with the correct siteId.
We do not want to change the siteId on the fly, as we believe the siteId should be "flavorized" if you require multiple configurations. Your use case is quite specific, and we prefer not to let a single specific case dictate the overall package logic.
If more users request this feature, we may reconsider our approach. For now, however, we suggest implementing the simple workaround using SharedPreferences.
It's already quite what we're doing to change environment (using shared_pref). So using that method won't really offers dynamic env change, nor avoid data leaking. But still, I can understand your point of view, keeping the package as simple as possible. Issue is here if anyone else think it's usefull.
However, regarding the the "static"-ness of the package, you still thinks it's good idea to leave it like that ?
Anyway, thank you for your time and quick answers.
However, regarding the the "static"-ness of the package, you still thinks it's good idea to leave it like that ?
You mean using a singleton? Maybe we should go with a more similar way as Firebase and provide an initialization method that would return the proper initialized instance of the Matomo object but this is quite the breaking change compared to our current behavior, as long as there's no critical issue with the singleton approach I think we'll stick with it until we can't anymore.
You mean using a singleton
Yes. Instanciation like SharedPreference allows both easily : handle your own Singleton for simple case, or create instance the way you need to more advanced scenarios