Project config templating

[j3k0]

For now, the project configuration allows replacing variables like so:

${somevar} gets replaced with project.configuration.somevar.

Some thoughts.

1. conditionals

If would be nice to be able to some thing like this:

${ env = "production" ? somevar : someothervar }

2. application descriptor

Shouldn't the application descriptor be a template too?

3. overrides

Instead of modifying the project when building for different targets, allow the project configuration to be overriden with environment variables. I'm preparing PR with this idea. (Done #43)

[j3k0]

4. add "identifier", "version", "name", "versionLabel"

Adding those root fields to the project configuration will allow to use them in the templates. Could be done quite easily in "config.loadProjectDefinition()" from #43.

[marchbold]

I don't think conditionals in the config files are a good idea.

I'd prefer to see something more standard like build configurations defined in the project file. This is how Android and many other systems handle this process and we have to work within the Android merge system to correctly handle the manifest merge. Placing conditionals in the android manifest will fail so I'd prefer to keep a consistent system in place across all platforms.

Also I'm not sure the use of the name "template" is right here. I was using that for the application descriptor but that isn't really correct for the ios and android manifest files. These are additional files that are merged into the info additions / entitlements / manifest.

[j3k0]

I'm facing the following issue with the PushNotifications ANE that could be an argument in favor of conditionals though.

The FirebaseInitProvider needs to be removed when using "Manual" configuration (which I know is not the recommended way of doing it, but was the only one that worked for me at the time, but this is another story).

If the config file could do something like this, it could be easier to implement:

%{if firebaseInitUseResource}
<provider
    android:authorities="APPLICATION_PACKAGE.firebaseinitprovider"
    android:name="com.google.firebase.provider.FirebaseInitProvider"
    android:exported="false"
    android:initOrder="100"
/>
%{endif}

It can be solved by distributing another version of the ANE, but then an ANE requires multiple conditionals, it becomes very cumbersome to create a different package for each possible combination. Like MyANE-disableX-enableY-disableZ, MyANE-enableX-disableY-disableZ, etc. ?

[marchbold]

There is already a method to do this built into the Android merge tools. You just add the following to your custom android manifest

<provider
    android:name="com.google.firebase.provider.FirebaseInitProvider"
    android:authorities="${applicationId}.firebaseinitprovider"
    tools:node="remove"
    />

You might need to add the tools namespace to the manifest tag :

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"

Let me know if this doesn't work for you. I haven't tested this yet, but this is the intended approach.