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.

0.7.1

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

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

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*.*

0.5.0

Features

• The DailyParticipant type—the one populating the participants() dictionary as well as participant event payloads—now contains more detailed track state in a new tracks property, enabling you to build more expressive call UI. See below for the shape of this new property. For a more detailed description, check out our reference docs. For an example of how to use these new properties, check out our React demo app.

tracks: {
  audio: {
    subscribed: boolean;
    state:
      | 'blocked'
      | 'off'
      | 'sendable'
      | 'loading'
      | 'interrupted'
      | 'playable';
    blocked?: {
      byDeviceMissing?: boolean;
      byPermissions?: boolean;
    };
    off?: {
      byUser?: boolean;
      byBandwidth?: boolean;
    };
    track?: MediaStreamTrack;
  };
  video: { /* same */ };
  screenAudio: { /* same */ };
  screenVideo: { /* same */ };
}

Other improvements

• TypeScript declaration fixes for track-started and track-stopped events.
• TypeScript declaration update to add screenAudio subscription option.

0.4.0

Features

Four methods that were previously web-only are now enabled in React Native:
* updateParticipant()
* updateParticipants()
* setSubscribeToTracksAutomatically()
* subscribeToTracksAutomatically()

0.3.0

Features

• The Daily dashboard now shows metrics and logs for calls made using React Native! This react-native-daily-js release makes the dashboard even more useful for RN calls by sending up a bit more information about the clients, such as RN version, device model, and OS name and version.

0.2.0

Features

• cycleCamera() returns a Promise that resolves to { device: { facingMode: DailyCameraFacingMode } | null }, where DailyCameraFacingMode is either ”user” or “environment”.
• A new method getCameraFacingMode() returns a Promise that resolves to ”user”, ”environment”, or null. Together with the new cycleCamera() behavior, this method should help you build UI that appropriately accounts for whether a front- or rear-facing camera is being used.

Improvements

• Various README updates.

0.1.0

First release of react-native-daily-js, the Daily JavaScript library for React Native and the native counterpart to daily-js.

Features

• A subset of the methods and events in daily-js needed for adding basic video call functionality to your app, including (but not limited to):
  • Joining and leaving meetings
  • Staying informed about participants in the meeting
  • Playing participant video and audio tracks
  • Controlling your cam and mic (muting devices, flipping the camera)
  • Getting network stats
• Configuration of the Android ongoing call notification