Closed rahamin1 closed 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
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.
@rahamin1 You can run the command adb logcat
in terminal without needing to run android studio to collect logs.
@Nightsd01 I forgot to ask:
Make sure to put "Sending Tags from RN" statements
Do you mean to put console.log statements?
@rahamin1 yep
@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
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:
I see in both logs the same error messages:
E ReactNativeFabric: Can't add objects or arrays
E OneSignal: You must initialize OneSignal before modifying tags!Moving this operation to a pending task queue.
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!
@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?
@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...
@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)?
@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)?
getPermissionSubscriptionState
. Returns null or, in some cases, does not return at all (the callback function is not called)oneSignal.init
before calling getPermissionSubscriptionState
. It returns with notificationEnabled === true
oneSignal.init
from the code. getPermissionSubscriptionState
still returns notificationEnabled === true
E OneSignal
)W OneSignal: Both GCM & FCM Libraries detected! Please remove the deprecated GCM library.
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)
@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' }
}
@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
@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
@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.
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
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:
Expected result Tags are retrieved by getTags
Actual Result