search

react-native-webrtc / react-native-callkeep

iOS CallKit framework and Android ConnectionService for React Native
ISC License
923 stars 445 forks source link

Multiple fixes on Android #724

Closed saif-o99 closed 1 year ago

saif-o99 commented 1 year ago

This PR deliver some fixes & new code

1- checkIsInManagedCall was added to check if there is a native active call in android, in my case this was useful to check if there is a native active call, prevent app from making a call

2- onHasActiveCall was added to tell the JS side about native call status, in my case this covered the case where you are in an app call then you accept a native call, this will trigger this event which i end the call by it. so no two calls be on the same time. before, the two calls were running at the same time

3- change in VoiceConnectionService.java is to fix #625

4- onHostDestroy has been added to stop all calls and processes when app is killed

saif-o99 commented 1 year ago

@manuquentin Can you please check this? Thanks

manuquentin commented 1 year ago

Thanks @saif-o99 , can you please add documentation about the new event ?

saif-o99 commented 1 year ago

@manuquentin Done

saif-o99 commented 1 year ago

hey @manuquentin , is this gonna be merged soon?

dkornilove commented 6 months ago

@saif-o99, @manuquentin, the new onHostDestroy behavior should be optional. I spent two days debugging after updating my app dependencies because the foreground service and current call started to disappear when the app is swiped away from recents. So this was unexpected breaking feature for me

saif-o99 commented 6 months ago

@saif-o99, @manuquentin, the new onHostDestroy behavior should be optional. I spent two days debugging after updating my app dependencies because the foreground service and current call started to disappear when the app is swiped away from recents. So this was unexpected breaking feature for me

Sorry to hear that, but the default behaviour of any app is that when you kill the app you kill everything related to it. try kill for instance Facebook Messenger while in a call. the call will be closed. so having call active while you don't have the app in the background is confusing for the users and seems like a bug.

dkornilove commented 6 months ago

@saif-o99 Speaking for myself, this behavior is unexpected and likely affects others as well. Throughout the library's existence, the behavior has been consistent, and its sudden change without announcement is surprising. I utilize foreground services not only for calls, so it's critical for me that the activity isn't completely killed after closing the app. The foreground service is designed to continue functioning even when the app is closed. Why does a library responsible only for calls override the behavior of the entire application?