Different build environments.

[man4ik]

Please provide a sample which has different values for different build variants.

[zsoltk]

I'm not sure I get what you mean. Please elaborate.

[man4ik]

 productFlavors {
    dev {
        buildConfigField 'String', 'EXAMPLE_0', '"some value 000"'
        buildConfigField 'boolean', 'EXAMPLE_1', 'true'
    }
    prod {
        buildConfigField 'String', 'EXAMPLE_0', 'some value 111'
        buildConfigField 'boolean', 'EXAMPLE_1', '"false"'
    }

How can I replace above code by paperwork?
Different values of same variables for different productFlavors

[zsoltk]

Right. I'm not sure if it's even theoretically possible to do that automatically, as you define your flavors / buildtypes in the android block. Maybe there's a workaround to access the current one outside of that scope, and someone will correct me on this.

What you can do however, is you could have a plugin config like:

paperwork {
    set = [
        debugKey1: "debug value",
        prodKey1: "prod value",
    ]
}

And then at runtime access it:

paperwork.get(BuildConfig.BUILD_TYPE + "Key1");

The plugin config supports arbitrary embedded structures, so in theory you could group all your debug keys in another set on level deeper without resorting to string concatenation. On the other hand, the runtime component only supports accessing a flat structure as of the moment.

[lordcodes]

I tried putting:

paperwork {
  set = [
     someKey = "some value"
  ]
}

Inside the debug block and then again in the release block to have a switch based on build type. Unfortunately, doing it this way means you have to duplicate all the keys that you want for both build types, as each paperwork block overwrites the previous.

I cannot use the prefix approach due to having another build type for development environment and would also rather not use a prefix-based approach.

Would it be possible to make it so that you can have multiple different paperwork blocks and have all the variables be added to the JSON file?

[zsoltk]

@andrewlord1990 I think what you want to achieve has to do more with groovy than with paperwork, i.e. merging those arrays. Also, why not try the same key approach, but instead of literals, you could have function calls on the right side, then override those functions per environment. I haven't checked, but it would make sense if it worked.

[lordcodes]

Okay thanks, interesting idea. Will try that out when I get a chance.

…

On 29 Jan 2017 15:07, "Zsolt Kocsi" ***@***.***> wrote: @andrewlord1990 <https://github.com/andrewlord1990> I think what you want to achieve has to do more with groovy than with paperwork, i.e. merging those arrays. Also, why not try the same key approach, but instead of literals, you could have function calls on the right side, then override those functions per environment. I haven't checked, but it would make sense if it worked. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKy1k_1JR3zMH8mmQioXXHL0hkr5Dfcrks5rXKswgaJpZM4HK1_g> .