Hi @saghul@Calinteodor (tmoldovan8x8 doesn’t seem to have an account under this name in this forum) and anyone else interested with the topic. I’m opening this forum to discuss ideas and questions to come up with a good GSOC proposal.
So first to make sure if I understand the general idea correctly: Jitsi provides an SDK for native ios and android right now. The goal is to develop a React Native SDK as it would be convenient for many developers and also the Jitsi Apps are written in React Native.
My first question is if there is any history with this project. Which problems do you see with it? I’m very new to Open Source, but I assume there is reasons why there is little cooperation between this project and Jitsi. Other than that, what is your opinion on building the RN SDK as a RN wrapper for the Native SDK?
To get started I downloaded the SDK Samples and played around with the API a bit to understand the structure and general idea of the SDK.
Would be great if you could answer these questions and perhaps give me a hint or two whether there already are older discussions and challenges for this problem
Correct. Both our apps and native SDKs are really written in RN, the project is about making that consumable as a RN package / library.
Excellent question. I cannot comment on the cooperation since they never reached out to us That said, I consider the approach that project took (wrapping our SDKs in RN) the wrong approach.
Our SDKs are already using RN, so there is no good reason to “wrap the wrapper”. What you get by doing that is tons of incompatibilities. In iOS for example you’ll get 2 instances of RN running at the same time, and depending on the libraries the other app is using you may run into issues when doing dybnamic lookups in the ObjC runtime. On Android it’s actually worse because then the app is “forced” to use the same RN version.
Going forward we should have a podscpec file for iOS and a build.gradle file for android which act like a regular RN package.
I was thinking that maybe one way to go would be to have a react-native-package/ directory where we have the scaffold, and then at package time we copy the files over from the main project, to the right locations.
Ok so I have been thinking about this a bit more and a couple more questions came up.
1.) I am having kinda a hard time what ExternalAPIModule.java is doing, could you give a quick summary?
2.) I realised that what I wrote above is veeery oversimplified. So let me go through the example SDK for android to try to understand what is happening right now: If I decide to launch a conference “org.jitsi.meet.CONFERENCE” is being passed as in an intent. Is that conference.js?
3.) I am not sure if I understand how the JitsiMeetView exactly works. It extends the BaseReactView which looks like it’s backed by the React Native View, but only the part that is on the native side of the RN bridge. But why do we need a View at all when the layouts are defined in different places in native android and ios development. To me in the example sdk
it looks like the JitsiMeetActivity is only used as a API called by a e.g. onButtonClick function, I think it would help a lot if I understood that. Perhaps you could also explain why the native SDKs have been written in that way? (So being backed by the native part of RN components)
I think all of this would help to tackle this feature so very glad about every explanation.
Not really. We already have a root component, we “just” need to make that importable. The biggest challenge I think is the native modules which are part of the app / SDK, that will need to be linked to the consuper apps.
That is a module that acts as a communication channel between the native view and the JS code.
No. When the main intent is launched the pp is opened you end up in App.native.js.
That’s correct. Our view has a single subview, thew RN root view.
Because the SDK is for native apps, and native apps need to have a view of some kind to put in their layout.
In that example, you are going to have 1 Activity in the beginning, let’s say it’s MainActivity. That is 100% native code. When you press a button we’d like to join a meeting.Joining a meeting is implemented with our SDK, so we want to launch a screen with the meeting in it. Generally speaking, in Android, this is another activity, because it’s an action that takes over.
So we launch a second Activity, JitsiMeetActivity, which is also native code, so now the unsuspecting Android developer is using our SDK to implement the meetings functionality, but under the hood, there is JS code and RN! Let’s look at the layers.
JitsiMeetActivity has a simple layout with a single Fragment: JitsiMeetFragment. We made it this way in case someone wants to integrate the Fragment in an activity that had other content too. Then the fragment has a single view: JitsiMeetView. This is where “the magic” happens. JitsiMeetView is a native view with a single subview: the React Native Root View.
We built it this way because our main consumers are native apps, not RN apps.
On iOS there is less integration because typically SDKs don’t offer a ViewController as an API, but a UIView (for example the Google Maps SDK). So there the app needs to implement its own controller, but the concept is the same, there is a JitsiMeetView with a single subview which is the React Native Root View.
I think I did not explain my approach that well before. Allow me to reiterate from our perspective.(My earlier post was from the perspective of the user who will be using a RN SDK)
What I meant was the JS code for the RN SDK will be written before hand this way->
In the RN SDK - all the functions necessary for calling the external API (including the iFrame API will all be initialized by us beforehand) written in another directory separate from the components which we will be using.
Make another file to handle the user defined options for the externalAPI /IFrameApi as props passed to ( 1.) (default server : ‘https://meet.jit.si’)
We will fetch API with the above mentioned specifications. the IFrame API will also be called to initialize it with userdefiend element (the element/window where the SDK user wants to integrate jitsi meet ) in the user app, …which will be a container for jitsi-meet .
Then we will make a View component which will will accept some props and pass it to ( 2.)
This is the View component which will then be set as the window for the above fetched API to the above-mentioned element in (3.).
The native side of the bridge will get only the View component mentioned in (4) from the JS side of the user’s RN application , all the other functions were called by the SDK beforehand.
Would this be the correct implementation of the APIs ?
First, are there any tests for the existing SDKs? I can’t seem to find them.
Help me understand this one please:
If JM Activity receives a READY_TO_CLOSE Broadcast message which in the end just calls View.leave() which resets the props the ReactRootView and reloads it. Do you see any obstacles in handling this with state changes? Because I am not aware of broadcast functionality in react native and I don’t really understand how something similar to the external API would look in that context. Could you elaborate a bit?
About that I got one more question: We got the JitsiMeetView with the React Root View. If someone let’s say joins a meeting, the props are updated and either the ReactRootView is updated or created if not existing. However I can’t really find the link to App.native.js. In which part of the code is this being launched/utilized? I would think that the ReactRootView is set to display App.native.js but I don’t understand how that is happening.