React-native-onesignal: Comment obtenir une notification initiale ?

Créé le 2 oct. 2017  ·  22Commentaires  ·  Source: OneSignal/react-native-onesignal

Le module React Native PushNotificationIOS a une méthode getInitialNotification() qui permet de récupérer la notification qui a été tapée pour ouvrir l'application (s'il y en avait une). Existe-t-il des fonctionnalités similaires pour cette bibliothèque ?

Lorsque j'ai envoyé une notification de test à mon appareil alors que l'application était fermée, j'ai reçu le journal Device info: dans ma console lors de son ouverture, mais je n'ai vu aucun des autres journaux d'événements pour recevoir une notification.

Édition 3 :
Pour une raison quelconque, je ne peux plus voir l'événement onOpened pour les notifications initiales, bien que rien n'ait changé dans mon code.

Édition 2 :
En déplaçant les auditeurs, j'ai pu voir le journal de l'événement onOpened , mais le fait d'être un auditeur passif signifie que je ne peux pas vérifier activement pour voir au lancement si mon application a été ouverte avec une notification ou non , je dois juste attendre une période de temps arbitraire pour voir si cet événement est déclenché ? N'y a-t-il aucun moyen de vérifier activement si l'application a été ouverte avec une notification push ou non ?

Éditer:
J'ai trouvé un article qui fait référence à l'utilisation OneSignal.configure() et onNotificationOpened , mais en regardant le code source, il ne semble plus que OneSignal.configure() accepte les paramètres ?

Documentation

Commentaire le plus utile

J'ai le même problème, et il semble que beaucoup d'autres ont également ce problème. Certains problèmes connexes / en double que j'ai trouvés incluent https://github.com/geektimecoil/react-native-onesignal/issues/206 , https://github.com/geektimecoil/react-native-onesignal/issues/195 , https://github.com/geektimecoil/react-native-onesignal/issues/191 , https://github.com/geektimecoil/react-native-onesignal/issues/336 , https://github.com/geektimecoil/ réagir-native-onesignal/issues/334 , https://github.com/geektimecoil/react-native-onesignal/issues/264 , https://github.com/geektimecoil/react-native-onesignal/issues/279.

Ces problèmes semblent tous concerner ce problème de l'écouteur d'événement opened qui n'est pas appelé lorsque vous appuyez sur une notification push pour ouvrir l'application et que l'application n'est pas en cours d'exécution à ce moment-là. D'après ce que j'ai lu dans ces problèmes et les tests que j'ai effectués, il semble que la cause de ce problème soit l'enregistrement de l'écouteur d'événement retardé de quelque manière que ce soit (c'est-à-dire OneSignal.addEventListener('opened', this.onOpened); est appelé légèrement après le l'application elle-même est chargée). Cela peut être dû au fait que vous avez ce code dans un composant React (par exemple, dans les fonctions constructor ou componentWillMount ou componentDidMount ), ou parce qu'il n'est appelé qu'après avoir configuré/réhydraté votre magasin Redux, etc. Et en raison de ce retard, l'événement lui-même (qu'une notification a été ouverte) est déclenché par react-native-onesignal avant que l'écouteur d'événement ne soit enregistré, et à ce stade, vous avez manqué l'événement et avez aucun moyen de savoir que c'est arrivé. En remarque, ce même problème affecte d'autres écouteurs d'événements, par exemple l'écouteur d'événements ids .

Si vous déplacez ce code pour qu'il se produise le plus tôt possible, il semble que l'écouteur d'événement sera enregistré avant que l'événement ne soit déclenché et, par conséquent, votre fonction de gestionnaire d'événements sera appelée. Par exemple, vous devez déplacer le code d'enregistrement de l'écouteur d'événement dans votre fichier index.ios.js , ou au début de votre fichier App.js dans le cas où votre fichier index.ios.js est simplement en train d'importer le composant App et l'enregistrer (via AppRegistry.registerComponent ).

Une fois que vous avez configuré cette configuration, vous pouvez désormais capturer l'événement d'ouverture d'une notification et la manière dont vous la gérez dépend de la configuration de votre application (par exemple, si vous utilisez Redux, ou si vous utilisez redux-persist, etc.).

Ma solution actuelle consiste à enregistrer la notification dans une variable définie au niveau supérieur de mon fichier App.js lui-même (avant même de déclarer mon composant App ), puis une fois l'initialisation de mon magasin Redux (qui inclut l'attente de la réhydratation de mon magasin par redux-persist), j'envoie des actions avec la notification en tant que charge utile (s'il y avait une notification ouverte), puis je supprime également mes écouteurs d'événement de niveau supérieur et ajoute un nouvel événement écouteurs sur mon composant App lui-même (ces écouteurs d'événements envoient également simplement des actions à mon magasin Redux avec la notification, les ID de périphérique, etc. comme charge utile d'action).

Cette solution est évidemment très hacky, et il y a probablement des cas extrêmes où cela ne fonctionnerait pas comme prévu. Mais jusqu'à ce qu'une solution appropriée soit implémentée dans react-native-onesignal, cela semble être une solution de contournement décente.

Je pense que ce qui doit arriver, c'est que react-native-onesignal soit mis à jour afin qu'il attende que vous ayez configuré vos gestionnaires d'événements avant de déclencher les événements. Une solution possible pourrait être que lorsque des événements se produisent (comme l'événement opened ), les événements sont placés dans une file d'attente, et react-native-onesignal vérifie alors s'il existe un écouteur d'événement correspondant actuellement enregistré. S'il n'y en a pas, il laisse l'événement dans la file d'attente. Ensuite, dès que l'écouteur d'événements est enregistré, les événements qui seraient reçus par cet écouteur d'événements sont déclenchés et supprimés de la file d'attente. De cette façon, vous pouvez ajouter les écouteurs d'événements dans l'application à tout moment (par exemple, après avoir attendu que votre magasin Redux soit configuré et réhydraté, ce qui pourrait potentiellement prendre 1 à 2 secondes après le chargement de l'application elle-même), puis dès que les écouteurs d'événements sont enregistrés, vos fonctions de gestionnaire d'événements seraient appelées et recevraient les événements qui se sont produits (comme l'événement qu'une notification a été ouverte).

Une autre solution possible, au moins pour détecter spécifiquement que l'application a été ouverte parce que l'utilisateur a appuyé sur une notification push, serait de faire quelque chose de similaire à getInitialNotification() partir de PushNotificationIOS comme vous l'avez suggéré, où vous pouvez appelez cette fonction à tout moment et elle renverra la notification push que l'utilisateur a appuyée pour ouvrir l'application (ou null si cela ne s'est pas produit). Mais même si cela était implémenté dans react-native-onesignal, cela ne résoudrait en rien ce problème qui affecte les autres écouteurs d'événements (par exemple, l'écouteur d'événements ids ).

Je pense donc qu'il doit vraiment y avoir une solution qui résout ce problème central des événements déclenchés avant l'enregistrement de tout écouteur d'événement correspondant, ce qui fait que l'événement est manqué par l'application.

Tous les 22 commentaires

J'ai le même problème, et il semble que beaucoup d'autres ont également ce problème. Certains problèmes connexes / en double que j'ai trouvés incluent https://github.com/geektimecoil/react-native-onesignal/issues/206 , https://github.com/geektimecoil/react-native-onesignal/issues/195 , https://github.com/geektimecoil/react-native-onesignal/issues/191 , https://github.com/geektimecoil/react-native-onesignal/issues/336 , https://github.com/geektimecoil/ réagir-native-onesignal/issues/334 , https://github.com/geektimecoil/react-native-onesignal/issues/264 , https://github.com/geektimecoil/react-native-onesignal/issues/279.

Ces problèmes semblent tous concerner ce problème de l'écouteur d'événement opened qui n'est pas appelé lorsque vous appuyez sur une notification push pour ouvrir l'application et que l'application n'est pas en cours d'exécution à ce moment-là. D'après ce que j'ai lu dans ces problèmes et les tests que j'ai effectués, il semble que la cause de ce problème soit l'enregistrement de l'écouteur d'événement retardé de quelque manière que ce soit (c'est-à-dire OneSignal.addEventListener('opened', this.onOpened); est appelé légèrement après le l'application elle-même est chargée). Cela peut être dû au fait que vous avez ce code dans un composant React (par exemple, dans les fonctions constructor ou componentWillMount ou componentDidMount ), ou parce qu'il n'est appelé qu'après avoir configuré/réhydraté votre magasin Redux, etc. Et en raison de ce retard, l'événement lui-même (qu'une notification a été ouverte) est déclenché par react-native-onesignal avant que l'écouteur d'événement ne soit enregistré, et à ce stade, vous avez manqué l'événement et avez aucun moyen de savoir que c'est arrivé. En remarque, ce même problème affecte d'autres écouteurs d'événements, par exemple l'écouteur d'événements ids .

Si vous déplacez ce code pour qu'il se produise le plus tôt possible, il semble que l'écouteur d'événement sera enregistré avant que l'événement ne soit déclenché et, par conséquent, votre fonction de gestionnaire d'événements sera appelée. Par exemple, vous devez déplacer le code d'enregistrement de l'écouteur d'événement dans votre fichier index.ios.js , ou au début de votre fichier App.js dans le cas où votre fichier index.ios.js est simplement en train d'importer le composant App et l'enregistrer (via AppRegistry.registerComponent ).

Une fois que vous avez configuré cette configuration, vous pouvez désormais capturer l'événement d'ouverture d'une notification et la manière dont vous la gérez dépend de la configuration de votre application (par exemple, si vous utilisez Redux, ou si vous utilisez redux-persist, etc.).

Ma solution actuelle consiste à enregistrer la notification dans une variable définie au niveau supérieur de mon fichier App.js lui-même (avant même de déclarer mon composant App ), puis une fois l'initialisation de mon magasin Redux (qui inclut l'attente de la réhydratation de mon magasin par redux-persist), j'envoie des actions avec la notification en tant que charge utile (s'il y avait une notification ouverte), puis je supprime également mes écouteurs d'événement de niveau supérieur et ajoute un nouvel événement écouteurs sur mon composant App lui-même (ces écouteurs d'événements envoient également simplement des actions à mon magasin Redux avec la notification, les ID de périphérique, etc. comme charge utile d'action).

Cette solution est évidemment très hacky, et il y a probablement des cas extrêmes où cela ne fonctionnerait pas comme prévu. Mais jusqu'à ce qu'une solution appropriée soit implémentée dans react-native-onesignal, cela semble être une solution de contournement décente.

Je pense que ce qui doit arriver, c'est que react-native-onesignal soit mis à jour afin qu'il attende que vous ayez configuré vos gestionnaires d'événements avant de déclencher les événements. Une solution possible pourrait être que lorsque des événements se produisent (comme l'événement opened ), les événements sont placés dans une file d'attente, et react-native-onesignal vérifie alors s'il existe un écouteur d'événement correspondant actuellement enregistré. S'il n'y en a pas, il laisse l'événement dans la file d'attente. Ensuite, dès que l'écouteur d'événements est enregistré, les événements qui seraient reçus par cet écouteur d'événements sont déclenchés et supprimés de la file d'attente. De cette façon, vous pouvez ajouter les écouteurs d'événements dans l'application à tout moment (par exemple, après avoir attendu que votre magasin Redux soit configuré et réhydraté, ce qui pourrait potentiellement prendre 1 à 2 secondes après le chargement de l'application elle-même), puis dès que les écouteurs d'événements sont enregistrés, vos fonctions de gestionnaire d'événements seraient appelées et recevraient les événements qui se sont produits (comme l'événement qu'une notification a été ouverte).

Une autre solution possible, au moins pour détecter spécifiquement que l'application a été ouverte parce que l'utilisateur a appuyé sur une notification push, serait de faire quelque chose de similaire à getInitialNotification() partir de PushNotificationIOS comme vous l'avez suggéré, où vous pouvez appelez cette fonction à tout moment et elle renverra la notification push que l'utilisateur a appuyée pour ouvrir l'application (ou null si cela ne s'est pas produit). Mais même si cela était implémenté dans react-native-onesignal, cela ne résoudrait en rien ce problème qui affecte les autres écouteurs d'événements (par exemple, l'écouteur d'événements ids ).

Je pense donc qu'il doit vraiment y avoir une solution qui résout ce problème central des événements déclenchés avant l'enregistrement de tout écouteur d'événement correspondant, ce qui fait que l'événement est manqué par l'application.

Salut @jordanmkoncz , pouvez-vous partager le code du fichier auquel vous avez envoyé les actions ? J'ai la même configuration réactive que vous (redux-persist etc..)

@ccoeder bien sûr, voici mon fichier App.js actuel.

import React, { Component } from 'react';
import { Provider } from 'react-redux';
import OneSignal from 'react-native-onesignal';
import isNil from 'lodash/isNil';
import configureStore from '../redux/configureStore';
import {
  pushNotificationIdsReceived,
  pushNotificationOpened,
  pushNotificationReceived,
  pushNotificationRegistered,
} from '../redux/actionCreators';
import AppNavigator from './AppNavigator';
import Blank from './Blank';

let openedPushNotificationResult = null;
let receivedPushNotification = null;
let receivedNotificationUserInfo = null;
let receivedIds = null;

const onOpened = openResult => {
  openedPushNotificationResult = openResult;
};

const onReceived = notification => {
  receivedPushNotification = notification;
};

const onRegistered = notificationUserInfo => {
  receivedNotificationUserInfo = notificationUserInfo;
};

const onIds = ids => {
  receivedIds = ids;
};

OneSignal.addEventListener('opened', onOpened);
OneSignal.addEventListener('received', onReceived);
OneSignal.addEventListener('registered', onRegistered);
OneSignal.addEventListener('ids', onIds);

class App extends Component {
  constructor() {
    super();

    this.state = {
      isStoreInitialised: false,
    };

    this.store = null;

    this.onOpened = this.onOpened.bind(this);
    this.onReceived = this.onReceived.bind(this);
    this.onRegistered = this.onRegistered.bind(this);
    this.onIds = this.onIds.bind(this);
  }

  componentDidMount() {
    this.store = configureStore(store => {
      if (!isNil(openedPushNotificationResult)) {
        store.dispatch(pushNotificationOpened(openedPushNotificationResult));
      }

      if (!isNil(receivedPushNotification)) {
        store.dispatch(pushNotificationReceived(receivedPushNotification));
      }

      if (!isNil(receivedNotificationUserInfo)) {
        store.dispatch(pushNotificationRegistered(receivedNotificationUserInfo));
      }

      if (!isNil(receivedIds)) {
        store.dispatch(pushNotificationIdsReceived(receivedIds));
      }

      OneSignal.addEventListener('opened', this.onOpened);
      OneSignal.addEventListener('received', this.onReceived);
      OneSignal.addEventListener('registered', this.onRegistered);
      OneSignal.addEventListener('ids', this.onIds);

      OneSignal.removeEventListener('opened', onOpened);
      OneSignal.removeEventListener('received', onReceived);
      OneSignal.removeEventListener('registered', onRegistered);
      OneSignal.removeEventListener('ids', onIds);

      this.setState({ isStoreInitialised: true });
    });
  }

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

  onOpened(openResult) {
    this.store.dispatch(pushNotificationOpened(openResult));
  }

  onReceived(notification) {
    this.store.dispatch(pushNotificationReceived(notification));
  }

  onRegistered(notificationUserInfo) {
    this.store.dispatch(pushNotificationRegistered(notificationUserInfo));
  }

  onIds(ids) {
    this.store.dispatch(pushNotificationIdsReceived(ids));
  }

  render() {
    if (!this.state.isStoreInitialised) {
      return <Blank />;
    }

    return (
      <Provider store={this.store}>
        <AppNavigator />
      </Provider>
    );
  }
}

export default App;

Remarque : configureStore est une fonction qui crée mon magasin Redux (c'est-à-dire qu'elle appelle createStore() ), puis configure redux-persist (c'est-à-dire qu'elle appelle persistStore() ). configureStore prend une fonction de rappel comme paramètre, et dans le rappel onComplete de la fonction persistStore j'appelle la fonction de rappel passée à configureStore et passe le magasin objet en tant que paramètre de ce rappel. Enfin, configureStore renvoie l'objet store.

Donc, fondamentalement, j'attends que mon magasin ait été configuré et réhydraté, puis j'envoie des actions en fonction des événements reçus par mes écouteurs d'événements initiaux, puis j'ajoute les nouveaux écouteurs d'événements et supprime les écouteurs d'événements initiaux.

@jordanmkoncz Merci d'avoir partagé votre code. Au début, je pensais avoir la même erreur que vous, mais j'ai réalisé que mon problème était lié à la notification silencieuse. Je dois agir si la notification arrive alors que l'application est fermée. Je suppose que vos codes ne fonctionnent pas pour moi.

Pas de soucis @ccoeder. Oui, le problème d'agir sur une notification alors que l'application est fermée est différent. Ce problème est spécifiquement lié à la détection dans l'application que l'utilisateur a appuyé sur une notification pour ouvrir l'application, au moment où l'application est lancée (alors qu'elle ne fonctionnait pas du tout auparavant).

Regardez comment réagit-native-fcm, il existe une méthode appelée getInitialNotification

@jordanmkoncz Merci pour votre publication.

J'ai eu le même problème. lorsque l'application a reçu la notification push, l'écran navigue vers l'écran souhaité.
mais lorsque vous ouvrez la notification, cela ne fonctionne pas pour la fonction push de navigation.
Exemple:
composantWillMount() {
OneSignal.addEventListener('reçu', this._onReceived);
OneSignal.addEventListener('ouvert', this._onOpened);
}
componentWillUnmount() {
OneSignal.removeEventListener('reçu', this.__onReceived);
OneSignal.removeEventListener('opened', this._onOpened);
}
_onRecevied(notification) {
console.log('Notification reçue : ', notification); // fonctionne bien
this.props.navigator.push({ pushSreen, passProps : { params } }); // fonctionne bien
}
_onOpened(openResult) {
console.log('Corps de notification : ', openResult.notification.payload.body); // fonctionne bien
this.props.navigator.push({ pushSreen, passProps : { params } }); // Ca ne fonctionne pas
}

Que pensez-vous de ceci? Si vous pouvez m'aider, j'espère répondre ici. Merci

Hmm .. J'ai mon composant PushNotificationHelper en tant qu'enfant de mon Redux Provider , qui n'est rendu qu'après que le store a été réhydraté.

componentWillMount() {
    AppState.addEventListener("change", this.handleAppStateChange);
    OneSignal.configure({
      onNotificationOpened: this.handleOpenNotification
    });
    OneSignal.addEventListener("received", this.onReceived);
    OneSignal.addEventListener("opened", this.onOpened);
    OneSignal.addEventListener("registered", this.onRegistered);
    OneSignal.addEventListener("ids", this.onIds);

    if (!IOS) {
      OneSignal.inFocusDisplaying(0);
    }
  }

  componentWillUnmount() {
    AppState.removeEventListener("change", this.handleAppStateChange);
    OneSignal.removeEventListener("received", this.onReceived);
    OneSignal.removeEventListener("opened", this.onOpened);
    OneSignal.removeEventListener("registered", this.onRegistered);
    OneSignal.removeEventListener("ids", this.onIds);
  }

handleOpenNotification = (message, data, isActive) => {
    console.log("Notification", message, data, isActive);

    if (isActive) {
      // touchable banner displaying info from push notification
    } else {
      // act on data received from push notification
    }
  };

onReceived = notification => {
    console.log("Notification received: ", notification);
  };

onOpened = openResult => {
    console.log("Message: ", openResult.notification.payload.body);
    console.log("Data: ", openResult.notification.payload.additionalData);
    console.log("isActive: ", openResult.notification.isAppInFocus);
    console.log("openResult: ", openResult);
  };

Même si mon application est fermée - pas dans un AppState background , mais complètement fermée - si j'appuie sur une notification push, la méthode onOpened est appelée avec le openResult objet et les données associées, et je suis libre de dispatch redux actions de manière appropriée.

@wkoutre c'est intéressant, pourriez-vous publier les versions de react-native , react-native-onesignal etc. que vous utilisez actuellement ? Avez-vous testé cela sur iOS et Android? Avez-vous effectué des tests approfondis pour ouvrir l'application en appuyant sur une notification push, l'application étant complètement fermée au moment où la notification push a été activée, et avez-vous constaté que votre méthode onOpened est appelée 100 % du temps ?

Pourriez-vous faire des tests pour voir si cela fonctionne toujours 100 % du temps si vous retardez artificiellement le chargement de votre PushNotificationHelper encore plus loin, par exemple en ayant un setTimeout avec un délai de quelque chose comme 5 secondes, après quoi vous changer quelque chose dans l'état pour autoriser le montage de PushNotificationHelper et enregistrer ses écouteurs d'événements avec OneSignal ?

@jordanmkoncz

"react-native": "0.50.4"
"react-native-onesignal": "^3.0.7"

J'ai testé sur iOS et Android, oui. Sur les deux, 100 % du temps :

  • l'application est complètement fermée
  • la notification push est reçue
  • la notification push est exploitée
  • charges d'application
  • onOpened est appelé avec les données de la notification push, et openResult.notification.isAppInFocus === false

Je ferai les setTimeout et je vous recontacterai.


EDIT1 : Je n'ai absolument rien changé, et maintenant cela échoue 100 % du temps sur Android.


EDIT2 : Faire le retard setTimeout a empêché onOpened de se déclencher lors du chargement de l'application en appuyant sur une notification push. Cependant, j'ai tout déplacé dans les méthodes de cycle de vie de App.js -- mon composant racine étant enregistré dans index.ios.js et index.android.js -- et onOpened est appelé 100% du temps iOS, et ~50% du temps sur Android.

Je ne sais pas pourquoi Android est incohérent, mais c'est évidemment un problème. Sur Android, lorsque l'application est complètement fermée et qu'une notification arrive, le débogueur s'efface et tout dans mon App.js se charge jusqu'à ce que je crée la classe elle-même.

const IOSX = HEIGHT === 812 && PLATFORM === "ios";

const wrapperStyle = [Styles.flex1];
if (IOSX) wrapperStyle.push(Styles.backgroundDarkGray);

let SPLASH_TIME;

console.log(`Change to TRUE below to reset store state`);

const PURGE = DEV ? false : false;

if (DEV) SPLASH_TIME = 4000;
else SPLASH_TIME = 4000;

// const composeEnhancers = composeWithDevTools({
//   realtime: true,
//   port: 8000
// });

const composeEnhancers =
  typeof window === "object" &&
  window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ &&
  DEV
    ? window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__({
        // Specify extension’s options like name, actionsBlacklist, actionsCreators, serialize...
      })
    : compose;

const middlewares = [ReduxThunk];

// debugging tooling
// if (DEV) {
//   // add logger
// middlewares.push(logger)

//   // middlewares = [...middlewares, logger];
//   middlewares = [...middlewares];

// replace these transient reducers when they've been created

export const store = createStore(
  Reducers,
  {},
  composeEnhancers(
    applyAppStateListener(),
    applyMiddleware(...middlewares),
    autoRehydrate()
  )
);

// if (module.hot) {
//   // Enable hot module replacement for reducers
//   module.hot.accept(() => {
//     const nextRootReducer = require("./reducers/index").default;
//     store.replaceReducer(nextRootReducer);
//   });
// }

console.log(`right before APP`);

// Debugger logs everything before this line.

export default class App extends Component {
    ...
}

@jordanmkoncz Curieux de savoir si vous avez essayé cette bibliothèque : https://github.com/wix/react-native-notifications

Très bien, j'ai une solution de contournement qui fonctionne 100% du temps sur iOS et Android.

Dans mon App.js mais avant de déclarer mon composant App, j'ai :

const handleOnOpened = openResult => {
  store.dispatch(setInitialNotification(openResult));
};

OneSignal.configure({});
OneSignal.addEventListener("opened", handleOnOpened);

... où setInitialNotification est un créateur d'action.

Ensuite, lorsque mon application (maintenant montée) a fini de se réhydrater, j'appelle :

this.setState({ rehydrated: true }, () => {
          OneSignal.removeEventListener("opened", handleOnOpened);
        });

Mon application - enveloppée d'un redux Provider - est ensuite renvoyée dans la méthode render , ressemblant à quelque chose comme...

<Provider store={store}>
        <IphoneXAwareView style={wrapperStyle}>
          <StatusBar hidden={false} barStyle="light-content" />
          <MyAlert />
          <Loading />
          <ConnectedAppWithNavigationState />
          <PushNotificationHelper />
        </IphoneXAwareView>
      </Provider>

À partir de là, le composant PushNotificationHelper gère l'écoute et la gestion de toutes les notifications push.

@bhoop Cela fait quelques mois, donc je ne sais pas si vous cherchez toujours un correctif mais ... si c'est le cas, essayez-le.

@wkoutre Pourriez-vous configurer un PR avec des mises à jour du fichier Lisez-moi qui inclut cette solution de contournement pour redux ?

@avishayil Bien sûr. je m'y attèle ce soir

avishayil PR fait.

Je suis confronté à un problème qui ressemble à ceci. Lorsque l'application est ouverte, elle fonctionne correctement avec tous les rappels, même lorsque l'application est en arrière-plan. Mais, si je reçois un push, l'icône de mon application augmente de +1 et le système affiche sa bannière avec le contenu de la notification MAIS si j'ignore la bannière et ouvre l'application par l'icône (et non par la bannière de notification), le rappel est ignoré =[ comment gérer ça ?

  • application de détachement expo
  • réagir 16.3.1
  • un signal 3.2.5
  • expo 27.0.1

@brunoandradebr c'est le comportement attendu. L'ouverture de l'application à partir de l'icône de l'application ne prend jamais en compte les notifications que vous avez pu recevoir. Il ouvre simplement l'application.

Si vous souhaitez modifier le comportement de votre application au démarrage en fonction de la réception ou non d'une notification par l'utilisateur, vous devrez vérifier cela vous-même au lancement.

Ce n'est pas vrai. Lorsque j'ouvre l'application par icône lorsque l'application s'exécute en arrière-plan, elle gère la notification push comme vous le souhaitez. Ce n'est que lorsque je le supprime de la mémoire (swipe), puis que j'ouvre par icône, rien ne se passe. J'étais en train d'enquêter et je pense que c'est XCode qui arrête l'application et ferme le lien Onesignal lib.

@brunoandradebr Je comprends peut-être mal le problème que vous rencontrez et à quel(s) rappel(s) faites-vous référence.
Si l'application s'exécute en arrière-plan, elle est capable de gérer les événements received . Mais si l'application est tuée, elle ne peut écouter aucun événement. La seule façon dont une notification peut interagir avec une application (au moins pour iOS) est d'interagir avec la notification de quelque manière que ce soit.

Lorsque je tue l'application et que j'ai une notification, si j'ouvre l'application par icône, l'application ne peut pas gérer les événements de rappel, MAIS si l'application s'exécute en arrière-plan et que j'ouvre par icône, les rappels se déclenchent comme prévu. J'ai compris ?

@brunoandradebr Je pense que j'ai compris, et si je ne me trompe pas, c'est le comportement que j'ai décrit dans mon commentaire précédent. Dans tous les cas, je pense que c'est hors sujet et si vous pensez avoir un problème avec cela, vous devriez ouvrir un problème séparé sur le repo.

@jordanmkoncz Vous semblez avoir une très bonne compréhension des problèmes de réaction native onesignal. Les versions que j'utilise react-native-onesignal : ^ 3.2.8 et react-native : 0.56.0. J'ai pu implémenter la gestion des notifications en arrière-plan et au premier plan, mais je rencontre un problème maintenant lorsque l'application est fermée et qu'une notification est activée. L'application affiche uniquement un écran blanc vierge qui ne disparaît que si vous la fermez et la redémarrez. Je ne sais pas comment gérer cette situation car je ne trouve aucune documentation sur le site Web de OneSignal. C'est frustrant parce que j'ai passé du temps à apprendre et à implémenter cette bibliothèque et maintenant je ne sais pas si elle sera capable de gérer ce cas d'utilisation extrêmement important. J'ai lu une solution de contournement possible pour cela ci-dessus qui implémente les écouteurs d'événements dans index.js mais j'utilise la navigation réactive et j'ai besoin d'obtenir une référence de mon navigateur principal qui est déclaré dans App.js afin de naviguer vers un écran de pile imbriqué. J'apprécierais vraiment tout conseil que l'on a pour faire face à ce problème et comment ils l'ont résolu. Merci d'avance.

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