Web's ExternalAPI accepts an object with properties as one of its
constructor arguments and from which it generated a URL. Mobile's
JitsiMeetView.loadURLObject is supposed to accept pretty much the same
object.
Introduces loadURLObject in JitsiMeetView on Android and iOS which
accepts a Bundle and NSDictionary, respectively, similar in structure to
the JS object accepted by the constructor of Web's ExternalAPI. At this
time, only the property url of the bundle/dictionary is supported.
However, it allows the public API of loadURLObject to be consumed. The
property url will be made optional in the future and other properties
will be supported from which a URL will be constructed.
Initializing a new URL/NSURL instance is a chore especially when one
takes into account that the JavaScript side (1) is loading the URL
asynchronously and (2) is capable of parsing strings that may or may not
be represented as URL/NSURL.
The Android method loadURLString(String) may have been called
loadURL(String) to overload loadURL(URL) but I didn't want to do that
because:
1. It would not be compatible with existing source code such as
loadURL(null) which would have become ambiguous.
2. I wanted to achieve better convergence with the iOS API.
When a Container is not visible there is no need for it to react to touch
events, thus avoid wrapping it in a touch component.
In addition, simplify the style needed for hiding the component. Moving the view
out of the window boundaries no longer works on RN 0.42 on iOS. Seting the size
to 0 works well on both platforms, but in the future (when we upgrade to RN >=
0.43) we should switch to display: none:
4d69f4b2d1
Because on web video track is stored both in redux and in 'localVideo'
field, video is attempted to be unmuted twice when turning off the audio
only mode. This will crash the app with 'unmute operation is already in
progress'. This commit will prevent from taking action from the web
world if the video track already exists and will make the redux side
rollback unmuted status in case unmute fails.
In another installment of "how on earth?!", using a 1px border instead of a
0.2px border fixes view clipping on a device where it didn't work before
(Moto X Play).
Observations:
- When nothing was rendered, rotating the device made the buttons show up, this
makes me think the Surface is not properly composited with the toolbar view
for some reason. Why this happens in some devices and not in others remains a
mistery.
Other approaches attempted:
- Setting View.collapsed to false so it will remain in the view hierarchy. It
made no effect.
- Setting View.needsOffscreenAlphaCompositing to true. It made no effect.
Just like before, I came up with this workaround by accident, but couldn't find
another way, so here we go again.
This essentially reverts
023359b9d2
In the filmstrip we keep a container full of thumbnail views. Destroying these
every time we want we want to hide it is costly, as new renderers have to be
recreated, and they lack context, so there is an increased chance for "black
thumbnails".
When video is unmuted when toggling off the audio only mode it
dispatches video muted status, but does not roll it back in case it
fails. That was causing toolbar button on Web to display incorrect
video muted status.
* Fixes some toolbox/toolbar styles and variables
* [squash] Fixes variable name to fit better its purpose
* [squash] Fixes secondary toolbar variable name
With the upgarde of @atlaskit/icon to 7.0.0, the size prop
essentially became required to maintain its appearance in the
jitsi app, otherwise it'll unexpectedly try to take up the
available space and cause minor display issues.
The speakerStatus field already exists as part of the objects
in the participant reducer. When the library updates the
connection status of a user, plumb that update through to redux.
Instead of passing stats through UI then VideoLayout then the
SmallVideo, pass stats directly to what uses it--ConnectionIndicator.
This also bypasses adding the stats to the store, as they do not
seem to be something that needs to be shared or stored app-wide
just yet.
This was already an implicit requirement, as it's the only version implemented
in libwebrtc.
The reason to add this is to (defensively) try to filter old devices which may
not implement it.
WebRTC's own Android demo app defines this.
Saúl Ibarra Corretgé
Lyubo Marinov
damencho
hristoterezov
Saúl Ibarra Corretgé
paweldomas
yanas
Leonard Kim
George Politis
Aaron van Meerten
Aaron van Meerten
bbaldino