search

react-native-webrtc / react-native-callkeep

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

[Feature-Request, iOS] Add completion for fulfilling action of 'performEndCallAction' delegate #593

Open Hesowcharov opened 2 years ago

Hesowcharov commented 2 years ago

Hey guys! Thank you all for the great project. It's absolutely must-have for calling apps based on react-native!

In our project we use the event 'endCall' to let know a server that incoming call was declined on the client side. The problem is when user declines an incoming call by system notification at the top of screen on iOS, while having the closed app, OS soon pauses all JS execution until a user opens the application.

I has been debugging the issue and finally figured out that implementation of performEndCallAction https://github.com/react-native-webrtc/react-native-callkeep/blob/2a4b0c0dc134021bedd85f57a2cc7dc68a717430/ios/RNCallKeep/RNCallKeep.m#L1051-L1059 fulfills the end call action right after emitting the event to JS-runtime. For example, if fulfillment will be delayed for 5 seconds then RN-side would be able to process properly notifying the server about declining call in my case.

Romick2005 commented 2 years ago

So it seems that you need to send call decline from native side via http request, websocket or any other available server side communication.

Hesowcharov commented 2 years ago

@Romick2005 well yes... That may be one of possible solution to get around this limitation by patching react-native-call keep for your needs (what I'm going to do actually for now 😅). But I suppose for almost all community who depelops applications with react-native and uses JS for it (as well as storing data, credentials, tokens and so on) would be convenient to do this in JS runtime.

Romick2005 commented 2 years ago

But what if the app did not even start JS? If user will quickly decline a call for iOS or Android app wouldn't start JS runtime. Also do not forget to decline call on other callee devices.

Hesowcharov commented 2 years ago

This is a good question...

I agree that may happen for iOS when an application booted in the background on receiving the void-push (notification and appropriate delegate perform faster then application and react tree). This could be worked around by auto fulfillment on timeout so if user decline the call quickly, the notification itself should wait for RN side or reasonable timeout. This is restriction of RN and probably we can't do it better.

My initial suggestion was to provide a convenient method for JS-developers (non native mobile developers) to handle this case only with JS means. And I think many other consumers would use such approach to not pull data to the native side for notifying server keeping business logic strictly on JS.

Hesowcharov commented 2 years ago

If someone else is looking for alternative approach you can get inspiration from my gist - https://gist.github.com/Hesowcharov/1e3e0dcdc6806fb0b234f01d7d9233a6

Hesowcharov commented 2 years ago

up: I've implemented with the approach above and it seems working flawlessly! When the iOS app receives voip-push and boots the application, while a user immediately declines the incoming call with the CallKit UI notification, RN app manages to setup and send a request to the server and only then fulfill the end call action (the notification hangs on a few seconds and wait to be dismissed on fulfillment).