Read the Write Key

[LeonardoRosaa]

The most applications to Flutter have support for IOS and Android therefore it does make sense to keep the loading WRITE_KEY within the package.

[danielgomezrico]

@LeonardoRosaa what's the purpose of this write key? I want to have more context to understand the value of the implementation

[LeonardoRosaa]

@LeonardoRosaa what's the purpose of this write key? I want to have more context to understand the value of the implementation

I felt that is unnecessary that the client needs to do their logic to get the Android or IOS write key.

This PR implements that the own package solves the logic to load the right key.

[danielgomezrico]

@LeonardoRosaa thanks for the answer, I was asking about the write key related to segment, I dont have context about the purpose of this, excuse for that

[LeonardoRosaa]

@LeonardoRosaa thanks for the answer, I was asking about the write key related to segment, I dont have context about the purpose of this, excuse for that

The write key is required to send data to the Segment Platform.

[savy-91]

@LeonardoRosaa thanks for the answer, I was asking about the write key related to segment, I dont have context about the purpose of this, excuse for that

@danielgomezrico to make it more clear, currently users have to do something like this:

    Segment.config(
        options: SegmentConfig(
      writeKey: Platform.isAndroid ? ANDROID_WRITE_KEY : IOS_WRITE_KEY,
      trackApplicationLifecycleEvents: true,
    ));

@LeonardoRosaa moved the logic to decide which write key to use in the package, so when initializing Segment the user has to provide both write keys and this library will then decide which one to use depending on the platform.

[danielgomezrico]

Sorry for the delay

I was thinking that not every project has iOS and android at the same time, we are currently working on a project that started as android only. So, I'm thinking that this use case may break for some people, and so we should not move into that direction? 🤔

[LeonardoRosaa]

I was thinking that not every project has iOS and android at the same time, we are currently working on a project that started as android only. So, I'm thinking that this use case may break for some people, and so we should not move into that direction? 🤔

Does make sense to start the package on a platform that will not use the package?

[danielgomezrico]

Sorry, I don't get your question, we are using it, but currently we have only android (on our project), can you reword your question please?