Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bridge] Dispatcher does not send events when phone is locked. #3273

Closed
jamesfzhang opened this issue Oct 7, 2015 · 6 comments
Closed

[Bridge] Dispatcher does not send events when phone is locked. #3273

jamesfzhang opened this issue Oct 7, 2015 · 6 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@jamesfzhang
Copy link
Contributor

I'm working on an app that plays music, and when one song ends the next one starts. The audio player is a bridged Native Module. A song's onStop callback triggers an event that RCTEventDispatcher sends. This is fine when the app is in the foreground or background. When the screen is locked, the event is lost somewhere between the dispatcher and the receiver.

When the phone is locked, only "sent!" is logged:

// AudioPlayer.m

- (void)audioPlayer:(STKAudioPlayer *)player stateChanged:(STKAudioPlayerState)state previousState:(STKAudioPlayerState)previousState
{
  if (state == STKAudioPlayerStateStopped) {
    NSLog(@"sent!");
    [self.bridge.eventDispatcher sendAppEventWithName:@"AudioPlayerEvent"
                                                 body:@{@"name": @"onStop"}];
}
// Receiver.js

NativeAppEventEmitter.addListener('AudioPlayerEvent', (event) => {
  console.log('received!');
});

Is there a setting that must be enabled to accommodate the dispatcher while the phone is locked?

@jamesfzhang
Copy link
Contributor Author

Anyone care to take a look at this, please? :)

@ide
Copy link
Contributor

ide commented Oct 13, 2015

If you encounter an issue the best way to get it fixed is to submit a PR with the right solution. There are only a handful of people working on RN and over 500 open issues and many PRs so high-quality PRs that are easy to maintain will get more attention.

@jaygarcia
Copy link
Contributor

I've run into this personally. The solution i've found is to call an execution block when the phone is brought alive to update the state of the UI. However ALL -- absolutely ALL of the audio controls are routed through objc.

@jaygarcia
Copy link
Contributor

@ide one issue with suggesting PRs is that someone can spend hours on a PR only for it to get rejected and/or ignored, even if it's a good solution. For example, I've submitted a PR allowing web views to cache contents -- something that is almost expected. That PR was ignored.

@mintuz
Copy link

mintuz commented Nov 1, 2015

This is a duplicate, the information provided here may help you. #1282

@jamesfzhang
Copy link
Contributor Author

Thanks @mintuz

@facebook facebook locked as resolved and limited conversation to collaborators Jul 21, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

5 participants