Looks like the "Firebase Analytics" dependency is needed when migrating to the
new Firebase Crashlytics SDK. We are only interested in the "latest iversion
crash-free users" stat, which seems to require this. The documentartion is
somewhat confusing though.
It's a number whichb must be ever increasing with each build submitted to the
store.
Automate its value by using the number of seconds since 1st of January 2019.
That should be enough for ~680 years.
When running the app from Android Studio the React packager is not automatically
started. In vanilla RN projects this is done by the "react-native run-android"
command, but often times it is desired to run from Android Studio.
This fixes that by starting the packager from Gradle.
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.
Glide (which is used by react-native-fast-image) can cause trouble if the host
app (the one using the SDK) is using Glide already.
To avoid this, don't use the builtin AppGlideModule (as the docs recommend) and
let apps define it.
Set them to the next release versions. In additon, the buildNumber variable will
be used to match the requirements of versionCode:
https://developer.android.com/studio/publish/versioning
that is, a monotonically increasing number, independent of the app / sdk
version.
Dames en heren, welcome to Jitsi Meet SDK for Android, the Jitsi Meet library
for Android.
The Jitsi Meet SDK encapsulates React Native and all the dependencies Jitsi
Meet has so other aopplications can integrate it easily.
Unlike iOS, creating "fat" libraries is not allways (if at all) possible on
Android, however, effort was put into making the integration as easy as
possible.
While React Native can be embedded in native applications, I don't think it was
designed to be embedded as part of an Android library, 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:
- Activity lifecycle methods must be linked with the React Native engine, so the
library provides wrapper methods.
- Custom fonts have to be manually added as assets, since the provided gradle
script doesn't work properly in a library target.
- The RN packager has to be manually triggered since the gradle script will no
longer do it for us.
At this stage, the Jitsi Meet application is just a small single activity
application which uses the Jitsi Meet SDK to create a single activity which
represents the entire application. Events and external conference handling are
forthcoming.
PS: Yours truly would like to add that it was a lot more fun to work on the iOS
side of things.
Now that Apple have approved build 1.3.204 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.
Now that Apple have approved build 1.2.199 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.
Turns out React Native's timers (setTimeout / setInterval) don't run while the
app is in the background: https://github.com/facebook/react-native/issues/167
This patch replaces the global timer functions with those from the
react-native-background-timer package, which work in the background.
These timers won't magically make an application work in the background, but
they will run if an application already happens to run in the background. That's
our case while in a conference, so these timers will run, allowing XMPP pings to
be sent and the conference to stay up as long as the user desires.
The implementation varies across platforms, with the same goal: allow the app to
use the entire screen real state while in a conference.
On Android we use immersive mode, which will hide the status and navigation bars.
https://developer.android.com/training/system-ui/immersive.html
On iOS the status bar is hidden, with a slide effect.
Now that Apple have approved build 1.1.185 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.
Now that Apple have approved build 1.0.178 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.
Titus-Andrei Moldovan
Saúl Ibarra Corretgé
tmoldovan8x8
Bettenbuk Zoltan
Saúl Ibarra Corretgé
hristoterezov
paweldomas
Lyubo Marinov
Lyubomir Marinov
Saúl Ibarra Corretgé