invertase / react-native-notifee

Moved to https://github.com/invertase/notifee
https://invertase.io/blog/open-sourcing-notifee
Other
465 stars 31 forks source link

Feature request: do not use notifee.config.json and initialize lib manually #37

Closed tautvilas closed 4 years ago

tautvilas commented 4 years ago

I have multiple environments: production, staging. That means I have to have several notifee.config.json files with primary and secondary keys and copy the right one during the build.

I would prefer that there would be a way to initialize the library in this way: Notifee.initializeLibrary(key) from JS code.

mikehardy commented 4 years ago

I wouldn't do that - I would set up your infrastructure more formally - I detailed one way here, might work for you?

https://github.com/invertase/react-native-firebase/issues/3504#issuecomment-616796121

tautvilas commented 4 years ago

Hey @mikehardy , thanks for the input. I have more formal separation but did not want to go into details too much. In case of android I have three build flavors: debug, staging and release. That enables to build separate apps like you suggested. In Firebase case I have put config jsons in android/app/src/flavor. However as I understand this is not supported by Notifee yet and .json has to be put in root folder.

For dependencies that need configuration keys I store these keys in my build.gradle. Example:

buildTypes {
        debug {
            signingConfig signingConfigs.debug
            applicationIdSuffix ".dev"
            versionNameSuffix "Dev"
            buildConfigField "String", "INTERCOM_API_KEY", "-"
            buildConfigField "String", "SEGMENT_WRITE_KEY", "-"
            buildConfigField "String", "STRIPE_PUBLIC_KEY", "-"
        }
       staging {
            applicationIdSuffix ".stage"
            versionNameSuffix "Staging"
            buildConfigField "String", "INTERCOM_API_KEY", "-"
            buildConfigField "String", "SEGMENT_WRITE_KEY", "-"
            buildConfigField "String", "STRIPE_PUBLIC_KEY", "-"
       }
} 

Then in my JS code I read this configuration variable using react-native-config-reader and inject the value in library when starting it. So in this case I would like to define three NOTIFEE_KEY values in my build gradle and then inject in javascript app.js by using notifee.initialize(RNConfigReader.NOTIFEE_KEY)

Salakar commented 4 years ago

@tautvilas I'll add this to be reviewed - if the implementation is fairly straightforward then I don't see any reason why we can't support it for folks that want to configure it through native build systems rather than the json file

mikehardy commented 4 years ago

Oh I see - yes then @Salakar I for instance would need that as a critical feature because it's how I split back-end environments (inclusive of application IDs / bundle IDs which the notifee license would key on). I based it on guides online when I set it up so I'm certain I'm not the only one either, along with @tautvilas

Salakar commented 4 years ago

FYI: this is in progress on #67

davidgovea commented 4 years ago

Really looking forward to this! I'd be happy if notifee had a similar config process to firebase.

Runtime config as proposed in this issue would also work, but I could see there being difficulties with licensing: notifee would always have to "run unlicensed" until the JS environment was set up & config provided, vs. a baked-into-build config.


My app has several buildTypes+flavors on Android, and several Schemes+BuildConfigurations on iOS. With firebase, the situation is:

Not sure if there is a better way on iOS -- as far as I know, there is built-in no way to split files by build configuration.


Looks like #67 will address the android side, and maybe documenting an example Build Phases script on iOS would be enough to address this issue?

# UNTESTED -- don't use yet
# Adapted from https://medium.com/rocket-fuel/using-multiple-firebase-environments-in-ios-12b204cfa6c0

# Name of the resource we're selectively copying
NOTIFEE_CONFIG=notifee.config.json

# Get references to dev and prod versions of the notifee.config.json
# NOTE: These should only live on the file system and should NOT be part of the target (since we'll be adding them to the target manually)
NOTIFEE_CONFIG_DEV=${PROJECT_DIR}/${TARGET_NAME}/Notifee/Dev/${NOTIFEE_CONFIG}
NOTIFEE_CONFIG_PROD=${PROJECT_DIR}/${TARGET_NAME}/Notifee/Prod/${NOTIFEE_CONFIG}

# TODO - exit 1 if config files do not exist

# Get a reference to the destination location for the notifee.config.json
CONFIG_DESTINATION=${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app
echo "Will copy ${NOTIFEE_CONFIG} to final destination: ${CONFIG_DESTINATION}"

# Copy over the prod notifee.config.json for Release builds
if [ "${CONFIGURATION}" == "Release" ]
then
    echo "Using ${NOTIFEE_CONFIG_PROD}"
    cp "${NOTIFEE_CONFIG_PROD}" "${CONFIG_DESTINATION}"
else
    echo "Using ${NOTIFEE_CONFIG_DEV}"
    cp "${NOTIFEE_CONFIG_DEV}" "${CONFIG_DESTINATION}"
fi
mikehardy commented 4 years ago

@davidgovea

iOS: A custom script in "Build Phases" copies the correct plist into place at GoogleServices-Info.plist files into place during build. Custom shell script with custom naming, but it's worked and maintenance has been easy. (See article with this technique: https://medium.com/rocket-fuel/using-multiple-firebase-environments-in-ios-12b204cfa6c0)

Not sure if there is a better way on iOS -- as far as I know, there is built-in no way to split files by build configuration.

I use Xcode targets/schemes, they seem to work and were intended for this situation? The plist files have each different one set to be a member of only the appropriate one

package.json snippets

    "ios-dev-mike-ipad": "npx react-native run-ios --scheme Komp.aiDev --device \"Hardy iPad\"",
    "ios-test-debug": "npx react-native run-ios --scheme Komp.aiTest --simulator \"iPhone 11\"",
    "ios-staging-debug": "npx react-native run-ios --scheme Komp.aiStaging --simulator \"iPhone 11\"",
    "ios-prod-debug": "npx react-native run-ios --scheme Komp.aiProd --simulator \"iPhone 11\"",

plist locations

mike@isabela:~/work/Kullki/ksocialscore/packages/public-app (rebranding) % find . |grep Google|grep plist
./ios/KScoreApp/Prod/GoogleService-Info.plist
./ios/KScoreApp/Dev/GoogleService-Info.plist
./ios/KScoreApp/Staging/GoogleService-Info.plist
./ios/KScoreApp/Test/GoogleService-Info.plist
davidgovea commented 4 years ago

@mikehardy ah -- I have things all set up under one target, with multiple schemes and configs. Targets are the way to control file membership. I'll consider moving to multiple targets in the future.

Salakar commented 4 years ago

Please see my comment here: https://github.com/notifee/react-native-notifee/pull/67#issuecomment-640136025

This change is live in 0.6.2 - changelog still to do but theres only 1 breaking change, renaming usages of Importance to AndroidImportance.

Alternatively you can completely ignore the json config for Android and just add a notifee_config_license string resource xml to your various flavors and build types.

As for iOS we've not looked into it yet, so to ease usage for now I've turned off licensing verification on iOS, so you don't need to put in a key right now for iOS - we can worry about this then in a later release, most likely v1.