Start new conference from native Activity

Hi community,

we are developing an application for Android and we added previous logic (CustomManagerActivity starts MainActivity) to schedule and start a new conference. For this flow, we set the JitsiMeetConferenceOptions like this:

return new JitsiMeetConferenceOptions.Builder()

Then, when user hangs up the conference we finish the MainActivity (which extends from JitsiMeetActivity) in onConferenceTerminated method.

However, when the user tries to create a new conference and starts again MainActivity, we received the next error:

D/JitsiMeetSDK: ExternalAPI Sending event: CONFERENCE_TERMINATED with data: { NativeMap: {"url":"","error":"Error: Config no longer needed!"} }
D/JitsiMeetSDK: onConferenceTerminated: {error=Error: Config no longer needed!, url=}

Note: It’s necessary consider this flow because we have another logic at the beginning of the application.

You shouldn’t terminate the MainActivity. Launch Jitsi in its own activity, which by default is terminated when onConferenceTerminated kicks in.

Also, what SDK version are you using?

We are using the current sdk version from jitsi-meet code in master.

Related to navigation, we need to follow the next navigation.

CustomManagerActivity -> MainActivity (extends JitsiMeetActivity)

And in the moment that the user finishes the conference, we need to come back to CustomManagerActivity.

Is your MainActivity where tthe app starts? Also, please sshare the code so we can spot mistakes.

No, it’s another activity. I can share some of our code. I attached it.JitsiDemoClasses.txt (10.6 KB)

We have a question: how could be possible if we add a webview along with the fragment that displays the conference? Could we show and hide depends on our flow?

You really shouldn’t start from our MainActivity, it’s just a change for a standalone app. Note that on initialize it calls .setWelcomePageEnabled(true). You will want to remove that and I think your problem would be solved.

But really, I think you should just call JitsiMeetActivity.launch from your own activity like so:

1 Like

You could have your own activity which has 2 fragments, one for the webview and one for the conferencce. Take a look at JitsiMeetFragment

Note that you’ll need to wire the fragment. to the activity, like JitsiMeetActivity does internally.

1 Like

Ok, we’re going to try it in that way. Thank you @saghul for your answers!

Hi again!

We chose lauch JitsiMeet from our own activity and it’s works!

However, if the user turns off his/her wifi, the conference finishes with the application. The log displays the following errors. crash_log.txt (8.5 KB)

Also, in the project, when user turns off his/her wifi, there is no reload dialog too. So how could we enable this functionality?

Looks like an uncaught exception. Can you paste the full log?

The reload dialog is only available for recoverable errors, fatal errors terminate the activity. You do have the error information in the onConferenceTerminated handler so you can prompt the user for reconnecting on your own app.

@saghul Sure! I attach it. full_crash_log.txt (1.4 MB)

Unfortunately the traceback is not useful… do you get anything in the metro console or the error dialog? Any chance you can share a small test project for us to repro?

If we comment the finish method on onConferenceTerminated, we receive the following error:

The message from this callbacks is:
Conference terminated: {error=connection.droppedError, url=}

The console debug throws the following information: debugger_logs.log (590.6 KB)

I’m going to try share more information because it’s a private project. We started our development from tag stable/jitsi-meet_4101.

Hum, that means somehow your connection with the server was interrupted abruptly, which is what happened. You won’t see that if you compile in release mode.

Yes, the communication is interrupted because the user disables his/her WiFi. Running as release, the activity doesn’t crash, but the dialog still doesn’t display (I think it’s because of a fatal error as you mentioned before).

Yes, this is expected.