I’m using a custom UI and I hide the annotation toolbar with:
hideAnnotationInScreenShareToolbar(true);
Then when I want to enable annotations programmatically during a screen share, I use WindowManager to add a system overlay containing a MobileRTCShareView. Then I call:
passing in the MobileRTCShareView from the system overlay. This was working up through SDK v5.9.6.4777. However starting with v5.10.1.5184, remote users cannot annotate the SDK app’s screen. The remote user can draw, but the drawings disappear after a few seconds and no other users can see the drawings.
If I enable the SDK annotation toolbar, annotations do work from there. So this only appears to be a problem with my custom programmatic annotation solution.
Can you please confirm whether you made any changes in your implementation when updating the SDK? Also, there were some changes to annotation in v5.10.3. They may not fix the behavior you’re seeing, but just to be sure can you please try updating and confirming whether the issue exists on that version as well?
I discovered this in v5.10.3.5614 (as I was giving a demo to a group of Zoom sales reps, I was like awww this used to work! ).
To find the exact version this broke, I reverted the SDK upgrades step by step back to 5.9 and it started working again. I have not gone near my annotation implementation in a while.
Thanks for confirming. Can you please provide a code snippet showing how you are starting annotations programmatically so that we can look into what may have changed?
Actually I do. I make calls to InMeetingAnnotationController.disableViewerAnnotation(boolean) when I want to enable and disable remote desktop users’ annotation toolbar from displaying. Once I have everything setup and ready to go, I pass in false to cause the annotation toolbar to become visible on the desktop user side. Once done with annotations, I pass in true to remove the desktop users’ toolbar.
I also used to make calls to InMeetingAnnotationController.startAnnotation() and stopAnnotation(), but I found these calls were unnecessary at the time.
Thanks for confirming. Can you please provide some specifics around exactly when you are calling disableViewerAnnotation? I suspect that the timing of this will be the key that enables us to reproduce the issue on our end.
If the code snippet I shared above returns true, the very next thing I do is call disableViewerAnnotation(false). Once the user chooses to pause annotations or stops sharing completely, I call disableViewerAnnotation(true).
I’m wondering if it’s possible that a race condition was introduced. Are you able to try waiting a few seconds before calling disableViewerAnnotation? If that makes any difference, it should narrow down the cause of the issue quite a bit. Otherwise if it still is not working as expected, I think we’ll need to take a look at the SDK logs.
For a quick test, I removed all calls to InMeetingAnnotationController. No change. Then I added a call to InMeetingAnnotationController.startAnnotation(), which I used to do a long time ago. Also no change.