ios: add ability to control deep / universal linking
Since the SDK may be embedded with other apps, we need to recognize our custom
URL scheme and universal links in order to tell the user if we will process the
request or not.
Make them configurable with sane defaults.
This is mostly implemented in the app, with the needed support in the SDK. Since
the app needs to donate intents and deal with creating NSUserActivity objects it
doesn't feel right to do this in a library. Instead, we donate the intents from
the app, but the SDK is ready to extract conference URLs from any intent which
was registered as a conference activity.
This also opens the door for eventually adding Handoff support.
This is done at the app level, not the SDK.
Currently 2 Firebase services are used:
- Crashlytics
- Dynamic Links
They are enabled in tandem, if the appropriate Google services file
(GoogleService-Info.plist on iOS or google-services.json on Android) is found.
Each service needs to be individually enabled in the Firebase console.
On iOS, if the app is closed the startup options are only passed as the
`launchOptions` dictionary of `applicationDidFinishLaunching`. Thus add a helper
method to be called from there by embedding applications so we can copy that
dictionary.
1. Aligns the project structure of Jitsi Meet SDK for iOS with that for
Android for better comprehension.
2. The command `react-native run-ios` uses the last Xcode project or
workspace in the list of these sorted in alphabetical order. Which
limits our freedom in naming. Thus having only an Xcode project in
the root directory of the iOS project structure gives us back the
freedom in naming.
3. Allows the Podspec to work for the app project in addition to the sdk
project because we need Crashlytics in the app which is integrated
via Cocoapods as well.
4. Further removes references to JitsiKit in the source code for the
sake of consistent naming.
Ladies and gentlemen, allow me to introduce you to Jitsi Meet SDK for iOS, the
mobile SDK which powers Jitsi Meet.
The goal is to encapsulate the entire React Native app into a framework / SDK
and offer an API for native (ObjC or Swift) applications to embed the Jitsi
conferencing experience.
While React Native can be embedded in native applications, I don't think it was
designed to be embedded as part of a framework, hidden away from the application
using it. This surfaced as a number of issues which had to be addressed
specifically due to our use-case:
- Universal / deep linking needed to be wrapped to avoid the embedding app from
linking with RN.
- The bundle URL had to be manually constructed, since RN considers that all
resources are in the main bundle, but in case of a framework that is not the
case.
- Custom fonts had to be manually loaded, since UIAppFonts doesn't work on the
framework's Info.plist file.
- The RN packager has to be manually triggered since the React project will no
longer do it for us.
- Custom App Transport Security rules were added since the builtin way to do it
modifies the framework's Info.plist, which is useless in this case.
At this stage, the Jitsi Meet application is just a small single view
application which uses the Jitsi Meet SDK to create a single view which
represents the entire application. Events and external conference handling are
forthcoming.
As a step toward merging jitsi-meet-react with jitsi-meet to share as
much source code as possible between mobile and Web, merge the part of
jitsi-meet-react's source tree which supports mobile inside the
jitsi-meet source tree and leave jitsi-meet-react's Web support in the
source code revision history but don't have it in master anymore because
it's different from jitsi-meet's Web support. In other words, the two
projects are mechanically merged at the file level and don't really
share source code between mobile and Web.
As an intermediate step on the path to merging jitsi-meet and
jitsi-meet-react, import the whole source code of jitsi-meet-react as it
stands at
2f23d98424
i.e. the lastest master at the time of this import. No modifications are
applied to the imported source code in order to preserve a complete
snapshot of it in the repository of jitsi-meet and, thus, facilitate
comparison later on. Consequently, the source code of jitsi-meet and/or
jitsi-meet-react may not work. For example, jitsi-meet's jshint may be
unable to parse jitsi-meet-react's source code.
tmoldovan8x8
Saúl Ibarra Corretgé
hristoterezov
Lyubo Marinov
Lyubomir Marinov