OneSignal / react-native-onesignal

React Native Library for OneSignal Push Notifications Service
Other
1.57k stars 374 forks source link

in Android, OneSignal.sendTags works in version 3.1.4, doesn't work in versions 3.2.5 and 3.2.6 #629

Closed rahamin1 closed 6 years ago

rahamin1 commented 6 years ago

Description: I am calling sendTags from my android app. It works in version 3.1.4, doesn't work on 3.2.5 and 3.2.6

According to another user, @magick93, he has the same problem (see #117)

Environment From my package.json: "react": "16.2.0", "react-native": "0.51.0", (also tried 0.56) "react-native-onesignal": "3.2.6",

Steps to Reproduce Issue:

  1. call oneSignal.sendTags
  2. Wait a minute, even more
  3. call oneSignal.getTags

Expected result Tags are retrieved by getTags

Actual Result

Nightsd01 commented 6 years ago

@rahamin1 If the tags aren't getting sent within 15 seconds there's no need to wait longer.

I can't reproduce this issue, tags in 3.2.6 seem to be working fine on my end. Can you reproduce this issue with our demo project?

If not, can you make sure to call OneSignal.setLogLevel(6, 0) before initializing our SDK and post a logcat? Make sure to put "Sending Tags from RN" statements so I know where in your logcat tags were sent

rahamin1 commented 6 years ago

Never used logcat but I know that I need to run android studio for activating it, right? I am not a big fan of android studio... Is there any way to produce logs when using genymotion without android studio?

@magick93, if you can provide what @Nightsd01 is asking, it will be great.

Nightsd01 commented 6 years ago

@rahamin1 You can run the command adb logcat in terminal without needing to run android studio to collect logs.

rahamin1 commented 6 years ago

@Nightsd01 I forgot to ask:

Make sure to put "Sending Tags from RN" statements

Do you mean to put console.log statements?

Nightsd01 commented 6 years ago

@rahamin1 yep

rahamin1 commented 6 years ago

log files

@Nightsd01, Attached below the two log files, one where we use version 3.1.4, the other with 3.2.6. Yossi-oneSignal-logs.zip

How I collected the logs

You can find all my console.log messages by searching for RN oneSignal.

I did the following to collect these logs, not sure if this is the right way to do it. I am using Windows 10.

Then I started the app in the genymotion emulator, and did the following:

Error messages that I see in both logs

I see in both logs the same error messages:

The Fabric message comes just after the log message that I am printing form the app, before calling OneSignal.addEventListener. I am not sure, however, that it is related to oneSignal, since I am not adding any object or array. This is the code for adding the events listeners:

OneSignal.addEventListener('received', this.onReceived)
OneSignal.addEventListener('opened', this.onOpened)
OneSignal.addEventListener('ids', this.onIds)
OneSignal.inFocusDisplaying(0)

Regarding the oneSignal error, it seems a good reason for my problem, however I get it in both versions of RN oneSignal, and it doesn't seem to impact the build with version 3.1.4...

If the Fabric message relates to the addEventListener calls, then the failure of sendTags is clear... However, it is not clear to me how 3.1.4 is working and why I am getting the error messages.

Thanks for helping!

Nightsd01 commented 6 years ago

@rahamin1 Interesting, that warning message from OneSignal is definitely related.

Are you sending tags instantly (synchronously in the same function call) that you init OneSignal in?

How do you initialize the SDK (manifest placeholders, or using the init method in JS)?

Do you run into a similar log warning when you attempt to call getTags?

Can you try hooking up a button in your app to sendTags, wait a few seconds, then press the button and let me know if those tags get sent?

rahamin1 commented 6 years ago

@Nightsd01

Are you sending tags instantly (synchronously in the same function call) that you init OneSignal in?

No. Only when a button is pressed for adding a new tag. The assumption is that if tags are already set when the app is started, they are also set already in the server. In the 3.2.6 log I see that (by searching for RN oneSignal):

How do you initialize the SDK (manifest placeholders, or using the init method in JS)?

I didn't write the code, I am trying to fix it... I don't see any use of the init method in JS, so it is probably another way... What are manifest placeholders? Will init from JS will make a difference? BTW, I see in the code a function called checkIfInitialized, but it is not exported for RN use. If it is available, I could check to see if initialization is done.

Do you run into a similar log warning when you attempt to call getTags?

Just checked in the logs that I sent you - seems that it fails in 3.2.6, succeeds in 3.1.4.

Can you try hooking up a button in your app to sendTags, wait a few seconds, then press the button and let me know if those tags get sent?

No need, since that's what is done already...

Nightsd01 commented 6 years ago

@rahamin1 can you check your app/build.gradle file and see if you are putting your OneSignal app ID in there?

Do actual push notifications work in your app?

Can you call OneSignal.getPermissionSubscriptionState() and check to make sure you are actually getting registered and have a OneSignal user ID (playerId)?

rahamin1 commented 6 years ago

@Nightsd01

can you check your app/build.gradle file and see if you are putting your OneSignal app ID in there?

Yes, it is there:

manifestPlaceholders = [
     'onesignal_app_id': "4bd75bb0-925d-42f8-b9cd-741d86005d4e",
     'onesignal_google_project_number': "749411725398"
]

Do actual push notifications work in your app?

When I build with 3.1.4, I see notifications in the status bar, the events handlers of onOpened and onReceived are triggered multiple times.

Can you call OneSignal.getPermissionSubscriptionState() and check to make sure you are actually getting registered and have a OneSignal user ID (playerId)?

I did several tests with version 3.2.6:

log from the test with the call to OneSignal.init

RN.3.2.6.update1.log

Last thing: a warning that I get during build - any idea how to handle it? Can it be related to the problems I am having?

I just noticed that when I run 'react-native run-android I get the following warning (may have been there long ago, there are many messages there...):

WARNING: The onesignal-gradle-plugin MUST be before com.android.application!
   Please put onesignal-gradle-plugin first OR update to com.android.tools.build:gradle:3.0.0 or newer!
Incremental java compilation is an incubating feature.

I assume that it relates to the `android\app\build.gradle' file (attached), but I am not sure how to deal with it... (I added .txt in order to be able to attach it here)

build.gradle.txt

Nightsd01 commented 6 years ago

@rahamin1 It looks like you are adding our gradle plugin at the end of your app/build.gradle, but you need to add it to the very VERY top. ie. here is a fixed version of your app/build.gradle:

buildscript {
  repositories {
    maven { url 'https://maven.fabric.io/public' }
    maven { url 'https://plugins.gradle.org/m2/' } // Gradle Plugin Portal
  }

  dependencies {
    // These docs use an open ended version so that our plugin
    // can be updated quickly in response to Android tooling updates

    // We recommend changing it to the latest version from our changelog:
    // https://docs.fabric.io/android/changelog.html#fabric-gradle-plugin
    classpath 'io.fabric.tools:gradle:1.+'
    classpath 'gradle.plugin.com.onesignal:onesignal-gradle-plugin:0.10.2'

  }
}

apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'

apply plugin: "com.android.application"

import com.android.build.OutputFile

/**
 * The react.gradle file registers a task for each build variant (e.g. bundleDebugJsAndAssets
 * and bundleReleaseJsAndAssets).
 * These basically call `react-native bundle` with the correct arguments during the Android build
 * cycle. By default, bundleDebugJsAndAssets is skipped, as in debug/dev mode we prefer to load the
 * bundle directly from the development server. Below you can see all the possible configurations
 * and their defaults. If you decide to add a configuration block, make sure to add it before the
 * `apply from: "../../node_modules/react-native/react.gradle"` line.
 *
 * project.ext.react = [
 *   // the name of the generated asset file containing your JS bundle
 *   bundleAssetName: "index.android.bundle",
 *
 *   // the entry file for bundle generation
 *   entryFile: "index.android.js",
 *
 *   // whether to bundle JS and assets in debug mode
 *   bundleInDebug: false,
 *
 *   // whether to bundle JS and assets in release mode
 *   bundleInRelease: true,
 *
 *   // whether to bundle JS and assets in another build variant (if configured).
 *   // See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
 *   // The configuration property can be in the following formats
 *   //         'bundleIn${productFlavor}${buildType}'
 *   //         'bundleIn${buildType}'
 *   // bundleInFreeDebug: true,
 *   // bundleInPaidRelease: true,
 *   // bundleInBeta: true,
 *
 *   // whether to disable dev mode in custom build variants (by default only disabled in release)
 *   // for example: to disable dev mode in the staging build type (if configured)
 *   devDisabledInStaging: true,
 *   // The configuration property can be in the following formats
 *   //         'devDisabledIn${productFlavor}${buildType}'
 *   //         'devDisabledIn${buildType}'
 *
 *   // the root of your project, i.e. where "package.json" lives
 *   root: "../../",
 *
 *   // where to put the JS bundle asset in debug mode
 *   jsBundleDirDebug: "$buildDir/intermediates/assets/debug",
 *
 *   // where to put the JS bundle asset in release mode
 *   jsBundleDirRelease: "$buildDir/intermediates/assets/release",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in debug mode
 *   resourcesDirDebug: "$buildDir/intermediates/res/merged/debug",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in release mode
 *   resourcesDirRelease: "$buildDir/intermediates/res/merged/release",
 *
 *   // by default the gradle tasks are skipped if none of the JS files or assets change; this means
 *   // that we don't look at files in android/ or ios/ to determine whether the tasks are up to
 *   // date; if you have any other folders that you want to ignore for performance reasons (gradle
 *   // indexes the entire tree), add them here. Alternatively, if you have JS files in android/
 *   // for example, you might want to remove it from here.
 *   inputExcludes: ["android/**", "ios/**"],
 *
 *   // override which node gets called and with what additional arguments
 *   nodeExecutableAndArgs: ["node"],
 *
 *   // supply additional arguments to the packager
 *   extraPackagerArgs: []
 * ]
 */

project.ext.react = [
    entryFile: "index.js"
]

apply from: "../../node_modules/react-native/react.gradle"

/**
 * Set this to true to create two separate APKs instead of one:
 *   - An APK that only works on ARM devices
 *   - An APK that only works on x86 devices
 * The advantage is the size of the APK is reduced by about 4MB.
 * Upload all the APKs to the Play Store and people will download
 * the correct one based on the CPU architecture of their device.
 */
def enableSeparateBuildPerCPUArchitecture = false

/**
 * Run Proguard to shrink the Java bytecode in release builds.
 */
def enableProguardInReleaseBuilds = false

configurations.all {
  resolutionStrategy.force 'com.google.android.gms:play-services-gcm:11.8.0'
  // resolutionStrategy.force 'com.google.android.gms:play-services-analytics:11.8.0'
  resolutionStrategy.force 'com.google.android.gms:play-services-location:11.8.0'
  resolutionStrategy.force 'com.facebook.android:facebook-android-sdk:4.18.0'
}

def DEFAULT_COMPILE_SDK_VERSION = 26
def DEFAULT_BUILD_TOOLS_VERSION = "23.0.1"
def DEFAULT_TARGET_SDK_VERSION = 26

android {
    compileSdkVersion 26
    buildToolsVersion "26.0.1"

    defaultConfig {
        applicationId "eu.priceinsight.mobileapp"
        minSdkVersion 16
        targetSdkVersion 26
        versionCode System.getenv('PARAM_VERSION_NUMBER').toInteger()
        versionName "0.0."+versionCode
        ndk {
            abiFilters "armeabi-v7a", "x86"
        }
        manifestPlaceholders = [
            'onesignal_app_id': "4bd75bb0-925d-42f8-b9cd-741d86005d4e",
            'onesignal_google_project_number': "749411725398"
        ]
    }
    splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false  // If true, also generate a universal APK
            include "armeabi-v7a", "x86"
        }
    }
    buildTypes {
        release {
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
        }
    }
    // applicationVariants are e.g. debug, release
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            // For each separate APK per architecture, set a unique version code as described here:
            // http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits
            def versionCodes = ["armeabi-v7a":1, "x86":2]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) {  // null for the universal-debug, universal-release variants
                output.versionCodeOverride =
                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }
        }
    }
}

dependencies {
    compile project(':react-native-link-preview')
    compile project(':react-native-fabric')
    compile project(':react-native-spinkit')
    compile project(':react-native-push-notification')
    // compile project(':react-native-google-analytics-bridge')
    compile project(':react-native-svg')
    compile project(':react-native-onesignal')
    compile project(':react-native-vector-icons')
    compile fileTree(dir: "libs", include: ["*.jar"])
    compile 'com.android.support:appcompat-v7:26.0.0-alpha1'
    compile "com.facebook.react:react-native:+"  // From node_modules
    compile project(':react-native-fabric')
    compile('com.crashlytics.sdk.android:crashlytics:2.9.4@aar') {
        transitive = true;
    }
}

// Run this once to be able to run the application with BUCK
// puts all compile dependencies into folder libs for BUCK to use
task copyDownloadableDepsToLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}
apply plugin: 'io.fabric'

repositories {
  maven { url 'https://maven.fabric.io/public' }
}
Nightsd01 commented 6 years ago

@rahamin1 As a troubleshooting step, please remove the manifestPlaceholders entirely from your app/build.gradle. In React-Native JS, try calling OneSignal.init("your_app_id") instead.

Let me know if the issue still occurs.

And when I asked if you could receive push notifications, I was asking about 3.2.6 not 3.1.4

rahamin1 commented 6 years ago

@Nightsd01

(since Nightsd01 is not available in the last few days, perhaps you - @ashokkumar88 or @OlaAlsaker or @sagarv1997 can answer the following? I saw that you were discussing OneSignal.init issues in another issue).

As a troubleshooting step, please remove the manifestPlaceholders entirely from your app/build.gradle. In React-Native JS, try calling OneSignal.init("your_app_id") instead.

Works fine now.

But, aren't the manifestPlaceholders in app/build.gradle required? Or, are they used only for initialization, so that calling OneSignal.init("app_id") can be used instead?

In other words, can it remain this way (calling init instead of the manifestPlaceholders) or should I remove init and restore manifestPlaceholders? If one is preferred over the the other, can you explain why, please?

Thanks much Yossi

jkasten2 commented 6 years ago

@rahamin1 The manifestPlaceholders used to be required but we have deprecated them for this react native SDK. OneSignal.init("YOUR_APP_ID") is the new recommended way.

manifestPlaceholders will still be support for a long while, until a 4.0 release.

Nightsd01 commented 6 years ago

Now that we've figured this out, I have created a separate issue to investigate the fact that initialization using manifest placeholders no longer appears to work: https://github.com/geektimecoil/react-native-onesignal/issues/639