DEV Community: Arpit Mishra

Map the Force Within You: Fastest Route and ETA for Rebels!

Arpit Mishra — Wed, 04 May 2022 11:48:50 +0000

Support us on Product Hunt - https://www.producthunt.com/posts/map-the-force

Calling all rebel pilots to New York! We’re under attack by the forces of the Empire. I repeat, we’re under attack and we need all hands on deck! NOW!
Join up with your allies of the resistance at your nearest base, select your aircraft type and report to the New York base as fast as you can.
Before you jump into your aircraft, load up your NextBillion.ai routing tools, enter your vehicle type and just follow the fastest route shown on your cockpit console display.
The resistance needs you here … NOW!

The mission

The distress message was clear to all rebel pilots –- reinforcements need to reach the rebel base in New York as quickly as possible. A fraction of a second’s delay could be enough for the opposition to gain an advantage and shift the momentum of the war.

But even in the darkest hour, there’s always a faint glimmer of hope that shines through. That glimmer of hope rests on finding the fastest and safest route to the New York base, while also avoiding detection by the Imperial Forces.

https://www.youtube.com/watch?v=DHtQf_LMeqk

Rebel pilots cannot take to the open skies, as the Imperial Forces have their radar systems scanning all possible air routes to New York. Instead, they need to fly as low as possible. Therefore, it is highly imperative to find the most optimized route that supports their aircraft's stealth movement.

Choose your route wisely

The force is strong with the Resistance, young pilot! It’s essential for you to cover ground and reach the New York base as fast as you can. For that, you’ll need to rely on your trusty NextBillion.ai routing tool. With accurate and optimized paths for any type of aircraft, this handy routing tool will fast track your journey and highlight the path of least risk and danger.

The rebel fleet

On reporting to your nearest base station, you can choose from the following aircraft types. Please bear in mind that smaller aircraft may not have advanced or heavy weapons systems in place, but they can move faster than larger aircraft. Hence, optimized routes for a lighter aircraft may not be the same as that of a larger aircraft type.

TIE Fighter

The classic TIE Fighter is the standard Imperial starfighter that’s seen in huge numbers throughout the galactic civil war. With a slim frame build, the TIE Fighter is nimble enough to navigate through narrow roads and shortcuts.

X-wing

The X-Wing is renowned for its ‘almost perfect’ balance of speed, maneuverability and defensive shielding, making it the ship of choice for the rebel alliance. While it’s not as fast and nimble as the TIE fighter, it has more room for cargo and firepower.

Millenium Falcon

The fastest and the sleekest starship used by smugglers across the galaxy. Its aged appearance belies numerous advanced modifications to boost the ship’s speed, weaponry and defense mechanisms.

Slave-1

Slave 1 is a well-armed starship. Its weaponry includes two heavy twin blaster cannons, as well as two rapid-firing laser cannons. Rounding out the ship’s armaments are two projectile launchers, each holding a magazine of three homing missiles, and a naval minelayer equipped with seismic charges.

Delta 7 Starfighter

The Delta 7 was designed with a focus on agility. An elite transport, it can accommodate a single pilot and an integrated astromech droid. Unlike most ships, the Delta 7 doesn’t feature a built-in hyperdrive but relies on external hyperspace transport rings that attach to the starship.

Ready to deploy?
Now that you’ve been briefed, it’s time to get you on your way to the New York base! Let’s get you started by clicking on the link below:

The interactive ‘Map the Force’ experience is here.

May the fourth be with you!

Check out - https://nextbillion.ai/ to create more such amazing products!
**

AMA & Talk: Scaling your Android build with Jetpack & Dagger

Arpit Mishra — Fri, 18 Feb 2022 06:19:37 +0000

Guess who just joined the club. 👋

100ms is conducting its first 🤖 Android Developer event, and we’re here to talk about all things development, coding, and scaling.

Join us for an exclusive Talk & AMA session with Rivu Chakraborty, Aniket Kadam, and Honey Sonwani on 🗓 26th of February! We will be unlocking elements to scale the Android system by deep-diving into Dagger and Jetpack compose.

💡 Going live on 26th February at 11:00 am IST. Don’t miss this!

https://www.100ms.live/events/android-jetpack-dagger

GDG #askmeanything #Android #jetpackcompose

Building a Twitter Spaces clone in React Native

Arpit Mishra — Fri, 10 Dec 2021 09:20:34 +0000

In the mood to learn something new over the weekend?🧑‍💻

100ms 🤝 GeekyAnts

Join speaker 🎙 Vipul Bhardwaj, Senior Engineer at #NativeBase, for a webinar 🎥 with #100ms on how to build a Twitter Spaces clone with #React Native.

What would you learn?

What is NativeBase and how to build consistent UI with it
What is Twitter Spaces and how does it work
How to build Twitter Spaces with 100ms React Native SDK

Sounds exciting? then register now 👇
Tune in on 🗓 18th December

https://www.100ms.live/events/twitter-spaces-clone

[ 🎥 Workshop] Building a Zoom clone in Flutter

Arpit Mishra — Wed, 24 Nov 2021 07:12:40 +0000

Read detailed blog on the workshop - Building Zoom clone in Flutter

We can't keep calm #100ms is back with another exciting workshop.🤩

Build a Zoom clone in Flutter with Vivek Yadav (Google Developer Expert in Flutter, Building Mobile at ZestMoney) on 2nd December at 10:00 AM ET | 8:30 PM IST.

In this #workshop,
☝️ Understand how Zoom works
🤘 Integrate the 100ms Flutter SDK
🖖 Build features like mute/unmute, leave/join room & messaging.

Excited? Register here: 👇

https://community.100ms.live/zoom-clone-flutter

Build a Discord stage channel clone with 100ms and Next.js

Arpit Mishra — Tue, 16 Nov 2021 07:26:30 +0000

Ever since the Clubhouse app rose to fame, the popularity of drop-in audio-only rooms has been increasing sharply and adopted by several platforms such as Slack, Twitter, and Discord. These rooms are great for hosting Q&A sessions, panel discussions, and a lot more.

This content was originally published - HERE

Earlier this year, Discord introduced Stages, an audio-only channel to engage with your Discord community with separation between speakers and audience. In this blog, we’ll learn how to build a similar platform painlessly with 100ms.

What We’ll Be Building

Using the 100ms React SDK, we’ll build our custom audio room application that will mimic these features from Discord

Stages:

Allow the user to join as a speaker, listener, or a moderator.
Speakers and moderators will have the permission to mute or unmute themselves.

Listeners will only be able to listen to the conversation, raise their hand to become a speaker, or leave the room.
Moderators will be allowed to mute anyone and change the role of a person to speaker or listener.

By the end of this blog, you can expect to build an application like this with Next.js (a React framework) and 100ms SDK:

The only prerequisites for building this project is a fundamental understanding of Next.js and React hooks. The Next.js documentation is a great place to start reading about how Next.js works, but you can still follow along if you’ve only used React in the past.

Familiarity with Flux-based architecture is a bonus but not a necessity, and no prior knowledge of WebRTC is required. How wonderful is that!

Setting up the Project

Before diving right into the code, create a 100ms account from the 100ms Dashboard to get your token_endpoint and room_id. We’ll be needing these credentials in the later stages of building the application.

Once you’ve created an account, follow the steps given below to create your application and set it up on the 100ms dashboard:

Defining Roles

We’ll be having four roles in our application: listener, speaker, handraise, and moderator. Let’s set up permissions for each of these roles, starting with the listener role.

For the listener role, we can turn off all the publish strategies as we don’t want listeners to share their audio, video, or screen. Listeners will still be able to listen to others’ audio.

Inside the permissions section, uncheck all the options except for Can change any participant's role permission.

For the handraise role, we can again turn off all the publish strategies and just keep the Can change any participant's role permission turned on. This permission will allow us to switch the user from listener role to handraise role, and vice-versa, and help us to to implement the hand-raise functionality.

When a listener wants to become a speaker, they can click on the hand-raise button that will change their role to handraise. When the user's role is handraise, we'll display a small badge next to their avatar to notify the moderator.

Now for the speaker role, since we’re building an audio-only room, we can just check the Can share audio publish strategy and leave the rest of them unchecked. We can leave all the permissions turned off for the speaker role.

Finally, for the moderator role, we can check the Can share audio publish strategy and move on towards the permissions. In the permissions section, turn on the Can change any participant's role permission and the Can mute any participant permission.

For all the roles, set the subscribe strategies to speaker and moderator. And with that, we’re ready to move on and get the required credentials from the 100ms Dashboard.

Getting the token_enpoint

Once you’re done creating your custom application and setting up the roles, head on over to the Developers tab to get your token endpoint URL. Keep this URL handy. We’ll store this URL inside an environment variable shortly in the upcoming sections.

Getting the `room_id`

To obtain the room ID, head on over the Rooms tab on 100ms Dashboard. If you don’t have an existing room, you can go ahead and create one to get its ID. Otherwise, copy the room ID of an existing room and paste it somewhere for now.

Understanding the Terminologies

I know you’re excited to start coding, but let’s take a moment to understand the key terminologies associated with the 100ms SDK so that we’re on the same page.

Room — A room is the basic object that 100ms SDKs return on successful connection. This contains references to peers, tracks and everything you need to render a live audio/video app.

Peer — A peer is the object returned by 100ms SDKs that contains all information about a user — name, role, video track etc.

Track — A track represents either the audio or video that a peer is publishing.

Role — A role defines who a peer can see/hear, the quality at which they publish their video, whether they have permissions to publish video/screenshare, mute someone, change someone’s role.

An Overview of the Starter Code

To ease the development process, you can grab the starter code with prebuilt components and styling by cloning the template branch of this repo with this command:

git clone -b template https://github.com/itsnitinr/discord-stages-clone-100ms.git

This starter code is built using the Create Next App CLI tool with the Tailwind CSS template. All the dependencies required for this building this project, such as the @100mslive/hms-video and @100mslive/hms-video-react SDK have already been added to the package.json file.

Therefore, make sure to run npm install or yarn install to install these dependencies locally before moving forward.

Remember the token endpoint URL and room ID we had saved earlier? It’s time to transfer them to an environment variable file. The starter code comes with an .env.local.example file.

cp .env.local.example .env.local

Run this command to copy this example env file and create an actual one:
Now, add the token endpoint URL and room ID to this .env.local file:

// .env.local
TOKEN_ENDPOINT = <YOUR-TOKEN-ENDPOINT-URL>
ROOM_ID = <YOUR-ROOM-ID>

To start the Next.js development server, run the dev script in this manner:

npm run dev
#or
yarn dev

Visit http://localhost:3000 on your browser and you’ll be greeted with this screen if everything goes well:

Fantastic! Let’s start implementing the features one by one in the upcoming sections.

Building the project

Before we can start using the hooks, selectors, or store from the 100ms React SDK, we will need to wrap our entire application with <HMSRoomProvider /> component from the @100mslive/hms-video-react package.

Here’s how your code should look like once you’ve completed this step:

// pages/index.js

import { HMSRoomProvider } from '@100mslive/hms-video-react';
import Head from 'next/head';

import Join from '../components/Join';
import Room from '../components/Room';

const StagesApp = () => {
  const isConnected = false;
  return isConnected ? <Room /> : <Join />;
};

const App = () => {
  return (
    <HMSRoomProvider>
      <Head>
        <title>Discord Stages Clone</title>
      </Head>
      <StagesApp />
    </HMSRoomProvider>
  );
};

export default App;

Joining a Room

Right now, we’re conditionally rendering either the <Room /> component or the <Join /> component based on the isConnected variable. However, its value has been hardcoded to be false for now.

To check if the user is connected to a room or not, we can use the selectIsConnectedToRoom selector and useHMSStore hook like this:

// pages/index.js

import { HMSRoomProvider,
  useHMSStore,
  selectIsConnectedToRoom,
} from '@100mslive/hms-video-react';
import Head from 'next/head';

import Join from '../components/Join';
import Room from '../components/Room';

const StagesApp = () => {
  const isConnected = useHMSStore(selectIsConnectedToRoom);
  return isConnected ? <Room /> : <Join />;
};

const App = () => {
  return (
    <HMSRoomProvider>
      <Head>
        <title>Discord Stages Clone</title>
      </Head>
      <StagesApp />
    </HMSRoomProvider>
  );
};

export default App;

By default, the user will not be connected to any room, and hence, the <Join /> component will be rendered. Let’s implement the functionality to join a room inside the components/Join.jsx file.

To join a room, we can use the join() method on the hmsActions object returned by the useHMSActions() hook.

This join() method takes an object containing the userName, authToken and an optional settings object as the parameter.

We can get the userName from the local name state variable created using the useState() hook from React. However, to obtain the authToken, we will need to make a network request to our custom Next.js API route along with the role we want to join the room with.

We’re also tracking the role the user has selected using the local role state variable, similar to name.

You can find the API route inside the pages/api/token.js file. Here’s how it will look like:

// pages/api/token.js

import { v4 } from 'uuid';

export default async function getAuthToken(req, res) {
  try {
    const { role } = JSON.parse(req.body);

    const response = await fetch(`${process.env.TOKEN_ENDPOINT}api/token`, {
      method: 'POST',
      body: JSON.stringify({
        user_id: v4(),
        room_id: process.env.ROOM_ID,
        role,
      }),
    });

    const { token } = await response.json();
    res.status(200).json({ token });
  } catch (error) {
    console.log('error', error);
    res.status(500).json({ error });
  }
}

Essentially, this API route makes a POST request to our 100ms token endpoint URL, which is stored inside the environment variables, along with a unique user_id, role, and the room_id, which is also stored inside the environment variables.

If successful, our Next.js API route will return the authToken. Using this authToken, we can join the room. Since we don’t want the user to join with their mic turned on, we can set isAudioMuted to true inside the optional settings object.

// components/Join.jsx

import Image from 'next/image';
import { useState } from 'react';
import Avatar from 'boring-avatars';
import { useHMSActions } from '@100mslive/hms-video-react';

import NameInput from './Join/NameInput';
import RoleSelect from './Join/RoleSelect';
import JoinButton from './Join/JoinButton';

const Join = () => {
  const hmsActions = useHMSActions();

  const [name, setName] = useState('');
  const [role, setRole] = useState('listener');

  const joinRoom = async () => {
    try {
      const response = await fetch('/api/token', {
        method: 'POST',
        body: JSON.stringify({ role }),
      });
      const { token } = await response.json();
      hmsActions.join({
        userName: name || 'Anonymous',
        authToken: token,
        settings: {
          isAudioMuted: true,
        },
      });
    } catch (error) {
      console.error(error);
    }
  };

  return (
    <>
      <Image
        src="https://imgur.com/27iLD4R.png"
        alt="Login background"
        className="w-screen h-screen object-cover relative"
        layout="fill"
      />
      <div className="bg-gray-800 rounded-lg w-11/12 md:w-1/2 lg:w-1/3 absolute top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2 p-8 text-white shadow-lg space-y-4 flex flex-col items-center max-w-md">
        <Avatar name={name} variant="marble" size="72" />
        <NameInput name={name} setName={setName} />
        <RoleSelect role={role} setRole={setRole} />
        <JoinButton joinRoom={joinRoom} />
      </div>
    </>
  );
};

export default Join;

And with just a few lines of code, we have implemented the functionality to join a room and render the <Room /> component. Now, let’s move forward and render the peers connected to our room.

Rendering The Peers

Right now, if you view the <Room /> component inside the components/Room.jsx file, you can see that we have hardcoded the value of peers to an empty array.Let’s make this dynamic.

To do that, we can use the selectPeers selector combined with the useHMSStore() hook to get an array of all the peers connected to the room in the form of objects. Each of these peer objects will contain information such as their name and roleName that we can use to render their tiles accordingly.

Once we get an array of all the peers, we can use the filter() JavaScript array method to separate them into listenersAndHandraised and speakersAndModerators using the roleName property on each peer object. This will help us render the appropriate tile based on the user’s role.

If the role of the user is a listener or handraise, we will render the <ListenerTile /> component. Else, we will render the <SpeakerTile /> component. While rendering these tiles, pass the peer object as a prop in order to display the peer’s information inside the tiles.

// components/Room.jsx

import { selectPeers, useHMSStore } from '@100mslive/hms-video-react';

import RoomInfo from './Room/RoomInfo';
import Controls from './Room/Controls';
import ListenerTile from './User/ListenerTile';
import SpeakerTile from './User/SpeakerTile';

const Room = () => {
  const peers = useHMSStore(selectPeers);

  const speakersAndModerators = peers.filter(
    (peer) => peer.roleName === 'speaker' || peer.roleName === 'moderator'
  );
  const listenersAndHandraised = peers.filter(
    (peer) => peer.roleName === 'listener' || peer.roleName === 'handraise'
  );

  return (
    <div className="flex flex-col bg-main text-white min-h-screen p-6">
      <RoomInfo count={peers.length} />
      <div className="flex-1 py-8">
        <h5 className="uppercase text-sm text-gray-300 font-bold mb-8">
          Speakers - {speakersAndModerators.length}
        </h5>
        <div className="flex space-x-6 flex-wrap">
          {speakersAndModerators.map((speaker) => (
            <SpeakerTile key={speaker.id} peer={speaker} />
          ))}
        </div>
        <h5 className="uppercase text-sm text-gray-300 font-bold my-8">
          Listeners - {listenersAndHandraised.length}
        </h5>
        <div className="flex space-x-8 flex-wrap">
          {listenersAndHandraised.map((listener) => (
            <ListenerTile key={listener.id} peer={listener} />
          ))}
        </div>
      </div>
      <Controls />
    </div>
  );
};

export default Room;

The <RoomInfo /> component takes a count prop with the total number of peers connected to the rooms as its value. For the speakers and listeners headings, we can access the length property of speakersAndModerators and listenersAndHandraised array, respectively, to get their count.

Adding Functionalities To The Controls

Let’s go to the <Controls /> component inside components/Room/Controls.jsx. Essentially, we will be having three controls: one to toggle our mic on or off, one to toggle hand-raise, and lastly to leave the room. We'll cover the hand-raise functionality in the latter part of this blog post.

The <MicButton /> component responsible for the toggle mic functionality will only be displayed to the speakers and moderators whereas, the <ExitButton /> component will be displayed to all roles.

We need to check if our role and if our mic is turned on or not to render the buttons accordingly. To do this, use the selectIsLocalAudioEnabled selector to get the status of our mic, and the selectLocalPeer selector to get our local peer object.

// components/Room/Controls.jsx

import {
  useHMSStore,
  selectIsLocalAudioEnabled,
  selectLocalPeer,
} from '@100mslive/hms-video-react';

import MicButton from './MicButton';
import ExitButton from './ExitButton';
import HandRaiseButton from './HandRaiseButton';

const Controls = () => {
  const isMicOn = useHMSStore(selectIsLocalAudioEnabled);
  const peer = useHMSStore(selectLocalPeer);

  const isListenerOrHandraised =
    peer.roleName === 'listener' || peer.roleName === 'handraise';

  return (
    <div className="flex justify-center space-x-4">
      {!isListenerOrHandraised && (
        <MicButton isMicOn={isMicOn} toggleMic={() => {}} />
      )}
      {isListenerOrHandraised && (
        <HandRaiseButton
          isHandRaised={peer.roleName === 'handraise'}
          toggleHandRaise={() => {}}
        />
      )}
      <ExitButton exitRoom={() => {}} />
    </div>
  );
};

export default Controls;

Now, to add the functionalities, start by creating a new instance of the useHMSActions() hook and store it inside hmsActions.

Call the setLocalAudioEnabled() method on the hmsActions object inside the toggleMic prop of the <MicButton /> component.

This method takes a boolean value: true for turning on the mic and false for turning it off. Since we want to toggle, we can pass the opposite of current status using the ! operator.

To exit the room, we can simply call the leave() method on the hmsActions object.

// components/Room/Controls.jsx

import {
  useHMSStore,
  useHMSActions,
  selectIsLocalAudioEnabled,
  selectLocalPeer,
} from '@100mslive/hms-video-react';

import MicButton from './MicButton';
import ExitButton from './ExitButton';
import HandRaiseButton from './HandRaiseButton';

const Controls = () => {
  const hmsActions = useHMSActions();
  const isMicOn = useHMSStore(selectIsLocalAudioEnabled);
  const peer = useHMSStore(selectLocalPeer);

  const isListenerOrHandraised =
    peer.roleName === 'listener' || peer.roleName === 'handraise';

  return (
    <div className="flex justify-center space-x-4">
      {!isListenerOrHandraised && (
        <MicButton
          isMicOn={isMicOn}
          toggleMic={() => hmsActions.setLocalAudioEnabled(!isMicOn)}
        />
      )}
      {isListenerOrHandraised && (
        <HandRaiseButton
          isHandRaised={peer.roleName === 'handraise'}
          toggleHandRaise={() => {}}
        />
      )}
      <ExitButton exitRoom={() => hmsActions.leave()} />
    </div>
  );
};

export default Controls;

Displaying Audio Level and Mic Status

When a user is speaking, we want to display a green ring just outside the user’s avatar to indicate the same. This will require us to know the audio level of the speaker, but how can we find that out? With 100ms React SDK, it is as simple as using the selectPeerAudioByID selector.

This selector function takes the peer’s ID as the parameter and returns an integer to represent the audio level. We can assign it to a variable and check if it is greater than 0 to check if the user is speaking.

Similarly, to check if a user’s mic is turned on or not, we can use the selectIsPeerAudioEnabled selector, which also takes the peer’s ID as the parameter and returns a boolean value to indicate the mic status.

Using these two selectors, we can render the UI accordingly by adding a ring using Tailwind CSS classes and displaying the appropriate icon. Go to the <SpeakerTile /> component inside components/User/SpeakerTile.jsx and make the following changes:

// components/User/SpeakerTile.jsx

import Avatar from 'boring-avatars';
import { FiMic, FiMicOff } from 'react-icons/fi';
import {
  useHMSStore,
  selectPeerAudioByID,
  selectIsPeerAudioEnabled,
} from '@100mslive/hms-video-react';

import PermissionsMenu from './PermissionsMenu';

const SpeakerTile = ({ peer }) => {
  const isSpeaking = useHMSStore(selectPeerAudioByID(peer.id)) > 0;
  const isMicOn = useHMSStore(selectIsPeerAudioEnabled(peer.id));

  return (
    <div className="relative bg-secondary px-12 py-6 rounded-lg border border-purple-500">
      <PermissionsMenu id={peer.id} audioTrack={peer.audioTrack} />
      <div className="flex flex-col gap-y-4 justify-center items-center">
        <div
          className={
            isSpeaking
              ? 'ring rounded-full transition ring-3 ring-green-600 p-0.5'
              : 'p-0.5'
          }
        >
          <Avatar name={peer.name} size="60" />
        </div>
        <p className="flex items-center gap-x-2">
          {peer.name}
          {isMicOn ? (
            <FiMic className="h-3 w-3" />
          ) : (
            <FiMicOff className="h-3 w-3" />
          )}
        </p>
      </div>
    </div>
  );
};

export default SpeakerTile;

The Permissions Menu

Time to add some functionality to the <PermissionsMenu /> component inside the components/User/PermissionsMenu.jsx file. We want to display this menu only if we have the moderator role.

To get our localPeer object, we can use the selectLocalPeer selector function. This will return an object with the roleName property that we can check to get our role.

Alternatively, you can also choose to use the selectLocalPeerRole selector and access the name property of the returned object.

To check if we are a moderator, use the === equality operator to check if our roleName equates to moderator.

Accordingly, we can either render this component, or null if we’re not a moderator.

The permissions menu has three options: Mute Peer, Make Listener, and Make Speaker. To achieve these functionalities, create a new instance of the useHMSActions() hook to get access to all the required methods.

For muting a peer, call the setRemoteTrackEnabled() method on hmsActions with the peer’s audio track (that we’re getting from the props) and false as parameters.

To change the role of a peer, call the changeRole() method on hmsActions along with the peer’s ID, new role, and a force boolean value to change their role without asking them or give them a chance to accept/reject.

// components/User/PermissionsMenu.jsx

import { useState } from 'react';
import { AiOutlineMenu } from 'react-icons/ai';
import {
  useHMSStore,
  useHMSActions,
  selectLocalPeer,
} from '@100mslive/hms-video-react';

const PermissionsMenu = ({ audioTrack, id }) => {
  const hmsActions = useHMSActions();

  const mutePeer = () => {
    hmsActions.setRemoteTrackEnabled(audioTrack, false);
  };

  const changeRole = (role) => {
    hmsActions.changeRole(id, role, true);
  };

  const localPeer = useHMSStore(selectLocalPeer);

  const [showMenu, setShowMenu] = useState(false);

  const btnClass = 'w-full text-sm font-semibold hover:text-purple-800 p-1.5';

  const isModerator = localPeer.roleName === 'moderator';

  if (isModerator) {
    return (
      <div className="absolute right-1 top-1 z-50">
        <AiOutlineMenu
          className="ml-auto"
          onClick={() => setShowMenu(!showMenu)}
        />
        {showMenu && (
          <div className="mt-2 bg-white text-black py-2 rounded-md">
            <button className={btnClass} onClick={() => mutePeer()}>
              Mute
            </button>
            <button className={btnClass} onClick={() => changeRole('listener')}>
              Make Listener
            </button>
            <button className={btnClass} onClick={() => changeRole('speaker')}>
              Make Speaker
            </button>
          </div>
        )}
      </div>
    );
  } else {
    return null;
  }
};

export default PermissionsMenu;

Adding Hand-Raise Functionality

Finally, let’s add the last bit of functionality to our application: hand-raise. As a listener, you might also want a chance to become a speaker at times. To notify the moderator, we can build a simple hand-raise button that will display a badge next to your avatar to show that you're interested to speak.

Therefore, start by building the functionality to change our role from listener to handraise on clicking the <HandRaiseButton /> component.

To do this, go back to the <Controls /> component inside components/Room/Controls.jsx.

Over here, you’ll notice the <HandRaiseButton /> component with 2 props: a isHandRaised boolean prop to check if you've raised hand currently and a toggleHandRaise function to toggle it. Also, we'll display this button only if we are a listener or have handraise role.

For the isHandRaised prop, we simply need to get our role by accessing the roleName property of our local peer and check if it equates to the handraise role.

For the toggle functionality, we can use the changeRole() method available on the hmsActions object like we did for the <PermissionsMenu /> component.

This changeRole() method takes our local peer's ID, the new role to set, and a force boolean prop. For the new role, if we are a listener currently, we need to pass handraise as the parameter. If we already have the role of handraise, we need to set it back to listener.

Here’s how your code should look like:

// components/Room/Controls.jsx

import {
  useHMSStore,
  useHMSActions,
  selectIsLocalAudioEnabled,
  selectLocalPeer,
} from '@100mslive/hms-video-react';

import MicButton from './MicButton';
import ExitButton from './ExitButton';
import HandRaiseButton from './HandRaiseButton';

const Controls = () => {
  const hmsActions = useHMSActions();
  const isMicOn = useHMSStore(selectIsLocalAudioEnabled);
  const peer = useHMSStore(selectLocalPeer);

  const isListenerOrHandraised =
    peer.roleName === 'listener' || peer.roleName === 'handraise';

  return (
    <div className="flex justify-center space-x-4">
      {!isListenerOrHandraised && (
        <MicButton
          isMicOn={isMicOn}
          toggleMic={() => hmsActions.setLocalAudoEnabled(!isMicOn)}
        />
      )}
      {isListenerOrHandraised && (
        <HandRaiseButton
          isHandRaised={peer.roleName === 'handraise'}
          toggleHandRaise={() =>
            hmsActions.changeRole(
              peer.id,
              peer.roleName === 'listener' ? 'handraise' : 'listener',
              true
            )
          }
        />
      )}
      <ExitButton exitRoom={() => hmsActions.leave()} />
    </div>
  );
};

export default Controls;

The starter code already contains the code to display a hand-raise badge in the <ListenerTile /> component. Inside this component, we just need to check if the peer's role is set to handraise and then conditionally render the <HandRaiseBadge /> accordingly.

And That’s a Wrap!

Building real-time audio application with 100ms SDK is as simple as that. I hope you enjoyed building this app, and make sure to drop by the 100ms Discord Server in case of any queries.

We can’t wait to see all the marvelous projects you build with 100ms. Till then, happy coding!

Check 100ms Now -> https://www.100ms.live/blog/build-discord-stage-channel-clone-hms

Android SurfaceViewRenderer explained

Arpit Mishra — Tue, 02 Nov 2021 10:25:45 +0000

The mighty SurfaceViewRenderer! It's the very end of a long WebRTC chain that gets video from other people to your screen.

It can also be a bit difficult to use if it's your first time around. Especially in a dynamic android app with a lots of views flicking in and out.

Let's a take a tour through the many ways it can go wrong and what you should know to keep your video conference calls running smoothly.

Here's the lifecycle of a SurfaceViewRenderer:

Which means:

*Once you create the SurfaceViewRenderer, you need to initialise it before it can be used at all. This kicks off a render thread.

*addSink should be called after this. Where is addSink you ask? Well it's not on the SurfaceViewRenderer, it's a method on the VideoTrack you want to add to it.

*removeSink should only be called when you're done showing the video and now it's time to either destroy the view (or recycle it), this stops downloading data from the peer's video too. Another function that's only on the VideoTrack, not the SurfaceViewRenderer though it takes the SurfaceViewRenderer as a parameter.

*Finally release so the render thread can stop.

Once released the SurfaceViewRenderer can be inited again and the cycle renews. Now let's look at what happens when any one of these is missed or not called with the right parameters.

1. Initing without a shared EglContext

This one is actually mentioned in the source code of SurfaceViewRenderer, when you call SurfaceViewRenderer.init(context) it must only be with a shared EGL context.

What does that mean? That you call org.webrtc.EglBase.create() once in something like a singleton and then always initialize all the SurfaceViewRenderers with that saved context's eglBaseContext.

If you call create() for each SurfaceView, you'd end up with no errors and no video playing at all. It's easy to get stuck here and wonder why SurfaceViewRenderer is not showing any video when seemingly nothing went wrong.

2. Not releasing before initing

If you don't release after you've removed a video sink, you're going to get the same result as if you initialised twice.

java.lang.IllegalStateException: videoSurfaceViewAlready initialized at org.webrtc.EglRenderer.init(EglRenderer.java:212)

So you've just got to release at the right time.

3. What if you never init at all?

The view just never shows up ¯_(ツ)_/¯
Behind the scenes a render thread was never created and the loop to draw wasn't kicked off so, of course, nothing would show up.

4. Double the addSinks, double vision

Calling addSink on the same SurfaceViewRenderer is a pretty fun bug. You won't realise anything's wrong if you just added all the the videos for people twice, until the order of the videos is changed.

Then you'll see flicker as two different video sources try to play onto the same surface. Both video sources will take race condition turns rendering.

Oh, and you'll keep downloading the video from the source peer if you only called removeSink once when disposing of the view.

Here's an image of what the two video streams look like separately and what happens when addSink for both was called on the same SurfaceViewRenderer.

5. How many SurfaceViewRenderers can you create? What happens beyond?

Without initialising them, you can create a heck of a lot. But there's a limit to how many different initialised SurfaceViewRenderers you can prepare at a time.

The limit varies from device to device, when I'd tried on one modestly powered Nokia 3.4 phone it got up to 30 contexts initialised until it failed with:

E/AndroidRuntime: FATAL EXCEPTION: mainProcess: com.example.myvideocallapp, PID: 532java.lang.RuntimeException: java.lang.RuntimeException: Failed to create EGL context: 0x3003at org.webrtc.EglBase14Impl.createEglContext(EglBase14Impl.java:282)at org.webrtc.EglBase14Impl.(EglBase14Impl.java:78)at org.webrtc.EglBase.createEgl14(EglBase.java:215)at org.webrtc.EglBase.create(EglBase.java:158)

On others, like an Oppo F19 it gets beyond 150 and keep going. Considering that that's the number of videos you're displaying simultaneously, you may not need to get anywhere near that much.

Now let's look at something even tricker than managing a single or a handful of a static number of SurfaceViewRenderers.

Managing the lifecycle within a RecyclerView

As a refresher, the RecyclerView is an essential View on Android that lets you avoid creating expensive view objects when scrolling through a large list.

What's even more expensive than a typical view object? The SurfaceViewRenderer of course.

Let's think about what a RecyclerView does in android.

*It creates a view when a new one is required.

*It keeps a cache of older views that aren't being used right now.

*It may need to render a view in a different place because its order in the layout changed. (In case of a high score board, there may be a rapid change in positions)

How does that compare to the lifecycle of a SurfaceView?

This poses a natural problem because there are multiple things that could cause the view to be changed.

*The position of the view changes. A teacher who's supposed to be shown first, may join after the students.

*The peer representing this video leaves, so has to be removed.

*New people keep joining so new ones have to be made.

*Someone scrolls the list, so no new views are made but they are constantly recycled.

To further complicate matters, someone's video may not have been on at first, so you may just show the person's initials, but later they do turn it on, so now the SurfaceViewRender has to be initialized.

If you're to Android, rebinding views is straightforward, you'd just do that in the AdapterView's bind method but a slightly unconventional approach is required here because anyone's video can go on or off at any time.

So the big question becomes, when do you initialize the video?
You'd quickly see a 'bind' method is insufficient.

What we need here are some lesser known adapter methods:
onViewAttachedToWindow

Called when a new view is added to the window or a cached one is restored.

onViewDetachedFromWindow

Called when a view is removed, we don't know if it's going into cache or out permanently.

Take a look at the PeerViewHolder and the PeerAdapter to see how all the disparate cases are handled. This is the simplest example of how you could manage the tricky SurfaceViewRenderer in an Android RecyclerView.
This is part of the "hello world" demonstration of how the 100ms SDK can be used.

To look into more advanced use cases, take a look at our fully featured sample app

How to build an audio app like Clubhouse for iOS

Arpit Mishra — Mon, 25 Oct 2021 18:10:31 +0000

The face of video/audio communication has changed dramatically due to the global pandemic. As corporations consider video/audio conferencing as an ultimate solution to connect with remote workers/customers, the affinity to provide features has gone up.

Building a feature-rich Video/audio conferencing application isn't that easy, and this is where 100ms comes to the rescue. In this guide, we will be building a Clubhouse clone using 100ms iOS SDK.

Getting Started

Our Clubhouse clone will have the following features:

Audio Call
Raise hand
Move people who raised a hand to speakers and back to the audience

To focus on SDK integration rather than room list management, the app will use a single predefined room.

*Join our upcoming workshop ‘ Build 👋 Clubhouse like app for iOS in 45 minutes’ — https://community.100ms.live/developer-community-meetup-october

Terminology
Room - A room is a primary object that 100ms SDKs return on successful connection. This contains references to peers, tracks, and everything you need to render a live a/v app.

Peer - A peer is an object returned by 100ms SDKs that contains all information about a user - name, role, video track, etc.

Track - A track represents either the audio or video that a peer is publishing

Role - A role defines who a peer can see/hear, the quality they publish their video, whether they have permission to publish video/screen share, mute someone, or change someone's role.

Prerequisites

To follow this tutorial, you must have a basic understanding of the elementary principles of iOS Development, Xcode, Swift.

Setting up Project

To simplify things and help us focus on adding the core functionality, I already created a template project with the main UI for the audio room app ready for the SDK integration.

git clone <https://github.com/100mslive/clubhouse-clone-ios-swift>

Now that you have cloned the repo, you will find two folders inside:

*AudioRoomTemplate - some boilerplate project if you want to go along with this guide step by step

*AudioRoomComplete - if you'd instead explore the finished project.

*Dependencies*

Open AudioRoom.xcodeproj from the AudioRoomTemplate folder. Our first step would be adding 100ms SDK to the project.

For that we will be using Swift package manager. Select "Add Package" from Xcode File menu and use https://github.com/100mslive/100ms-ios-sdk.git as the package url.

Access Credentials

The primary means of authentication for 100ms SDK is a jwt auth token. It is never a good idea to hardcode tokens in your app, so your backend should provide this token.

You might not have a backend set up during prototyping, so 100ms provides a temporary token generation backend for you to try, which should not be used in production. To get a token from the 100ms backend, we need a token endpoint URL and a room id.

To get these credentials, you first need to create an account at 100ms Dashboard. After your account is set up, head over to the Developer Section, and you can find your Token endpoint URL there.

Creating Roles

Before we create a room, we will create a custom app; you can find it here. Click on "Add a new App." When you are asked to choose a template, select "Create your Own".

Now click on “Create Roles” button this will open a modal were we can create our custom roles.

We will be having 4 roles in our application.

*audience - only able to listen to others, can change role to speakerwannabe

*speakerwannabe - same as speaker, will be used to segregate people who raised their hand

*speaker - able to listen and speak

*host - everything that speaker can plus the ability to change other’s role

We will create host role first. Input host into the role name field, leave only "Can share audio" enabled under "Publish Strategies". Under permissions enable "Can change any participant's role" and then click "save".

Proceed to create speaker role which should be identical to host. Now lets create audience and speakerwannabe roles. Disable everything under "Publish Strategies".

Under permissions enable "Can change any participant's role" and then click "save".

Now that our roles are setup we will move on to our next step by clicking ‘Set up App’. You should see your custom app being created.

Creating a Room

In the last step we created our custom app and setup custom roles , in this step we will create a room id.

To create a room head over to Link page in 100ms Dashboard click on “Create Room” make sure to select the Custom App that you created in the last step. Fill out Room Name and click “Create Room”. After creating you will be routed to Room Details were you can find your room id.

Awesome! Now that we have token endpoint and room id we will add it in our app. Open TokenProvider.swift file and insert the values in the Constants struct. It should look like this:

Now we can start building our project.

Joining The Room

The initial screen of the app is the login screen controlled by the The initial screen of the app is the login screen controlled by the MainViewController.

When the user taps the "JOIN ROOM" button, it uses TokenProvider class to fetch the token from the 100ms token backend and then passes it to RoomViewController, which it then presents modally.

Having a token, we can proceed with joining the room. Open RoomViewController.swift file to start. First, you need to add an import for the SDK:

import HMSSDK

The next thing we need to do is to have an instance of the SDK. It serves as an entry point to everything we will be using.

```class RoomViewController: UIViewController {

private let hms: HMSSDK = HMSSDK.build()

...```

Now we are ready to join a room. In the join function stub add following code:

func join() { let config = HMSConfig(userName: name, authToken: token) hms.join(config: config, delegate: self) }

The above code creates a configuration for the join call from the user name and token that we have obtained earlier. The join function will be called fro the viewDidLoad override. With the join call we also provide a delegate that will receive the important updates from the SDK. So lets add conformance to the HMSUpdateListener protocol:

```extension RoomViewController: HMSUpdateListener {

    /// This will be called on a successful JOIN of the room by the user
    /// This is the point where applications can stop showing its loading state
func on(join room: HMSRoom) {

}

    /// This is called when there is a change in any property of the Room
func on(room: HMSRoom, update: HMSRoomUpdate) {

}

/// This will be called whenever there is an update on an existing peer
/// or a new peer got added/existing peer is removed.
/// This callback can be used to keep a track of all the peers in the room
func on(peer: HMSPeer, update: HMSPeerUpdate) {

}

    /// This is called when there are updates on an existing track
/// or a new track got added/existing track is removed
/// This callback can be used to render the video on screen whenever a track gets added
func on(track: HMSTrack, update: HMSTrackUpdate, for peer: HMSPeer) {

}

    /// This will be called when there is an error in the system
/// and SDK could not recover
func on(error: HMSError) {
            // Display an error alert to the user and bail to main screen
    showError(error.localizedDescription) { [weak self] in
        self?.dismiss(animated: true, completion: nil)
    }
}

    /// This is called when there is a new message from any other peer in the room
/// This can be used to implement chat is the room
func on(message: HMSMessage) {

}

    /// This is called every 1 second with list of active speakers
func on(updated speakers: [HMSSpeaker]) {

}

    /// This is called when SDK detects a network issue and is trying to recover
func onReconnecting() {

}

    /// This is called when SDK successfully recovered from a network issue
func onReconnected() {

}

}```

The only thing we are going to handle at this stage is on(error:) which will let us see if something went wrong. Rest can be left as is.

Now when user decides to leave the room we should call leave function. This will let other people know we left. The appropriate place to do that in case of a modally presented controller should be endAppearanceTransition override:

```override func endAppearanceTransition() {
super.endAppearanceTransition()

    if isBeingDismissed {
        UIApplication.shared.isIdleTimerDisabled = false

        hms.leave() // <--- cleanup
    }
 }```

With this in place quite a lot is achieved. You can join the room as host/audience/speaker. Audience will not be able to speak but host/speaker will.

This is done by the SDK automatically publishing/subscribing to tracks based on the roles configuration we made in the beginning.

Showing Peers In The Room

Now that we can join in the room, let's display the peers who have joined the room. To get all peers, we will use hms. room?.peers property. This will return us an array of all peers in the room.

Each peer object stores the details of individual participants in the room. You can refer to the interface of HMSPeer in our API-reference docs.
We will show these peers in a UICollectionView separated into two sections: audience and speakers. The host will also have the ability see peers who have raised a hand in the "Raised hand" section. We need to create a data model for the sections to use in the collection view data source to achieve that. The template project already has a Section class that can hold a list of peers and a type of section and logic to tell which role goes into which section. So let us create our data model in the RoomViewController class:

```class RoomViewController: UIViewController {
...
// Recreates the model from the current peer list provided by the SDK
func reloadModel() {
// Get a list of peers in the room
let peers = hms.room?.peers ?? []
// Create a section of each type to add peers to
let sectionsModel = SectionType.allCases.map { Section(type: $0) }

    for peer in peers {
        // Get section type for this peer based on its role
        let type = Section.sectionType(for: peer.mappedRole, showRaisedHand: isHost)
        // Find the index of this section in the resulting array
        let index = type.rawValue
        // Add the peer to the respective section
        sectionsModel[index].peers.append(peer)
    }

    // Remove empty sections and store the new model
    sections = sectionsModel.filter { !$0.peers.isEmpty }
}

    // Wether current peer is a host
var isHost: Bool {
    localRole == .host
}

    // Map the role of the local peer to one of our known roles. see Role.swift
var localRole: RoleType {
    return hms.localPeer?.mappedRole ?? .unknown
}

// Holds the current model, reloads the collection view on set
private var sections = [Section]() {
    didSet {
        participantsView.reloadData()
    }
}```

Now that we have added logic to build the model we need to wire it up to the SDK updates so that it gets updated when any of these updates happen:

*Room is joined and we get the initial list of peers in the room
*Any peer joins or leaves
*Peer changes its role
*Peer mutes/unmutes (in case he is a speaker/host)

``` func on(join room: HMSRoom) {
reloadModel()
}

func on(peer: HMSPeer, update: HMSPeerUpdate) {
    reloadModel()
}

func on(track: HMSTrack, update: HMSTrackUpdate, for peer: HMSPeer) {
    reloadModel()
}```

With all this in place we can now connect our model to the collection view. The template logic already has a ParticipantCollectionViewCell class that we will use to show our participants.

```extension RoomViewController: UICollectionViewDataSource {
func numberOfSections(in collectionView: UICollectionView) -> Int {
return sections.count
}

func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
    return sections[safe: section]?.peers.count ?? 0
}

func collectionView(_ collectionView: UICollectionView, viewForSupplementaryElementOfKind kind: String, at indexPath: IndexPath) -> UICollectionReusableView {
    guard let section = sections[safe: indexPath.section], kind == UICollectionView.elementKindSectionHeader else {
        return UICollectionReusableView()
    }

    let sectionHeader = collectionView.dequeueReusableSupplementaryView(ofKind: kind, withReuseIdentifier: "header", for: indexPath) as! SectionHeader
    sectionHeader.nameLabel.text = section.sectionDisplayName()
    return sectionHeader
}

func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
    guard let peer = sections[safe: indexPath.section]?.peers[safe: indexPath.item],
          let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "ParticipantCell",
                                              for: indexPath) as? ParticipantCollectionViewCell else {
        return UICollectionViewCell()
    }

    cell.name = peer.name
    cell.isMute = (peer.audioTrack?.isMute() ?? false)

    return cell
}

}

extension RoomViewController: UICollectionViewDelegateFlowLayout {
func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, referenceSizeForHeaderInSection section: Int) -> CGSize {
guard let section = sections[safe: section], section.type != .speakers else {
return .zero
}

    return CGSize(width: collectionView.frame.width, height: 30)
}

And now we are able to see who is in the room, wether they belong to audience or speakers and their mic mute status.

Showing Active Speakers

Another must have feature of an audio room app is showing who is currently speaking. This is quite easy to add. First create a storage for the active speaker ids:

private var speakers = Set<String>() { didSet { participantsView.reloadData() } }``

Then populate it from on(updated:) callback
func on(updated speakers: [HMSSpeaker]) { self.speakers = Set(speakers.map { $0.peer.peerID }) }

Now in the cell configuration add this:
func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { ... cell.isSpeaking = speakers.contains(peer.peerID) ...

And we are done! The speaker will now be marked by a blue glow.

Mute/Unmute

Now let's add a mic mute button. First we need a helper function to tell us if we can speak:

private var canSpeak: Bool { switch localRole { case .host, .speaker: return true default: return false } }

Then we will add a function to setup buttons visibility according to role:
`private func setupButtonStates() {
muteButton.isHidden = !canSpeak
}'

This should be called in on(join:) because at that time we will know what role we joined as:
`func on(join room: HMSRoom) {
reloadModel()
setupButtonStates()
}'

Finally add a mute button tap handler:

@IBAction func muteTapped(_ sender: Any) { muteButton.isSelected = !muteButton.isSelected hms.localPeer?.localAudioTrack()?.setMute(muteButton.isSelected) reloadModel() }

The code above queries local peer for its audio track and then sets its mute status. Then reloads model so that our cell can reflect the change. Now joining as a host you will see the mute button. While joining as audience you will see none.

Raise Hand

What makes audio rooms fun is that anyone can become a speaker at some point. To show interest in becoming a speaker we will add a raise hand button. The UI is already in place we just need to unhide it according to role just like with mute button.

private func setupButtonStates() { ... raiseHandButton.isHidden = canSpeak }

Now in the button tap handler we will use changeRole api to change our own role to speakerwannabe so that the host can see us:

```@IBAction func raiseHandTapped(_ sender: UIButton) {
guard let peer = hms.localPeer else {
return
}
sender.isSelected = !sender.isSelected
sender.tintColor = sender.isSelected ? .red : .white

            // If hand is already raised move ourselves back to audience
    let role = sender.isSelected ? Role.audience : Role.speakerwannabe

    change(peer: peer, to: role)

}

func change(peer: HMSPeer, to role: Role) {
// Get a reference to HMSRole instance for required role
guard let newRole = hms.roles.first(where: { $0.name == role.rawValue }) else {
return
}

            // The force flag is used by the backend to decide wether peer 
    // should be changed immediately or promted to change instead.
    hms.changeRole(for: peer, to: newRole, force: true)

}```

Now as a host we should be able to move people who raised hand to speakers, as well as move speakers back to audience. Lets do that by adding showing an action sheet when cell has been tapped:

func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
        guard let peer = sections[safe: indexPath.section]?.peers[safe: indexPath.item], isHost else {
            return}
        let action: UIAlertAction
        switch peer.mappedRole {
        case .speakerwannabe:
            action = changeRoleAction(peer: peer, role: .speaker, title: "Move to speakers")
        case .speaker:
            action = changeRoleAction(peer: peer, role: .audience, title: "Move to audience")
        default:
            return
        }
        let alertController = UIAlertController(title: "",
                                                message: "Select action",
                                                preferredStyle: .actionSheet)
        alertController.addAction(UIAlertAction(title: "Cancel", style: .cancel))
        alertController.addAction(action)
        present(alertController, animated: true)}
    func changeRoleAction(peer: HMSPeer, role: Role, title: String) -> UIAlertAction {
        UIAlertAction(title: title, style: .default) { [weak self] _ in
           self?.change(peer: peer, to: role)}}

And we are done. Launch the app and try for yourself!

⚔️ Open Source v/s cPaaS ⚔️ - The architecture choices for building a live video applications.

Arpit Mishra — Mon, 18 Oct 2021 18:24:41 +0000

Join Kshitij Gupta, Co-founder & CEO at #100ms along with Sean DuBois, founder of #Pion, Developer at Twitch talk about #WebRTC at upcoming #CTOTalk, October session! 🚀

Agenda -> Open Source v/s cPaaS - The architecture choices for building a live video applications.

Watch as the top minds in the space of live video systems answer queries about -

👉 How live video applications work and why are they hard to build
👉 Architecture choices for building live video applications
👉 How to scale live video systems in production and war stories
👉 How to grow an open source project

Block your seats now ⬇️

Date : 9 AM - 11 AM IST Saturday, 23rd October

Register here : https://bit.ly/ctotalk-opensource

Building highly scalable real-time video applications with WebRTC

Arpit Mishra — Mon, 18 Oct 2021 11:04:36 +0000

Join Kshitij Gupta - CEO and Co-Founder at 100ms and Sean DuBois - Developer Twitch, Creator Pion at CTOtalks session -

Title - Building highly scalable production-ready real-time video applications with WebRTC

When: 9 AM - 11 AM IST Saturday, 23rd October

Join Here - https://bit.ly/ctotalk-opensource

The session will delve into the details of architecture and open-source choices for live video systems and how to run them in production.

Agenda

➡️ How do live video applications work, and why is it hard to build
➡️ Overview of WebRTC (Deep dive on one interesting WebRTC concept)
➡️ Making life simpler for developers
➡️ How to run WebRTC systems in production

See you on 23rd with a power-packed session!

Register for FREE now - https://bit.ly/ctotalk-opensource

Build Clubhouse 👋 like app for iOS

Arpit Mishra — Mon, 11 Oct 2021 12:38:38 +0000

Join 100ms October developer meet-up where we cover - Building a Audio app like Clubhouse for iOS using 100ms SDK on October 13th, 2021 | 9:00 PM IST

Join Now - https://community.100ms.live/developer-community-meetup-october

Workshop Host - Dmitry Fedoseyev & Yogesh Singh, iOS developers at 100ms

Agenda -
-> The killer idea behind Clubhouse and its working
-> Setting up & creating roles for the app.
-> Understanding terminology - HMS SDK, rooms, etc.
-> Integrating the HMS SDK to create an audio room from scratch
-> QnA with 100ms team

[Free Workshop] Build Clubhouse like app for iOS

Arpit Mishra — Sat, 09 Oct 2021 05:04:50 +0000

Join 100ms October developer meet-up where we cover - Building a Audio app like Clubhouse for iOS using 100ms SDK on October 13th, 2021 | 9:00 PM IST

Join Now - https://community.100ms.live/developer-community-meetup-october

Workshop Host - Dmitry Fedoseyev & Yogesh Singh, iOS developers at 100ms

Add live video conferencing to your app in hours, not months

Arpit Mishra — Thu, 12 Aug 2021 12:55:32 +0000

Hi everyone,

I’d love to share what we are building past few months with you.

We launched 100ms today on the ProductHunt 🚀 -> https://www.producthunt.com/

We enable developers to add live audio-video capabilities to their apps.

Previously, our team built live video infrastructure at Facebook and Disney+Hotstar.

Our SDK is different and efficient from existing video APIs.
Would love to hear your thoughts about the product, support us in launch if you liked it.

So, If you like our vision and what we're building, we'd grin from ear to ear if I could count on your support. 😻

DEV Community: Arpit Mishra

Map the Force Within You: Fastest Route and ETA for Rebels!

AMA & Talk: Scaling your Android build with Jetpack & Dagger

GDG #askmeanything #Android #jetpackcompose

Building a Twitter Spaces clone in React Native

[ 🎥 Workshop] Building a Zoom clone in Flutter

Build a Discord stage channel clone with 100ms and Next.js

What We’ll Be Building

Setting up the Project

Getting the token_enpoint

Getting the room_id

Understanding the Terminologies

An Overview of the Starter Code

Building the project

Joining a Room

Rendering The Peers

Adding Functionalities To The Controls

Displaying Audio Level and Mic Status

The Permissions Menu

Adding Hand-Raise Functionality

And That’s a Wrap!

Android SurfaceViewRenderer explained

1. Initing without a shared EglContext

2. Not releasing before initing

3. What if you never init at all?

4. Double the addSinks, double vision

5. How many SurfaceViewRenderers can you create? What happens beyond?

Managing the lifecycle within a RecyclerView

How does that compare to the lifecycle of a SurfaceView?

How to build an audio app like Clubhouse for iOS

Getting Started

Prerequisites

Setting up Project

Creating a Room

Joining The Room

Showing Peers In The Room

Showing Active Speakers

Mute/Unmute

Raise Hand

⚔️ Open Source v/s cPaaS ⚔️ - The architecture choices for building a live video applications.

Building highly scalable real-time video applications with WebRTC

Build Clubhouse 👋 like app for iOS

[Free Workshop] Build Clubhouse like app for iOS

Add live video conferencing to your app in hours, not months

Getting the `room_id`