In order to get this resolved as quickly as possible, we’re going to investigate two possible solutions for you:
Adding the ability to navigate within your app after minimizing the meeting (likely requires a feature request)
Fixing the crash you originally identified (note that we still have not been able to reproduce this on our end so it may take a while to get this right)
Once we have any updates on either of these approaches, I will let you know.
Adding the ability to navigate within your app after minimizing the meeting (likely requires a feature request)
We are looking forward to seeing this feature in the next SDK which will benefit lots of our members to be guided by our clinicians and know how to use our app.
Fixing the crash you originally identified (note that we still have not been able to reproduce this on our end so it may take a while to get this right)
During the time I debugged the sample app, I found that the root cause of throwing exception on adding null child in the videoListLayout when returning the meeting and trying to set the visibility of videoListLayout. It is because onAttachedToWindow() in the VideoListLayout.java does not get called and this leads to init() not get called neither. videoList will be null when it tries to set the visibility when returning the meeting. I changed the following function to make it not crashed.
// In VideoListLayout.java @Override
public void setVisibility(int visibility) {
super.setVisibility(visibility);
if (visibility == VISIBLE) {
if (videoList != null && indexOfChild(videoList) < 0) {
addView(videoList);
updateArrow();
}
//updateArrow();
} else {
removeView(videoList);
}
}
And now it is working when it returns to the meeting from minimization window. I don’t know if this change has a big impact to your all samples. This is just for your reference. BTW, I need to mentioned that which button I used to test the sample code - “Join Meeting” button in InitAuthSDKActivity. I just injected the SDK_JWT, meeting Id and password to join the meeting and then it entered the meeting in the MyMeetingActivity. I will send the video to you.
I’m glad to hear you were able to identify a workaround for the crash! The change you’ve made may impact one view’s rotation, but shouldn’t have any implications on the overall functionality. That being said, please do let me know if you notice any unexpected functional differences after making this change.
We are still investigating to possibility of adding the ability to navigate within your app after enabling this in the default UI and will let you know if there any updates on that end.
Thanks for your response. Sure! Will let you know if I see any unexpected behavior after my change, I will be looking forward to the solution of adding the ability to navigate within our app after enabling MinimizeMeeting in the default UI.
Is there any way I can hide the “start/stop video” and “switch video” icons when join the meeting? I use meetingSettingsHelper.enableForceAutoStopMyVideoWhenJoinMeeting(true), but that just disable the start-video function. I wan the meeting just only with audio communication. I tried to do meetingOptions.no_video = true which does not hide the video. Do you have any recommendation?
Just want to know if it is possible that you can have the solution of adding the ability to navigate within our app after enabling MinimizeMeeting in the default UI by the end of this month. We really need this feature to get our members to be able to navigate our app easily while they are in our zoom session. If you have the beta version, that would be great!
Unfortunately, our engineers are very low on bandwidth right now and can only implement what they can. We also do not have the power to prioritize this issue over others. I understand how this is inconvenient and I apologize that you have waited this long. I will ping the engineers again about this and we will let you know what they say.
I have done the minimization feature in our app. Everything works great except one thing that when meeting is minimized and mobile participant presses system home button and then presses the minimized meeting window, returning to the zoom meeting screen has the delay about 3-4 seconds on some devices. I want to add the system dialog to indicate user we are back to the zoom meeting. I found that resuming the MyMeetingActivity is possibly triggered by Zoom SDK. If this is the case, Is there any callback interface I can use to indicate the dialog?
That’s great to hear that you were able to successfully implement this in your app! Unfortunately the SDK does not provide the callback you are looking for. The only callback related to minimizing the meeting is afterMeetingMinimized, which is obviously not what you are looking for.
The good news is I am able to consistently reproduce the delay that you are seeing when the app is backgrounded, so we should be able to begin investigating this. I will be sure to let you know as soon as we have an update.
Thanks for you quick reply. This is the piece of code that is triggered by tapping on the minimized window. I tried to add the alert dialog here to indicate we are back to the meeting screen, but it does not work to show on the home screen. I think it’s bc the activity is on the background and the dialog cannot be seen. Let me know if you have any solution.
private class SingleTapConfirm extends GestureDetector.SimpleOnGestureListener {
@Override
public boolean onSingleTapUp(MotionEvent event) {
if (null != refContext && null != refContext.get()) {
Context context = refContext.get();
//TODO: Add the Alert Dialogue if the minimized window on the top of the home screen
hiddenMeetingWindow(false);
Intent intent = new Intent(context, MyMeetingActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
context.startActivity(intent);
}
return true;
}
}
We have already been able to reproduce this issue on our end, so no further action is required by you. We will let you know as soon as we have any updates.
The root cause is : android background app switch 5 seconds limit .
// Amount of time after a call to stopAppSwitches() during which we will
// prevent further untrusted switches from happening.
private static final long APP_SWITCH_DELAY_TIME = 5 * 1000;
Thanks for sharing this information. So that means we don’t any control for this issue. But 5 secs is really long. Maybe providing a system alert would be a good solution.
