React-native-onesignal: problème onIds

Créé le 19 févr. 2017  ·  25Commentaires  ·  Source: OneSignal/react-native-onesignal

Salut, j'ai OneSignalController que j'inclus dans Main.js

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;
    }
}

J'utilise redux-persist et je ne veux pas démarrer l'application avant que rehydration soit terminé.
donc je veux faire ça dans mon 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
        );
    }

Mais si je fais oneSignal ne déclenche plus la fonction onIds .

Help Wanted

Commentaire le plus utile

Je viens de commencer à utiliser cette bibliothèque et j'ai rencontré le même problème. En utilisant redux-persist ici aussi! Et après quelques recherches, je crois fermement que cela a à voir avec redux-persist. Ou tout abonnement différé à l'événement ids .

Le code suivant, s'il est inséré dans le index.xxx.js (c'est-à-dire très tôt dans le démarrage de l'application), il se déclenchera à chaque redémarrage de l'application :

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

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

// ....

AppRegistry.registerComponent ....

Cependant, si le OneSignal.addEventListener('ids' ... est appelé après la réhydratation redux-persist => dites au revoir au rappel.

CORRECTIF voici comment je l'ai (piraté ?) réparé, pour l'instant (version actuelle de react-native-onesignal 3.0.3) :

il existe une méthode côté js non documentée appelée OneSignal.configure() qui permet au côté natif ( android et ios ) de diffuser l'événement ids sur le côté js.

Alors, appelez-le juste après avoir ajouté l'écouteur d'événement pour « ids » :

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

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

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

D'après mon évaluation de la façon dont il est implémenté dans le côté natif et il semble être assez sûr de l'appeler, même plus d'une fois (il remplace simplement le gestionnaire d'événements interne, n'en crée pas plus). Mais gardez à l'esprit qu'il déclenche les auditeurs ids chaque fois.

Je me demande maintenant si les autres événements fonctionneront lorsque les auditeurs seront ajoutés plus tard au démarrage de l'application.

Je pense que cela devrait probablement être mieux résolu par la bibliothèque react-native-onesignal avec une file d'attente d'abonnés interne. Je vais essayer de tenter le coup, peut-être faire une pull-request dans un proche avenir pour ce scénario avec enregistrement retardé des auditeurs d'événements.

Tous les 25 commentaires

J'ai des problèmes avec les onIds, qui ne sont parfois pas appelés. Cependant, cela n'est pas lié à redux-persist.

Il semble que les serveurs OneSignal ne soient pas accessibles ? Cependant, le Doc dit qu'il devrait retourner null de toute façon. J'ai ce problème une fois tous les quelques essais, ce n'est pas cohérent. Je ne sais pas à quel point cet événement est fiable maintenant.

Je vérifiais à nouveau sur le simulateur aujourd'hui et il m'a fallu 10 bonnes secondes pour obtenir l'événement "onIds", après avoir accepté les autorisations via OneSignal.requestPermissions().

J'ai placé le même événement à un autre endroit de l'application pour voir si j'obtiens toujours les identifiants, chaque fois que j'actualise (comportement du projet de démonstration), mais cela ne fonctionne pas du tout.

De plus, il n'est pas clair ce que l'événement "enregistré" devrait être à propos d'une cause qui n'est jamais déclenchée dans tous les cas.

Les gars, l'événement n'est jamais appelé lorsque l'application est fermée et rouverte. Je veux dire, si les identifiants sont disponibles, cela ne devrait-il pas être déclenché à chaque fois ?

L'autre problème est qu'il ne se déclenche pas 1 fois sur 5 (en moyenne), lorsque l'utilisateur accepte les notifications push. Ce ne serait pas un problème si le premier problème était correct, nous pourrions donc récupérer l'identifiant la prochaine fois que l'utilisateur ouvrira l'application.

Je viens de commencer à utiliser cette bibliothèque et j'ai rencontré le même problème. En utilisant redux-persist ici aussi! Et après quelques recherches, je crois fermement que cela a à voir avec redux-persist. Ou tout abonnement différé à l'événement ids .

Le code suivant, s'il est inséré dans le index.xxx.js (c'est-à-dire très tôt dans le démarrage de l'application), il se déclenchera à chaque redémarrage de l'application :

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

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

// ....

AppRegistry.registerComponent ....

Cependant, si le OneSignal.addEventListener('ids' ... est appelé après la réhydratation redux-persist => dites au revoir au rappel.

CORRECTIF voici comment je l'ai (piraté ?) réparé, pour l'instant (version actuelle de react-native-onesignal 3.0.3) :

il existe une méthode côté js non documentée appelée OneSignal.configure() qui permet au côté natif ( android et ios ) de diffuser l'événement ids sur le côté js.

Alors, appelez-le juste après avoir ajouté l'écouteur d'événement pour « ids » :

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

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

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

D'après mon évaluation de la façon dont il est implémenté dans le côté natif et il semble être assez sûr de l'appeler, même plus d'une fois (il remplace simplement le gestionnaire d'événements interne, n'en crée pas plus). Mais gardez à l'esprit qu'il déclenche les auditeurs ids chaque fois.

Je me demande maintenant si les autres événements fonctionneront lorsque les auditeurs seront ajoutés plus tard au démarrage de l'application.

Je pense que cela devrait probablement être mieux résolu par la bibliothèque react-native-onesignal avec une file d'attente d'abonnés interne. Je vais essayer de tenter le coup, peut-être faire une pull-request dans un proche avenir pour ce scénario avec enregistrement retardé des auditeurs d'événements.

Si vous appelez OneSignal.configure(); avant l'écouteur d'événement, cela fonctionne bien. Je ne suis même pas sûr que ce soit redux-persist.

Juste une note rapide, je viens d'avoir ce problème avec un comportement erratique avec l'événement onIds qui ne se déclenche pas.

Maintenant que j'ai ajouté la fonction de configuration à un autre composant qui se charge un peu plus tard au lancement de l'application, je reçois parfois un seul événement onIds et parfois deux (puisque l'original se déclenche encore à l'occasion).

Il convient de noter que je n'ai pas testé cela sur les versions de version et que je débogue actuellement sur Android, React Native 0.38 et puisque d'autres ont suggéré qu'il s'agissait d'un problème persistant de redux, il convient de noter que je l'utilise également.

S'il n'y a effectivement aucun effet négatif sur l'appel de configure plusieurs fois, je suppose que c'est bien. Je vais juste m'en occuper en frappant mon API deux fois à chaque fois qu'un utilisateur reprend l'application à l'occasion.

S'il y a une sorte de résultat négatif de faire cela (autre que l'inefficacité), veuillez me le faire savoir car ce n'est pas un domaine d'expertise pour moi.

J'ai le même et nous sommes en production. ;) Oui, j'appelle l'API deux fois. :(

Bonjour @edo1493 , j'ai également le même problème. Comment appeler l'API deux fois ?

J'ai remarqué que sans recharger l'application (mode Dev), l'événement ne se déclenchera qu'après 35s

Éditer:
Cela se produit lors du premier chargement de l'application
Plateforme : Android

Peut-être que @jkasten2 pourra vous aider ici, je pense que ce n'est pas un problème avec cette bibliothèque spécifique,

@edo1493 onIds ne se déclenchera pas à moins qu'il ne puisse obtenir un identifiant de joueur / utilisateur du serveur OneSignal. Cela signifie que le userId ne sera jamais null mais le pushToken peut le faire si APNs / FCM ne répond pas à temps. Le problème que je vois semble être lié à la connexion. Pouvez-vous essayer d'appeler setLogLevel en code natif pour activer la journalisation des appels réseau ? Si vous parvenez à reproduire le problème avec Android, il fournira plus de détails sur les appels passés dans le logcat par rapport au journal Xcode avec iOS.

Cependant, la plupart ont noté que le problème semble être lié à redux-persist ce qui signifierait très probablement un problème dans la couche javascript avec le plugin OneSignal. @avishayil Pouvez-vous essayer de reproduire le problème avec redux-persist et essayer d'identifier le problème ? Partagez le projet une fois que vous le faites, je peux également essayer de le déboguer.

@jkasten2 Je

Je n'utilise pas de redux et c'est toujours un problème.

Merci @rcugut ! OneSignal.configure() corrigez-le immédiatement ! J'utilise aussi redux-persist ! Besoin de résoudre ce problème !

L'ajout de .configure l'a également corrigé pour moi, je n'utilise pas react-persist.

Pour moi, OneSignal.configure() hack fonctionne aussi, mais j'ai remarqué que OneSignal.removeEventListener("ids", this.onIds) ne fonctionne pas. Je ne sais pas si c'est lié. Une idée de comment réparer ça?

face à la même chose que @junedomingo

Dans Android, lors du premier chargement de l'application, l'événement ids est appelé après 35 secondes

Je n'ai aucun problème sur Android, l'événement se déclenche sans problème.
Mais j'ai du mal sur iOS, où je n'entre jamais dans la fonction onIds() ...
L'ajout de OneSignal.configure() avant ou après les écouteurs d'événement et avant ou après la fin de la réhydratation (oui, j'utilise redux-persist ) n'a pas aidé.
Quelqu'un a-t-il une idée ?

@jkasten2 j'ai le même problème que @junedomingo mentionné ici sur l'écouteur ids. j'ai mis le journal à l'extérieur et à l'intérieur de cette méthode

     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);
            }
        });

il répond au bout de 30 secondes !
avez vous une idée/solution ?

si vous avez OneSignal.setRequiresUserPrivacyConsent(true);
cela ne fonctionnera pas tant que vous n'aurez pas donné votre consentement !
OneSignal.provideUserConsent(true);

appelez également OneSignal.configure() après avoir ajouté des écouteurs.
L'espoir fonctionne pour vous !!!

Même problème
version : v3.3.1
Plateforme : iOS

Comme vous pouvez le voir ici, userId est null, ce n'est qu'après 29 secondes que l'écouteur d'événement se déclenche avec l'userId. C'est au premier lancement après une installation propre de l'application.
Screen Shot 2019-08-05 at 3 04 59 PM

Quelqu'un a encore ce problème ?
L'événement n'est déclenché qu'après environ 30 secondes dans le démarrage clair sous Android.

@damathryx Salut, je suis confronté au même userId null lors du premier problème de lancement. Avez-vous trouvé un correctif pour cela?

Ce problème devrait être rouvert 😩

Pour moi, les notifications push n'arrivent pas sur Android sans .configure . Les identifiants sont déclenchés correctement maintenant, les informations sur l'appareil sont reçues, mais les notifications elles-mêmes ne fonctionnent pas.

Cette page vous a été utile?
0 / 5 - 0 notes