0.16.0

Features

• Introduced new method, getNetworkTopology() which indicates whether the call is happening over an "sfu" or "peer" connection type.

  let { topology } = await call.getNetworkTopology();
  // topology will be set to 'sfu' | 'peer' | 'none' (if not in the call)

• Added support for new portrait layouts to live streaming with the options of a 'vertical' or 'inset' layout. See the portrait option in the docs for more information.

Other improvements

• Minor README updates

0.15.0

Features

• Updated support for React Native versions ≥ 0.64.
  Note: peer dependencies have also changed. See the README for installation instructions updated with the proper npm packages and versions. A gotcha: if you're updating from a previous version of react-native-daily-js, please note that you'll have to npm uninstall @react-native-community/async-storage, which is no longer a peer dependency.

0.14.0

Features

• Added 'staged' media track subscription state that corresponds to setting up the connections for a track, but not transmitting data across that connection. This lets you "stage" tracks that you know you'll need soon, for later rapid transition into the fully "subscribed" state, without using any extra bandwidth. Reminder: Track subscriptions are only supported when your call is in SFU mode.

  Example 'staged' usage

  call.updateParticipant(id, {
    setSubscribedTracks: {
      video: 'staged',
    },
  });
  

• Launched several affordances to give you control over how you want to receive the video tracks that you're subscribed to. These are referred to as receive settings. The first—and so far only—configurable receive settings are the desired maximum simulcast layers for video and screenVideo. A higher simulcast layer corresponds to higher quality. The new affordances are:

  • receiveSettings() and updateReceiveSettings() instance methods
  • receiveSettings DailyIframe property
  • receive-settings-updated event

  Note: Simulcast layer settings only apply when a call is in SFU mode.

  Example usage: update receive settings for a participant on the fly

  call.updateReceiveSettings({
    'some-participant-id': { video: { layer: 0 } }
  });
  

• You can now live stream with react-native-daily-js. To get started, check out our docs on live streaming instance methods.

0.13.0

Improvements

• preAuth() now rejects its Promise with a meaningful error when there's a room-related error (e.g. when in invalid or expired room is specified), with its contents matching the corresponding 'error' event's payload.

0.12.1

Bugfixes

• Resolved an iOS issue where, when switching networks (e.g. from Wi-Fi to LTE), your chosen in-call audio mode (i.e. 'video' or 'voice', specified through setNativeInCallAudioMode()) would no longer be honored.
  • IMPORTANT: Note that this fix depends on an update to @daily-co/react-native-webrtc. Since it's specified as a peer dependency of react-native-daily-js, you'll need to update your project to depend on its appropriate version. You should get a warning at npm install time about the version you need—heed it!

0.12.0

Bugfixes

• Fixed a bug where the 'active-speaker-change' event wouldn't fire immediately upon join() if it wasn't the first time join() was invoked on the call object (i.e. if you were reusing the same call object for multiple calls).

0.11.0

Bugfixes

• Fixed setNativeInCallAudioMode().

Other improvements

• Synced Daily's react-native-webrtc fork with the upstream version 1.89.2, which contains a more modern M89 build of libwebrtc (we were previously relying on M75). With this update, you can make release builds on iOS that leverage bitcode (see README for details). Some things to keep in mind:
  • Since @daily-co/react-native-webrtc is specified as a peer dependency of react-native-daily-js, you'll need to update your project to depend on the appropriate version. You should get a warning at npm install time about the version you need—heed it.
  • iOS 10 and below are no longer supported starting with this version.
  • Use of the Chrome debugger is no longer supported due to a change (Android, iOS) in the upstream react-native-webrtc. We recommend instead using the Safari debugger for debugging JavaScript on iOS.

0.10.0

Features

• A new 'lang-updated' event fires when setDailyLang() is called and changes the call language. The payload includes two values: lang and langSetting. lang is the language currently in effect. langSetting is the value the user explicitly specified (e.g. via setDailyLang()) that resulted in that language ultimately being set. For example, if you call setDailyLang('en'), both your lang and your langSetting will be 'en'. If you call setDailyLang('th'), where 'th' is an as-yet-unsupported language, then langSetting will be 'th' and lang will be 'en', the fallback language chosen.
• A new getMeetingSession() method returns the current meeting session id. A meeting session is a set of one or more people in a room together during a specific time window.
• A new 'meeting-session-updated' event fires when your meeting session changes. One meeting session ends and another begins, for example, when you've been sitting alone in a room for 10 minutes (cricket, cricket).

Bugfixes

• Squashed a bug where if you invoked two or more async methods (like room() or requestAccess(), etc.) within the same millisecond, some of those methods might never have resolved.

0.9.0

Improvements

• 'error' event payloads now include an optional error field in addition to the existing errorMsg field. This new error field includes a type (which you can think of as an error code but a string constant) and an optional localizedMsg, which can provide you with a localized UI-friendly message describing the error. Note that not all kinds of errors have an error field yet—see index.d.ts's DailyFatalErrorType for supported error types so far—but the eventual goal is that you'll be able to stop relying on errorMsg in your code to identify errors.
• The preAuth() method will now put the meeting into an 'error' state (meetingState() === 'error') if it determines that a provided join token is expired or not yet valid or if the room is expired or not yet valid, and will fire a corresponding 'error' event. This behavior better matches join()'s behavior.

0.8.0

Features

• (BETA) There's a new set of room access control APIs geared towards implementing flows like a "lobby" where users can request full access to a meeting and wait for a meeting owner to let them in—behavior that previously only existed in the prebuilt UI on the web. Briefly, these new methods and events let you:

  • Know your access level, even before attempting to join a meeting (preAuth(), accessState(), 'access-state-updated')
  • Request elevated access to a meeting (requestAccess())
  • Manage pending access requests, if you're a meeting owner (waitingParticipants(), updateWaitingParticipant(), updateWaitingParticipants(), 'waiting-participant-added', 'waiting-participant-updated', 'waiting-participant-removed')

  You can read more about our new API methods and events in our reference docs. Make sure to check out the privacy and enable_knocking room flags!

• participants()[id].tracks.audio.off and participants()[id].tracks.video.off may now include byRemoteRequest: true when a participant is explicitly muted by a meeting owner invoking updateParticipant(id, { setAudio: false }) or updateParticipant(id, { setVideo: false }) or the updateParticipants()(plural) equivalent calls. Note that when byRemoteRequest: true is set, byUser: true will also be set, so that you don't have to change any existing code and can continue treating meeting-owner-triggered mutes as regular mutes. When a user unmutes themselves, byRemoteRequest disappears along with byUser.