React-native-onesignal: onIds-Probleme

Erstellt am 19. Feb. 2017  ·  25Kommentare  ·  Quelle: OneSignal/react-native-onesignal

Hallo, ich habe OneSignalController, den ich in Main.js einfüge

class OneSignalController extends Component {
    props: Props

    constructor(props) {
        super(props);
    }
    componentWillMount() {
        OneSignal.addEventListener('opened', this.onOpened);
        OneSignal.addEventListener('ids', this.onIds);
    }

    componentWillUnmount() {
        OneSignal.removeEventListener('opened', this.onOpened);
        OneSignal.removeEventListener('ids', this.onIds);
    }

    onIds = (device) => {
        this.props.dispatch_set_device_id(device.userId);
    }

    render() {
        return null;
    }
}

Ich verwende redux-persist und möchte die App nicht starten, bevor rehydration fertig ist.
Also möchte ich das in meinem index.android.js

...
        this.state = { rehydrated: false };
    }

    componentWillMount() {
      Storage.restoreData(store, {}, () => {
        this.setState({ rehydrated: true });
        });
    }

    render() {
        return (
            this.state.rehydrated === true
            ? <Provider store={store}>
                <View style={styles.container}>
                    <Main />
                </View>
            </Provider>
            : null
        );
    }

Aber wenn ich das mache, löst oneSignal die onIds Funktion nicht mehr aus.

Help Wanted

Hilfreichster Kommentar

Ich habe gerade angefangen, diese Lib zu verwenden und bin auf das gleiche Problem gestoßen. Redux-persist auch hier verwenden! Und nach einigen Recherchen glaube ich fest, dass es mit Redux-Persisting zu tun hat . Oder jedes verzögerte Abonnement des ids Ereignisses .

Der folgende Code wird, wenn er direkt in index.xxx.js (dh sehr früh beim App-Start), bei jedem App-Neustart ausgelöst:

//... other imports
import OneSignal from "react-native-onesignal";

OneSignal.addEventListener('ids', (device) => {
    console.log("[OneSignal]>>ids: ", device);
});

// ....

AppRegistry.registerComponent ....

Wenn jedoch OneSignal.addEventListener('ids' ... nach Redux-Persist Rehydration aufgerufen wird => Küsse den Callback auf Wiedersehen.

FIX So habe ich es (gehackt?) vorerst behoben (aktuelles React-Native-Onesignal-Release 3.0.3):

Es gibt eine undokumentierte js-seitige Methode namens OneSignal.configure() , die die native Seite ( android und ios ) veranlasst, das ids Ereignis zurück an die js-Seite zu senden.

Rufen Sie es also direkt nach dem Hinzufügen des Ereignis-Listeners für 'ids' auf:

// ... after store rehydration complete ...

OneSignal.addEventListener('ids', (device) => {
   // ... do whatever with device
});

OneSignal.configure();  // add this to trigger `ids` event

Nach meiner Einschätzung, wie es auf der nativen Seite implementiert ist, scheint es ziemlich sicher zu sein, das sogar mehr als einmal aufzurufen (es ersetzt nur den internen Event-Handler, erzeugt nicht mehr). Aber denken Sie daran, dass es jedes Mal die ids Listener auslöst.

Ich frage mich jetzt, ob die anderen Ereignisse funktionieren, wenn Listener später beim App-Start hinzugefügt werden.

Ich denke, dies sollte wahrscheinlich besser durch die Reactive-native-Onesignal-Lib mit einer internen Subscriber-Queue behoben werden. Ich werde versuchen, es zu versuchen, vielleicht in naher Zukunft einen Pull-Request für dieses Szenario mit verzögerter Registrierung von Ereignis-Listenern.

Alle 25 Kommentare

Ich habe einige Probleme mit onIds, die manchmal nicht aufgerufen werden. Dies hat jedoch nichts mit redux-persist zu tun.

Es scheint, als wären die OneSignal-Server nicht erreichbar? Der Doc sagt jedoch, dass es sowieso null zurückgeben sollte. Ich habe dieses Problem alle paar Versuche, es ist nicht konsistent. Ich bin mir nicht sicher, wie zuverlässig dieses Ereignis jetzt ist.

Ich habe heute noch einmal im Simulator nachgesehen und es dauerte gut 10 Sekunden, bis das "onIds"-Ereignis erhalten wurde, nachdem ich die Berechtigungen über OneSignal.requestPermissions() akzeptiert hatte.

Ich habe das gleiche Ereignis an einer anderen Stelle in der App platziert, um zu sehen, ob ich die IDs immer noch bekomme, wenn ich aktualisiere (Demo-Projektverhalten), aber es funktioniert überhaupt nicht.

Außerdem ist nicht klar, worum es bei dem "registrierten" Ereignis gehen soll, da es auf keinen Fall ausgelöst wird.

Leute, das Ereignis wird nie aufgerufen, wenn die App geschlossen und wieder geöffnet wird. Ich meine, wenn die IDs verfügbar sind, sollte dies nicht jedes Mal ausgelöst werden?

Das andere Problem ist, dass es nicht 1 von 5 Mal (Durchschnitt) ausgelöst wird, wenn der Benutzer Push-Benachrichtigungen akzeptiert. Dies wäre kein Problem, wenn das erste Problem in Ordnung wäre, sodass wir die ID beim nächsten Öffnen der App durch den Benutzer abrufen könnten.

Ich habe gerade angefangen, diese Lib zu verwenden und bin auf das gleiche Problem gestoßen. Redux-persist auch hier verwenden! Und nach einigen Recherchen glaube ich fest, dass es mit Redux-Persisting zu tun hat . Oder jedes verzögerte Abonnement des ids Ereignisses .

Der folgende Code wird, wenn er direkt in index.xxx.js (dh sehr früh beim App-Start), bei jedem App-Neustart ausgelöst:

//... other imports
import OneSignal from "react-native-onesignal";

OneSignal.addEventListener('ids', (device) => {
    console.log("[OneSignal]>>ids: ", device);
});

// ....

AppRegistry.registerComponent ....

Wenn jedoch OneSignal.addEventListener('ids' ... nach Redux-Persist Rehydration aufgerufen wird => Küsse den Callback auf Wiedersehen.

FIX So habe ich es (gehackt?) vorerst behoben (aktuelles React-Native-Onesignal-Release 3.0.3):

Es gibt eine undokumentierte js-seitige Methode namens OneSignal.configure() , die die native Seite ( android und ios ) veranlasst, das ids Ereignis zurück an die js-Seite zu senden.

Rufen Sie es also direkt nach dem Hinzufügen des Ereignis-Listeners für 'ids' auf:

// ... after store rehydration complete ...

OneSignal.addEventListener('ids', (device) => {
   // ... do whatever with device
});

OneSignal.configure();  // add this to trigger `ids` event

Nach meiner Einschätzung, wie es auf der nativen Seite implementiert ist, scheint es ziemlich sicher zu sein, das sogar mehr als einmal aufzurufen (es ersetzt nur den internen Event-Handler, erzeugt nicht mehr). Aber denken Sie daran, dass es jedes Mal die ids Listener auslöst.

Ich frage mich jetzt, ob die anderen Ereignisse funktionieren, wenn Listener später beim App-Start hinzugefügt werden.

Ich denke, dies sollte wahrscheinlich besser durch die Reactive-native-Onesignal-Lib mit einer internen Subscriber-Queue behoben werden. Ich werde versuchen, es zu versuchen, vielleicht in naher Zukunft einen Pull-Request für dieses Szenario mit verzögerter Registrierung von Ereignis-Listenern.

Wenn Sie OneSignal.configure() aufrufen; vor dem Ereignis-Listener funktioniert dies gut. Ich bin mir nicht einmal sicher, ob es redux-persist ist.

Nur eine kurze Anmerkung Ich hatte gerade dieses Problem mit einem unberechenbaren Verhalten, bei dem das onIds-Ereignis nicht ausgelöst wurde.

Nachdem ich nun die Konfigurationsfunktion zu einer anderen Komponente hinzugefügt habe, die etwas später beim Start der App geladen wird, bekomme ich manchmal ein einzelnes onIds-Ereignis ausgelöst und manchmal zwei (da das Original gelegentlich immer noch ausgelöst wird).

Es ist erwähnenswert, dass ich dies nicht auf Release-Builds getestet habe und derzeit auf Android, React Native 0.38 debugge.

Wenn es in der Tat keine negativen Auswirkungen hat, mehrmals configure aufzurufen, dann denke ich, dass es in Ordnung ist. Ich werde mich nur damit befassen, dass es meine API jedes Mal zweimal trifft, wenn ein Benutzer die Anwendung gelegentlich fortsetzt.

Wenn dies zu einem negativen Ergebnis (außer Ineffizienz) führt, lassen Sie es mich bitte wissen, da dies kein Fachgebiet für mich ist.

Ich habe das gleiche und wir sind in der Produktion. ;) Ja, ich rufe die API zweimal auf. :(

Hallo @edo1493 , ich habe auch das gleiche Problem. Wie rufen Sie die API zweimal auf?

Mir ist aufgefallen, dass das Event ohne Neuladen der App (Dev-Modus) erst nach 35s ausgelöst wird

Bearbeiten:
Dies geschieht beim ersten Laden der App
Plattform: Android

Vielleicht kann @jkasten2 hier helfen, ich denke, mit dieser speziellen Bibliothek ist das kein Problem,

@edo1493 onIds wird nicht ausgelöst, es sei denn, es kann eine Spieler- / Benutzer-ID vom OneSignal-Server abrufen. Dies bedeutet, dass userId niemals null aber pushToken kann es sein, wenn APNs / FCM nicht rechtzeitig antwortet. Das Problem scheint mit der Verbindung verbunden zu sein. Können Sie versuchen, setLogLevel im nativen Code aufzurufen, um die Protokollierung von Netzwerkanrufen zu aktivieren? Wenn Sie das Problem mit Android reproduzieren können, werden weitere Details zu Anrufen im Logcat im Vergleich zum Xcode-Protokoll mit iOS angezeigt.

Allerdings scheint das Problem am meisten mit redux-persist was höchstwahrscheinlich ein Problem in der Javascript-Schicht mit dem OneSignal-Plugin bedeuten würde. @avishayil Können Sie versuchen, das Problem mit redux-persist reproduzieren und versuchen, das Problem zu lokalisieren ? Teilen Sie das Projekt, sobald Sie dies tun, ich kann auch versuchen, es zu debuggen.

@jkasten2 Ich verwende redux-persist derzeit nicht in meinen Projekten, daher wäre es schwierig, die Zeit zum Reproduzieren zu finden. Ich denke, es wäre einfacher, wenn einer der Leute hier ein Repo mit redux-persist mit dem reproduzierten Problem teilt.

Redux nicht verwenden und dies ist immer noch ein Problem.

Danke @rcugut ! OneSignal.configure() sofort beheben! Ich benutze auch redux-persist ! Das muss behoben werden!

Das Hinzufügen von .configure hat es auch für mich behoben, ich verwende kein Reagieren-Persistieren.

Bei mir funktioniert OneSignal.configure() Hack auch, aber mir ist aufgefallen, dass OneSignal.removeEventListener("ids", this.onIds) nicht funktioniert. Nicht sicher, ob das zusammenhängt. Irgendwelche Ideen, wie man das beheben kann?

mit der gleichen Sache konfrontiert wie @junedomingo

In Android wird beim ersten Laden der App das ids-Ereignis nach 35 Sekunden aufgerufen

Ich habe kein Problem auf Android, das Ereignis startet ohne Probleme.
Aber ich habe Probleme mit iOS, wo ich nie in die onIds() Funktion komme...
Das Hinzufügen von OneSignal.configure() vor oder nach den Ereignis-Listenern und vor oder nach Abschluss der Rehydratation (ja, ich verwende redux-persist ) hat nicht geholfen.
Hat jemand eine Idee?

@jkasten2 Ich habe das gleiche Problem, das @junedomingo hier auf

     OneSignal.idsAvailable(new OneSignal.IdsAvailableHandler() {
            public void idsAvailable(String userId, String registrationId) {
                final WritableMap params = Arguments.createMap();

                params.putString("userId", userId);
                params.putString("pushToken", registrationId);

                sendEvent("OneSignal-idsAvailable", params);
            }
        });

es reagiert nach 30 Sekunden!
habt ihr eine idee/lösung?

wenn Sie OneSignal.setRequiresUserPrivacyConsent(true) haben;
es funktioniert nicht, bis Sie zustimmen!
OneSignal.provideUserConsent(true);

Rufen Sie auch OneSignal.configure() auf, nachdem Sie Listener hinzugefügt haben.
Hoffnung funktioniert für dich!!!

Gleiches Problem
Version: v3.3.1
Plattform: iOS

Wie Sie hier sehen können, ist userId null, erst nach 29 Sekunden löst der Event-Listener mit der userId aus. Dies ist beim ersten Start nach der Neuinstallation der App.
Screen Shot 2019-08-05 at 3 04 59 PM

Hat noch jemand dieses Problem?
Das Ereignis wird erst nach ~30 Sekunden beim Clear Boot in Android ausgelöst.

@damathryx Hallo, ich habe beim ersten Start die gleiche userId null. Hast du eine Lösung dafür gefunden?

Dieses Problem sollte wieder geöffnet werden 😩

Für mich kommen Push-Benachrichtigungen auf Android nicht ohne .configure . IDs werden jetzt problemlos ausgelöst, Geräteinformationen werden empfangen, aber Benachrichtigungen selbst funktionieren nicht.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen