[iOS] [Bug report] isCallActive return undefined

[ThinhVu]

As docs in https://reactnative.dev/docs/native-modules-ios, ReactNative method always return void so to pass value to JS layer, we need to use callback, Promise or eventEmitter.

Current iOS implement. Return boolean value in this method doesn't send to JS layer

+ (BOOL)isCallActive:(NSString *)uuidString
{
    CXCallObserver *callObserver = [[CXCallObserver alloc] init];
    NSUUID *uuid = [[NSUUID alloc] initWithUUIDString:uuidString];

    for(CXCall *call in callObserver.calls){
        NSLog(@"[RNCallKeep] isCallActive %@ %d ?", call.UUID, [call.UUID isEqual:uuid]);
        if([call.UUID isEqual:[[NSUUID alloc] initWithUUIDString:uuidString]] && !call.hasConnected){
            return true;
        }
    }
    return false;
}

Js index:

isCallActive = async(uuid) => await RNCallKeepModule.isCallActive(uuid);

I already tried with Promise method, it's work but not for my case.
I needed to call this method each second so I changed to event emitter to prevent "illegal callback invocation from native module" error.

PR is not available atm.

[ThinhVu]

Work-around for one who need this function.
In node_modules/react-native-callkeep/ios/RNCallKeep/RNCallKeep.m

1. Define event emitter name

static NSString *const RNCallKeepDidLoadWithEvents = @"RNCallKeepDidLoadWithEvents";
static NSString *const RNCallKeepIsCallActive = @"RNCallKeepIsCallActive"; // <-- add this line

2. Add defined event to supportedEvents array

- (NSArray<NSString *> *)supportedEvents
{
    return @[
        ...
        RNCallKeepDidLoadWithEvents,
        RNCallKeepIsCallActive. // <-- add this line
    ];
}

3. Change exported method RCT_EXPORT_METHOD(isCallActive:(NSString *)uuidString) to

RCT_EXPORT_METHOD(isCallActive:(NSString *)uuidString)
{
#ifdef DEBUG
    NSLog(@"[RNCallKeep][isCallActive] uuid = %@", uuidString);
#endif
    CXCallObserver *callObserver = [[CXCallObserver alloc] init];
    NSUUID *uuid = [[NSUUID alloc] initWithUUIDString:uuidString];

    for(CXCall *call in callObserver.calls){
        NSLog(@"[RNCallKeep] isCallActive %@ %d ?", call.UUID, [call.UUID isEqual:uuid]);
        if([call.UUID isEqual:[[NSUUID alloc] initWithUUIDString:uuidString]] && !call.hasConnected){
            [self sendEventWithNameWrapper:RNCallKeepIsCallActive body:@{ @"active": @true }];
            return;
        }
    }

    [self sendEventWithNameWrapper:RNCallKeepIsCallActive body:@{ @"active": @false }];
}

4. In node_modules/react-native-callkeep/actions.js, add

const removeSubscription = (sub) => {
  eventEmitter.removeSubscription(sub)
}

and export it

export const listeners = {
  ...
  isCallActive,
  removeSubscription
};

5. In node_modules/react-native-callkeep/index.js, change isCallActive = async(uuid) => await RNCallKeepModule.isCallActive(uuid); to

  isCallActive = uuid => {
    return new Promise((resolve, reject) => {
      try {
        const sub = listeners.isCallActive(({ active }) => {
          resolve(active)
          listeners.removeSubscription(sub)
        })
        RNCallKeepModule.isCallActive(uuid)
      } catch (e) {
        reject(e)
      }
    })
  }

Now you can using await RNCallKeep.isCallActive(uuid) in your code as expected.

[ajnozari]

Iirc I made this contribution, I have a fix for this that I can submit as a PR this week. I have an exam tomorrow (Monday) but can look at submitting it after. Will fix this issue and expose it properly to the JS side.

At the time I made it I didn’t include the js layer since I interrupted it solely in native code.

[viveknair]

Hey there @ajnozari , did you get a chance to merge your PR for this?

[ajnozari]

I have worked on it but have not submitted another PR. I will get to it before the week is done.

[devWaleed]

@ajnozari any updates with this? I am getting issues with this method as well, returns undefined as explained in #332

I tried the above solution, i don't get undefined now but it doesn't detect active call either, it rejects promise even though call is active in background

[ajnozari]

@devWaleed I'm finally back at this part of our app and am giving this a look now. I'll have a pr coming soon.

[devWaleed]

@ajnozari thanks...here are some questions that I opened on SO for solving this issue:

https://stackoverflow.com/questions/65146599/callkit-call-hasconnected-always-returning-true
https://stackoverflow.com/questions/65127789/react-native-callkeep-iscallactive-using-cxcallobserver
https://stackoverflow.com/questions/65180711/cxcallobserverdelegate-not-being-invoked

I was assigned a different task so I didn't work on it further, but if this helps you.

[jitensuthar]

Hi @ajnozari, I could also use the isCallActive functionality to check against early/immediate acceptance of a call. Wondering if there is a PR still imminent!

[ajnozari]

I really am sorry School has just kept me super busy. However I went back to look at my old implementation of this function and there’s a couple of things with how y’all want to use it. One of the things with how callKit works is it requires the signal to cancel a call to come from the native side. Android does not have this issue. However if the phone is ringing the end signal on IOS is more reliable if it’s handled on the native side. This was originally designed to be an extra check in your incoming push notifications, before they’re sent to the JS side to allow you to end the ringing if for example you answered on another device. This should be exposed to JS, but the real purpose of it is to be placed before you pass any push to the js side of the app. In the App delegate I check if this is the end call notification (answered on another device is a flag you can set in iOS). If it is, and the call is not currently active, (this functions sole existence), I can end the ringing right there and it works if the app is in the background as well. Android doesn’t have this issue as it can cancel the call from the js side even if app is in the background.

…

Sent from my iPhone On Jan 30, 2021, at 3:16 AM, jitensuthar <[email protected]> wrote:  Hi @ajnozari<https://github.com/ajnozari>, I'm in need of the isCallActive functionality to check against early/immediate acceptance of a call and wondering if a PR is still imminent? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#278 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRDXONZLNVMTLBKOVDNGLS4O533ANCNFSM4Q7LTWFQ>.

[ajnozari]

To specifically answer you here there should be no difference between early and immediate answer of a call, CallKeeps didAnswerCall listener handles that. Anytime the user hits he green answer button that event is fired. If the app was in background there’s another function that handles an answer with coming in from the background. You absolutely do not need nor should you use this function for that purpose. It is already built into callKeep. Edit got cut off: That being said I will double check that it is exposed and make a new PR if necessary.

…

Sent from my iPhone On Jan 30, 2021, at 3:16 AM, jitensuthar <[email protected]> wrote:  Hi @ajnozari<https://github.com/ajnozari>, I'm in need of the isCallActive functionality to check against early/immediate acceptance of a call and wondering if a PR is still imminent? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#278 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRDXONZLNVMTLBKOVDNGLS4O533ANCNFSM4Q7LTWFQ>.

[jitensuthar]

Appreciate the reply and detailed explanation @ajnozari. Out of curiousity, have you tried to answer or reject an incoming call very quickly, within a second of it coming in on iOS (i.e. the call comes in and you accept it nearly immediately on seeing it)? I may have something set up incorrectly or suboptimally so curious if you also experience the same behavior.

The accept and reject call handlers are NOT firing for me on iOS when I do this with the app in a kill state (not bg state, but killed). Nor are they captured through didLoadWithEvents. This is a very specific and perhaps not-too-common edge case, but I live for making sure all edge cases are cleanly handled :)

isCallActive seemed like the easiest fix for me to add in as a check on the JS side to at least handle the accepted call case. Obviously, determining call rejected won't be possible like this because I won't be able to distinguish between a rejected and unanswered call, but that I care less about (the call will just time out on the other side, same as if the callee ignored it or never picked up). Right now, CallKeep is not informing me of calls accepted in this (perhaps rare) scenario which is a problem I wanted to button up.

Again to clarify, all of this only applies for calls that were responded to near-immediately upon them displaying when the app was in a kill state. Otherwise, the handlers have been working great!

[devWaleed]

Appreciate the reply and detailed explanation @ajnozari. Out of curiousity, have you tried to answer or reject an incoming call very quickly, within a second of it coming in on iOS (i.e. the call comes in and you accept it nearly immediately on seeing it)? I may have something set up incorrectly or suboptimally so curious if you also experience the same behavior.

The accept and reject call handlers are NOT firing for me on iOS when I do this with the app in a kill state (not bg state, but killed). Nor are they captured through didLoadWithEvents. This is a very specific and perhaps not-too-common edge case, but I live for making sure all edge cases are cleanly handled :)

isCallActive seemed like the easiest fix for me to add in as a check on the JS side to at least handle the accepted call case. Obviously, determining call rejected won't be possible like this because I won't be able to distinguish between a rejected and unanswered call, but that I care less about (the call will just time out on the other side, same as if the callee ignored it or never picked up). Right now, CallKeep is not informing me of calls accepted in this (perhaps rare) scenario which is a problem I wanted to button up.

Again to clarify, all of this only applies for calls that were responded to near-immediately upon them displaying when the app was in a kill state. Otherwise, the handlers have been working great!

I was using isCallActive in the same sense. If the call was accepted too early, didLoadWithEvents was not working correctly for me so I had only this method to verify if the call was accepted.

I use Firestore which tells me if a call was ended so that ends call on iOS Native UI by calling endCall function and passing UUID.

But I noticed one thing, if you're using debug build you may have to wait for at least 3 to 5 seconds before accepting call which will be notified as accept call event, if you do it before that it won't work. But in release mode I was able to pick call on iPhone 10 at around 1.5 seconds and it worked correctly. That was enough for me so I stopped looking for this method.

[ajnozari]

That is understandable, the delay from debug can be very deceiving sometimes.

[eminberkay]

the best is to find different library.