Skip to content

Releases: daily-co/react-native-daily-js

0.13.0

28 Jul 21:57
Compare
Choose a tag to compare

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

16 Jul 15:42
Compare
Choose a tag to compare

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

06 Jul 22:30
Compare
Choose a tag to compare

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

27 May 19:53
Compare
Choose a tag to compare

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 (AndroidiOS) in the upstream react-native-webrtc. We recommend instead using the Safari debugger for debugging JavaScript on iOS.

0.10.0

12 May 20:44
Compare
Choose a tag to compare

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

19 Apr 22:20
Compare
Choose a tag to compare

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

05 Apr 19:01
Compare
Choose a tag to compare

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.

0.7.1

26 Feb 14:36
Compare
Choose a tag to compare

Bugfixes

  • Adds TypeScript declarations for recording-started and recording-stopped events, and the record field in the DailyParticipant object. See 0.7.0 release notes for a description of the new recording-related changes.

0.7.0

26 Feb 02:02
Compare
Choose a tag to compare

Features

  • A new method setUserName() allows you to programmatically set the user name that other participants see through the user_name property in the DailyParticipant object corresponding to you.
  • recording-started and recording-stopped events now fire for all participants—not just the recorder—when someone starts recording the meeting. Additionally, DailyParticipant objects (the ones returned by participants()) have a new record field that indicates whether the participant is recording.

0.6.0

08 Feb 16:44
Compare
Choose a tag to compare

Features

  • You can now update all participants at once using the * key in the updateParticipants() method. Example: callObject.updateParticipants({'*': {setSubscribedTracks: true}});.
  • The room() method returns a more complete set of config properties describing the room you're currently in, as well as domainConfig properties describing the room's domain. This new set of properties includes explicitly-set properties as well as default ones. To see only default properties, pass in a new {includeRoomConfigDefaults: false} argument.

Bugfixes

  • Improved track subscription performance and fixed race conditions when updating multiple tracks. When changing subscriptions for multiple participants, it is highly recommended to use the updateParticipants() (plural) call over multiple calls to updateParticipant() in order to batch updates and expedite subscription changes. Also—as described in "Features", above—you can now update all participants at once using the * key in the updateParticipants() method*.*