Hi @ekaansh.zoom,
We are currently using the latest ZoomVideoSDK (version 2.2.0) for iOS and have been encountering frequent crashes in the getShareStatus function when users attempt to share their screen. In some cases, the app does not crash but fails to provide the screen-sharing feed consistently.
Could you please provide guidance on resolving this issue and ensuring reliable screen-share functionality? The debug log for reference can be found here ( https://drive.google.com/file/d/1HHTIMYhneqv8rRWu40h8pQjvwHBJ2MUW/view?usp=sharing
).
We appreciate your prompt response and any steps you can recommend to address this problem.
Please allow me to understand your issues better here. Currently, what type of share (Entire device screen or a single UI View) and how are you doing the share that caused this issue? Also, depending on your use case, the getShareStatus might not be required for the sharer, but it is important for the receiver side under the onUserShareStatusChanged delegate.
HI @boonjun.tan,
Thanks for your response. We currently are using single UI view sharing. Every time our view controllers changes, we right away call the .stopShare() function and then call the startShare() function. This way, the right view is being shared. We check if its the sharer in onUserShareStatusChanged function and return right away if it is. Only when it is the receiver do we call the getShareStatus(). We were originally using on version v1.12.0 where we called user?.getShareCanvas() and didn’t run into any issues. Only when ZoomVideoSDKShareAction was introduced did we start noticing problems
Am I understanding the video you shared correctly that the iPad on the right, upon clicking the blue “Start” button, will start sharing the UI view, and the iPad on the left should receive it? However, it is currently showing a black screen instead of the “Touch Screen Tutorial” view.
If yes, upon sharing, did the receivers get the onUserShareStatusChanged for the sharer information and how are you subscribing to the share view based on the information given in the onUserShareStatusChanged delegate? You can also refer to our documentation on this here.
Hi @boonjun.tan,
Your understanding is correct. We are getting a black/grey screen instead of the “Touch Screen Tutorial” view.
Upon sharing, the receivers got the onUserShareStatusChanged which not errors. We then do is the following (agrees with the documentation you shared)
DispatchQueue.main.async {
// Get User’s share canvas.
if let shareCanvas = shareAction?.getShareCanvas() {
switch shareAction?.getShareStatus() {
case .start:
// Set video aspect.
let videoAspect = ZoomVideoSDKVideoAspect.panAndScan
// Render the user's share stream.
let error = shareCanvas.subscribe(with: self.remoteScreenView, aspectMode: videoAspect, andResolution: ._Auto)
break
case .stop:
let error = shareCanvas.unSubscribe(with: self.remoteScreenView)
break
default:
break
}
}
}
I want to make sure you also know that before we call startShare, we check isSharingOut(), if so, we stopShare and then immediately call startShare. We are mainly having issues during this time. We are forced to do that because we have different views that are being shared before and after
I believe i have gotten to the bottom of the issue, shareAction?.getShareStatus(), gives me ‘.none?’ status instead of ‘.stop’ when i call stopShare function
I have missed this out earlier on and was answering your the other post instead. As with multi share available, are you currently allowing multiple share or only 1 share at the same time? The reason why I am asking this is because there can be a case where user A started sharing and another user B share later on.
Can you check that your isMultiShareEnabled in the ZoomVideoSDKShareHelper is disable? Also, is the subscription done in the main thread? If so, can you also check that whenever a new share is pushed, the older shares are unsubscribed first from the same view before a new share can be pushed.
Hi @boonjun.tan,
We don’t explicitly set isMultiShareEnabled to true—it only takes that value if it’s the default behavior set by the Zoom SDK. The subscription is performed on the main thread. Before initiating a new share, we always check .isSharingOut(). If it returns true, we call stopShare() and immediately follow up with startShare(). However, we don’t wait for the onUserShareStatusChanged callback before calling startShare().
Do you think this might be causing the issue? One of the Zoom developers mentioned during the office hours that it could be related to triggering startShare() too soon after calling stopShare().
Yes, this will cause an issue. Once the stop share is called, Zoom has some internal process running, and the only time that the share has truly stopped entirely will be based on the onUserShareStatusChanged’s callback stop status. Please try this way instead.
Hi @boonjun.tan ,
I tried that way and the issue is still there. The ZoomVideoSDK.shareInstance()?.getShareHelper().stopShare() still gives me .none status inside the func onUserShareStatusChanged(_ helper: ZoomVideoSDKShareHelper?, user: ZoomVideoSDKUser?, shareAction: ZoomVideoSDKShareAction?) function
What is this .none status that you mentioned here? Did the stopShare gives an error code of 0 (success) when you execute that method and also once that is executed successfully, all the participants within the session will get the onUserShareStatusChanged of the user with its ShareCanvas’s shareStatus to be ZoomVideoSDKReceiveSharingStatus_Stop. Hence once you get this callback, you can then proceed to turn on share if you will like to. Or you can get also check the share status of the user by using the user object and getShareActionList.
Hi @boonjun.tan,
Its the ZoomVideoSDKReceiveSharingStatus_None. When you stop sharing, all users get the onUserShareStatusChanged callback but instead of ZoomVideoSDKReceiveSharingStatus_Stop status they get ZoomVideoSDKReceiveSharingStatus_None
That shouldn’t be the case. Can you send me the new Zoom’s log via the new way that I mentioned and also code snippets of your current project on how you are screen sharing (Broadcast Extension or View) and also your onUserShareStatusChanged callback.
Hi @boonjun.tan,
You were absolutely right—shareStatus was indeed providing the correct status. After further investigation, we discovered that the actual issue lies in the thread safety of shareAction?.getShareStatus().
The shareAction parameter is passed into the onUserShareStatusChanged() delegate callback. When we retrieve shareStatus directly from the background thread where the callback is invoked, we get the expected result. However, when we attempt the same call within a DispatchQueue.main.async block, the status unexpectedly returns as .none.
This behavior strongly suggests that getShareStatus() is not thread-safe. Interestingly, we didn’t encounter this issue in previous SDK versions.
Could you confirm whether this is expected behavior? And if not, is there a plan to address this in an upcoming ZoomVideoSDK release?
Can you please share the entire code where you are handling the background/main thread because all our SDK related method should be called in the main thread. Are you having a background thread within onUserShareStatusChanged to handle the shareAction right now?