React-native-onesignal: Como obter a notificação inicial?

Eu tenho o mesmo problema, e parece que muitos outros também estão tendo esse problema. Alguns problemas relacionados/duplicados que encontrei incluem 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/ react-native-onesignal/issues/334 , https://github.com/geektimecoil/react-native-onesignal/issues/264 , https://github.com/geektimecoil/react-native-onesignal/issues/279.

Todos esses problemas parecem ser sobre o problema do ouvinte de eventos opened não ser chamado quando você toca em uma notificação por push para abrir o aplicativo e o aplicativo não está em execução no momento. Pelo que li nesses problemas e pelos testes que fiz, parece que a causa desse problema é o registro do ouvinte de eventos atrasado de alguma forma (ou seja OneSignal.addEventListener('opened', this.onOpened); é chamado um pouco após o app em si é carregado). Isso pode ser porque você tem esse código dentro de um componente React (por exemplo, nas funções constructor ou componentWillMount ou componentDidMount ), ou porque ele não é chamado até depois de configurar/rehidratar sua loja Redux, etc. E devido a esse atraso, o próprio evento (que uma notificação foi aberta) é disparado por react-native-onesignal antes que o ouvinte do evento seja registrado, e neste ponto você perdeu o evento e tem não há como saber que isso aconteceu. Como observação lateral, esse mesmo problema afeta outros ouvintes de eventos, por exemplo, o ouvinte de eventos ids .

Se você mover este código para que aconteça o mais cedo possível, parece que o ouvinte de eventos será registrado antes que o evento seja acionado e, como tal, sua função de manipulador de eventos será chamada. Por exemplo, você deve mover o código de registro do ouvinte de eventos para o seu arquivo index.ios.js , ou no início do seu arquivo App.js no caso de seu arquivo index.ios.js ser simplesmente importado o componente App e registrá-lo (via AppRegistry.registerComponent ).

Depois de configurar isso, agora você pode capturar o evento em que uma notificação foi aberta e cabe a você como lidar com isso, o que dependerá de como seu aplicativo está configurado (por exemplo, se você está usando Redux, ou se você está usando redux-persist, etc.).

Minha solução atual é salvar a notificação em uma variável definida no nível superior do meu próprio arquivo App.js (antes mesmo de declarar meu componente App ) e, depois de concluir a inicialização do minha loja Redux (que inclui aguardar a reidratação da minha loja por redux-persist), despacho ações com a notificação como uma carga útil (se houver uma notificação aberta) e também removo meus ouvintes de eventos de nível superior e adiciono novo evento listeners no meu próprio componente App (esses event listeners também simplesmente despacham ações para minha loja Redux com a notificação, IDs de dispositivo etc. como a carga útil da ação).

Esta solução é obviamente muito hacky, e provavelmente existem alguns casos extremos em que isso não funcionaria como deveria. Mas até que uma solução adequada seja implementada em react-native-onesignal, isso parece ser uma solução decente.

Eu acho que o que precisa acontecer é que react-native-onesignal seja atualizado para que ele espere até que você configure seus manipuladores de eventos antes de disparar os eventos. Uma solução possível poderia ser que, quando ocorrem eventos (como o evento opened ), os eventos são colocados em uma fila e react-native-onesignal verifica se há um ouvinte de evento correspondente registrado no momento. Se não houver, ele deixa o evento na fila. Então, assim que o ouvinte de eventos é registrado, os eventos que seriam recebidos por este ouvinte de eventos são acionados e removidos da fila. Dessa forma, você pode adicionar os ouvintes de eventos no aplicativo a qualquer momento (por exemplo, depois de esperar que seu armazenamento Redux seja configurado e reidratado, o que pode levar de 1 a 2 segundos após o carregamento do próprio aplicativo) e, assim que os ouvintes de eventos são registrados, suas funções de manipulador de eventos seriam chamadas e receberiam os eventos ocorridos (como o evento em que uma notificação foi aberta).

Outra solução possível, pelo menos para detectar especificamente que o aplicativo foi aberto porque o usuário tocou em uma notificação push, seria fazer algo semelhante a getInitialNotification() de PushNotificationIOS como você sugeriu, onde você pode chame essa função a qualquer momento e ela retornará a notificação push que o usuário tocou para abrir o aplicativo (ou null se isso não ocorreu). Mas mesmo se isso fosse implementado em react-native-onesignal, não faria nada para resolver esse problema que afeta os outros ouvintes de eventos (por exemplo, o ouvinte de eventos ids ).

Então, acho que realmente precisa haver uma solução que resolva esse problema central de eventos sendo acionados antes que qualquer ouvinte de evento correspondente seja registrado, fazendo com que o evento seja perdido pelo aplicativo.

Oi @jordanmkoncz , você pode compartilhar o código do arquivo para o qual você despachou as ações? Eu tenho a mesma configuração react-native que você (redux-persist etc.)

@ccoeder claro, aqui está meu arquivo App.js atual.

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;

Nota: configureStore é uma função que cria minha loja Redux (ou seja, chama createStore() ), então configura redux-persist (ou seja, chama persistStore() ). configureStore pega uma função callback como parâmetro, e no callback onComplete da função persistStore eu chamo a função callback passada para configureStore e passo a loja objeto como um parâmetro para este retorno de chamada. Finalmente, configureStore retorna o objeto store.

Então, basicamente, espero até que minha loja seja configurada e reidratada e, em seguida, despacho ações com base nos eventos recebidos pelos meus ouvintes de eventos iniciais, adiciono os novos ouvintes de eventos e removo os ouvintes de eventos iniciais.

@jordanmkoncz Obrigado por compartilhar seu código. A princípio pensei que tinha o mesmo erro que você, mas percebi que meu problema está relacionado à notificação silenciosa. Preciso agir se a notificação chegar enquanto o aplicativo estiver fechado. Acho que seus códigos não funcionam para mim.

Não se preocupe @ccoeder. Sim, a questão de realmente agir em uma notificação enquanto o aplicativo está fechado é diferente. Esse problema está relacionado especificamente à detecção no aplicativo de que o usuário tocou em uma notificação para abrir o aplicativo no momento em que o aplicativo é iniciado (quando não estava em execução anteriormente).

Dê uma olhada como react-native-fcm faz, existe um método chamado getInitialNotification

@jordanmkoncz Obrigado por sua postagem.

Eu tive o problema semelhante. quando o aplicativo recebeu a notificação por push, a tela navega para a tela desejada.
mas ao abrir a notificação, não está funcionando para a função push de navegação.
exemplo:
componentWillMount() {
OneSignal.addEventListener('recebido', this._onReceived);
OneSignal.addEventListener('opened', this._onOpened);
}
componentWillUnmount() {
OneSignal.removeEventListener('recebido', this.__onRecebido);
OneSignal.removeEventListener('opened', this._onOpened);
}
_onReceved(notificação) {
console.log('Notificação recebida: ', notificação); // trabalhando bem
this.props.navigator.push({ pushSreen, passProps : { params } }); // trabalhando bem
}
_onOpened(openResult) {
console.log('Corpo da notificação: ', openResult.notification.payload.body); // trabalhando bem
this.props.navigator.push({ pushSreen, passProps : { params } }); // não está funcionando
}

O que você pensa sobre isso? Se você puder me ajudar, espero por favor responder aqui. Obrigado

Hmm.. Eu tenho meu componente PushNotificationHelper como um filho do meu Redux Provider , que é renderizado somente após o store ter sido reidratado.

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

Mesmo se meu aplicativo estiver fechado -- não em um AppState background , mas completamente fechado -- se eu tocar em uma notificação por push, o método onOpened é chamado com o openResult objeto e dados associados, e estou livre para dispatch ações redux apropriadamente.

@wkoutre que interessante, você poderia postar quais versões de react-native , react-native-onesignal etc. você está usando atualmente? Você testou isso no iOS e no Android? Você fez testes extensivos para abrir o aplicativo tocando em uma notificação por push, com o aplicativo sendo completamente fechado no momento em que a notificação por push foi tocada e descobriu que seu método onOpened é chamado 100% do tempo?

Você poderia fazer alguns testes para ver se ainda funciona 100% do tempo se você atrasar artificialmente o carregamento de seu PushNotificationHelper ainda mais, por exemplo, tendo um setTimeout com um atraso de algo como 5 segundos, após o qual você alterar algo no estado para permitir que PushNotificationHelper seja montado e registre seus ouvintes de eventos com o OneSignal?

@jordanmkoncz

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

Já testei em iOS e Android, sim. Em ambos, 100% do tempo:

• o aplicativo está completamente fechado
• notificação push é recebida
• notificação push é tocada
• carregamentos de aplicativos
• onOpened é chamado com dados da notificação push e openResult.notification.isAppInFocus === false

Eu vou fazer o setTimeout e te retorno.

EDIT1: não mudei absolutamente nada e agora falha no Android 100% do tempo.

EDIT2: Fazer o atraso setTimeout fez com que onOpened não fosse acionado no carregamento do aplicativo ao tocar em uma notificação por push. No entanto, mudei tudo para os métodos de ciclo de vida de App.js -- meu componente raiz sendo registrado em index.ios.js e index.android.js -- e onOpened é chamado de 100% do tempo iOS e ~50% do tempo no Android.

Não sei por que o Android é inconsistente, mas obviamente é um problema. No Android, quando o aplicativo está completamente fechado e uma notificação chega, o depurador limpa e tudo no meu App.js é carregado até eu criar a própria classe.

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 Curioso se você já experimentou esta biblioteca: https://github.com/wix/react-native-notifications

Tudo bem, eu tenho uma solução alternativa que funciona 100% do tempo no iOS e no Android.

No meu App.js mas antes de declarar meu componente App, tenho:

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

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

... onde setInitialNotification é um criador de ação.

Então, quando meu aplicativo (agora montado) termina de reidratar, eu chamo:

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

Meu aplicativo -- envolto com um redux Provider -- é então retornado no método render , parecendo algo como ...

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

A partir daí, o componente PushNotificationHelper lida com a escuta e o tratamento de todas as notificações push.

@bhoop Já faz alguns meses, então não tenho certeza se você ainda está procurando uma correção, mas... se sim, experimente.

@wkoutre Você poderia configurar um PR com atualizações para o arquivo Leiame que inclui esta solução alternativa para redux?

@avishayil Com certeza. Eu vou chegar até esta noite

avishayil PR feito.

Estou enfrentando um problema que soa assim. Quando o aplicativo é aberto, ele está executando todos os retornos de chamada, quando o aplicativo também está em segundo plano. Mas, se eu receber um push, meu ícone do aplicativo incrementa +1, e o sistema mostra seu banner com conteúdo de notificação MAS se eu ignorar o banner e abrir o aplicativo pelo ícone (não pelo banner de notificação) o retorno de chamada é ignorado =[ como lidar com isso?

• aplicativo de desapego expo
• reagir 16.3.1
• um sinal 3.2.5
• exposição 27.0.1

@brunoandradebr esse é o comportamento esperado. Abrir o aplicativo a partir do ícone do aplicativo nunca leva em consideração nenhuma notificação que você possa ter recebido. Ele apenas abre o aplicativo.

Se você quiser alterar o comportamento do seu aplicativo quando ele for iniciado com base no fato de o usuário ter recebido uma notificação, você precisará verificar isso na inicialização.

Não é verdade. Quando abro o aplicativo por ícone quando o aplicativo está sendo executado em segundo plano, ele lida com a notificação por push conforme desejado. Só quando eu removo da memória (swipe), depois abro pelo ícone, nada acontece. Eu estava investigando e acho que é o XCode para o aplicativo e fecha o link da lib do oonesignal.

@brunoandradebr Posso estar entendendo mal o problema que você está tendo e a quais retornos de chamada você está se referindo.
Se o aplicativo for executado em segundo plano, ele será capaz de lidar com eventos received . Mas se o aplicativo for encerrado, ele não poderá ouvir nenhum evento. A única maneira de uma notificação interagir com um aplicativo (pelo menos para iOS) é interagindo com a notificação de qualquer maneira.

Quando eu encerro o aplicativo e tenho uma notificação, se eu abrir o aplicativo por ícone, o aplicativo não pode lidar com eventos de retorno de chamada, MAS se o aplicativo estiver sendo executado em segundo plano e eu abrir por ícone, os retornos de chamada serão acionados conforme o esperado. Entendi ?

@brunoandradebr acho que entendi, e se não estiver errado esse é o comportamento que descrevi no meu comentário anterior. De qualquer forma, acho que isso está fora do tópico e, se você acha que tem um problema com isso, deve abrir um problema separado no repositório.

@jordanmkoncz Você parece ter uma boa compreensão dos problemas de um sinal nativo de reação. As versões que estou usando react-native-onesignal: ^3.2.8 e react-native: 0.56.0. Consegui implementar notificações de manipulação em segundo plano e primeiro plano, mas estou tendo um problema agora quando o aplicativo é fechado e uma notificação é tocada. O aplicativo mostra apenas uma tela branca em branco que não desaparece a menos que você o feche e reinicie. Não tenho certeza de como lidar com essa situação, pois não consigo encontrar nenhuma documentação no site da OneSignal. É frustrante porque gastei tempo aprendendo e implementando essa biblioteca e agora não tenho certeza se ela será capaz de lidar com esse caso de uso extremamente importante. Eu li uma possível solução para isso acima, que implementa os ouvintes de eventos no index.js, mas estou usando a navegação de reação e preciso obter uma referência do meu navegador principal que é declarado no App.js para navegar para uma tela de pilha aninhada. Eu realmente aprecio qualquer conselho que alguém tenha para lidar com esse problema e como eles o resolveram. Desde já, obrigado.