[Question] Would you consider changing the installation process to be pure Dart?

[jorgecoca]

Hello! 👋

First of all, thank you for creating and maintaining this awesome package! It makes integrating with segment a piece of cake!

I was wondering how open would you be to changing the installation process to be pure Dart/Flutter, so instead of relying on the AndroidManifest.xml for Android, or the Info.plist for iOS, we could just have a constructor for Segment that could take the writeKey and other parameters as well.

I understand this would introduce a ton of breaking changes, but my thinking process at the moment is:

• For applications with more than one flavor, it becomes very tedious to go to every manifest and Info.plist and make the modifications, while if we change that to be pure dart if would be much more straightforward, and we could even unit test it on the Dart side when building our Segment instance.
• Introducing a constructor would imply also changing the APIs to not to be static. This would open the door for many other questions: should this library maintain two different approaches, one with native installation and static APIs, and one just pure Dart APIs and no static APIs? Should you just pick one? Or continue as it is?

Anyways, I wanted to touch base with the maintainers, since I am currently working on a big project that is facing that installation challenge I described before, and internally we were considering opening a PR to adapt this Dart installation process I described before.

If you think it is interesting, I am more than happy to do the work and open a PR. If you think more discussion is needed, we can find a way to chat and see what we can do. Otherwise, if you think this a process you would not like to adapt, let me know as well, so I can talk to my team and regroup around the options we might have.

Thank you so much! 😄

[vinicius-animo]

Hi @jorgecoca

I like the idea of having a pure Dart approach for this plugin.
You can count on me for this PR, which is - in my opinion - very welcome.

Anyways, it would be good to hear the opinions of @MaiKaY and @kev52

[MaiKaY]

Hi @jorgecoca, hi @vinicius-animo,
I really appreciate and very welcome this kind of contribution.

The idea behind I also really like even tho I have some concerns since we are getting rid of native segment libraries (or am I wrong and we still use the native libraries?):

• Is offline capability still given?
• Is it mobile optimized (e.g. caching, request queueing, etc.)?

---

Nevertheless as soon as the implementation might happen here are my opinions to the mentioned points above:

Should you just pick one? Or continue as it is?

Preferably we should set the current configuration (AndroidManifest.xml for Android and Info.plist for iOS) as optional instead of being required and use these values as the default values for the configuration.

Introducing a constructor would imply also changing the APIs to not to be static

We could use the singleton-pattern to keep our existing interface and provide a .configure() method to overwrite existing configurations.

[jorgecoca]

We would still use the native SDKs and platform channels; the changes would imply only to avoid modifying the AndroidManifest and Info.plist to pass parameters, and instead pass those from Dart

[MaiKaY]

Sounds good to me. Feel free to work on a PR to support this.

[MaiKaY]

Hi @jorgecoca,
we just released version 3.2.0 which added support to install through dart.