DEV Community: Phil Miller

How to load an external HTML file in an iOS app

Phil Miller — Thu, 18 Mar 2021 19:43:53 +0000

Daily Keyframes are byte-sized tips from our engineers. We hope they help you remove roadblocks so you can focus on building.

When Apple announced, in iOS 14.3, that WKWebView would have support for navigator.mediaDevices.getUserMedia, we were ecstatic. It meant that iOS applications which relied on a webview could now use audio and video devices, a crucial element for an audio or video call. We were so excited, in fact, that we built Party Line.

However, in the course of development we quickly realized there was a known bug. navigator.mediaDevices.getUserMedia would only work if the HTML file in question was loaded via http(s) origins. If you were loading a local HTML file (using file://), getUserMedia would be denied. Luckily this has been fixed, but those fixes can take time to land, and even longer for users to upgrade to the latest OS version.

So what can be done to get around this today?

The easiest thing to do is host your file somewhere that serves it via https (might as well keep it secure, while we’re at it). If you already have a server for your static assets, simply add it there and you’re good to go. If you don’t, and you want an easy solution, Netlify is a great modern platform for static file deployments (among other things) and even has a drag and drop feature. For Party Line, our iOS HTML file is deployed alongside our React web app, which makes it publicly accessible at https://partyline.daily.co/ios-bridge.html.

To use it in our iOS app, we reference it in Client.swift with the following code:

private static var pageURL: URL {
    URL(string: "https://partyline.daily.co/ios-bridge.html")!
}

And then load it in Client.swift with the following code:

let pageURL = Self.pageURL
self.webView.load(URLRequest(url: pageURL))

And that’s it!

If you want to read more about this, check out our html file, and these related tickets:

And if you’re curious about what we built, head over to the repo or read the blog post.

Build a multi-platform audio community in a weekend

Phil Miller — Fri, 12 Mar 2021 17:36:32 +0000

At Daily, we're seeing a lot of new interest in audio chat and collaboration apps of all kinds. To support people building these apps, we whipped up sample code for a Clubhouse-like (or, Clubhouse-lite) audio room experience on four platforms: web (React), iOS, Android, and React Native. Feel free to try out the live demo on the web, or browse the sample code, then come back and read this post...

If you clicked on this article because of the title, you’re (probably) one of a few possible types of person. You’re a thirsty entrepreneur, ready to see how you can unlock the future. Maybe you’re the curious type and the short timeframe caught your attention. Or in the most likely case you, dear reader, are like your humble author. You’re a cynical developer who loves SEO and being hyperbolic. Hopefully, you’re all three of these people! 🦄

Unless you’ve been living under a rock (or perhaps an Android phone), you have undoubtedly heard about some of these audio communities in the news lately. If you haven’t, may I suggest you enter the Clubhouse, grab a Cappuccino, and make a Quilt? Or you might prefer to take a Roadtrip to the Rodeo. To put it bluntly, audio is hot right now, Musk vs. Putin hot.

If you’ll humor me, I’d like to start by talking about how we approached building Party Line to begin with. So many "weekend" projects go astray because they don’t fully define goals and expectations. So that’s where we’ll begin.

Then we’ll talk about the overall flow of our applications. Creating a consistent experience across four platforms was important to us, so we’ve built four different demos with a small backend (two serverless functions). Since they all share similar logic, we’ll walk through that before diving into platform-specifics. In each section we’ll link out to the platform specific code if you want to dig deeper.

Party on!

Party Line allows you to create audio chat rooms and invite your friends. They can join you as a speaker or just listen. The best part is that it works in most browsers without installing anything. And if you want to ship mobile apps, we’ve got you covered with iOS, Android, and React Native.

Since we wanted to build something in a "weekend", let’s define our goals and call out assumptions to keep the scope manageable.

Our application should have the following features:

A starting screen where you can either create or join a room
A prompt to enter your first and last name
Three user types in a room: moderator, speaker, listener
The room creator is the moderator
Moderators can promote listeners to speakers
Moderators can make other users moderators
Moderators can demote speakers to listeners
Listeners can raise (or lower) their hands to speak
Speakers and moderators can mute/unmute themselves, but only mute others.
Moderators can end the call for everyone
All attendees can leave a call and return to the starting screen

Let’s also consider the following constraints:

No external account management or authentication
No database
No backend aside from serverless functions which call the Daily REST API
Implicit user roles based on meeting tokens
No list of rooms to join

Now that we have a sense for our MVP scope, let’s look at the overall architecture, from a Daily API perspective.

Architecture: methods and events

Since Daily is doing the heavy lifting for us, we can focus on how we’re interacting with Daily and build our interfaces (more on that later).

There are three different ways we’ll interact with Daily:

1) Calling methods from either of the js libraries

join() - to join the room
leave() - to leave the room
setLocalAudio() - for enabling and disabling the microphone
updateParticipant() - for changing roles
setUserName() - for storing roles and raising hands
room() - to fetch room information
participants() - to fetch participant information

2) Responding to events sent by the libraries

joined-meeting - when the local participant joins
left-meeting - when the local participant leaves
error- when an error occurs
participant-joined - when a remote participant joins
participant-updated - when a remote participant updates (ex. mic is turned on)
participant-left - when a remote participant leaves
active-speaker-change - when the active speaker changes

3) Creating rooms and tokens using REST endpoints

/rooms - to create the room
/meetings-tokens - to create the moderator token

It’s worth noting that for iOS and Android, we’ll be interacting with the methods and events via a WebView "bridge". In React and React Native, we can call daily-js and react-native-daily-js directly.

Audio for the masses, the more platforms the merrier!

We’ve put each of the clients in one convenient repo for you. You’ll notice four folders, one for each of the clients. You can find the folder for our serverless functions inside /react/server/functions. Each folder contains its own README with platform specific setup instructions. These should be enough to get everything up and running, but let us know if you’d find detailed, platform-specific posts helpful. Open an Issue, create a PR, or just ping us any time we can help.

In general, React and React Native are the most similar, and the most "idiomatic" in terms of how to build with Daily. Android and iOS are included to show what’s possible via "bridging" data to an invisible WebView. The fact that we’re only playing audio tracks makes this a bit more feasible. We’re actively working on native SDKs for mobile, so we welcome any feedback in this area.

Follow along on the platform of your choice, or explore each of them simultaneously to see how to approach a cross platform application.

For the rest of this overview, we’ll use the following legend.

🕸 (React web app)
⚛ (React Native mobile app(s))
🍏 (iOS mobile app - Swift)
🤖 (Android mobile app - Kotlin & Java; we'll link to the Kotlin examples)
🥅 (Netlify function - Node)

Whenever you see one of these emoji, it will link to the relevant file or line in the repo. Even the ones above. Try it!

First off, follow the README instructions, and start your dev server. (🕸 ⚛ 🍏 🤖)

If you’re one of those read-the-last-page-first types, you can see a working demo here and follow along that way.

The first page you are greeted with is a join/create a page.

This is the user’s entry point into your application. Here we made a couple assumptions to keep the scope down. First, there’s no authentication or accounts per se. We take privacy seriously and you should too. So before you take our scrappy demo and deploy it as a production app, please consider how you’ll handle auth and security in general.

Second, if you start a room, you’re the moderator. We accomplish this by creating a meeting-token which is then used when you join the call. Moderators have the ability to "promote" other user types, which is why we need a token to identify them, but more on that later.

See more on how create (🕸 ⚛ 🍏 🤖) and join (🕸 ⚛ 🍏 🤖) works in the clients

On the server(less) side of things, we’ve created /room (🥅) and /token (🥅) endpoints which call the /rooms and /meeting-tokens endpoints respectively. You’ll see those endpoints used in each of the clients. We’re enforcing the 10 minute demo limit here by using the exp property for rooms and tokens. Feel free to change this in your own application unless you prefer to keep your meetings short and sweet!

Life of the party

Once you create a call, you are presented with the call view (🕸 ⚛ 🍏 🤖). Here, as a moderator, you have the ability to "promote" listeners to speakers, or moderators. We’re using the owner property from the participants object to identify moderators. This gets set when the meeting token you join with has is_owner set to true. To simplify how user roles in general work for the purposes of this demo, we’re storing them by appending to the username (🕸 ⚛ 🍏 🤖). In a production environment, you’ll want a more robust way to enforce the roles, so keep that in mind.

Look who's talking now

When you use your moderator privileges to promote a speaker, under the hood this is accomplished by calling sendAppMessage() to let the speaker know they have been promoted. For the promoted participant, who will be a speaker, we call setUserName(), so that other members will be able to pick up their new role via participants() and update the UI accordingly in each of the clients.

Don't hesitate, moderate!

Sometimes conversations can get a little spirited or maybe someone’s dog has decided they want to participate in the world’s latest social craze. When this happens it’s good as a moderator to be able to mute someone. We accomplish this by calling updateParticipant() with setAudio:false (🕸 ⚛ 🍏 🤖). For privacy reasons, moderators can only mute remote participants. They will have to unmute themselves when things quiet down.

In rare circumstances, muting may not be enough, and you will need to remove someone from the room. We handle this by calling sendAppMessage() and telling the client that needs to leave to exit the room by calling leave() (🕸 ⚛ 🍏 🤖).

Gotchas and One More Thing™️

Because our trust mechanism to identify moderators is a token, when someone gets "promoted" to a moderator they need to rejoin (🕸 ⚛ 🍏 🤖) with their token so we can give them elevated control of the call. This pattern means they’ll drop out of the call for a second or two before rejoining as a moderator. In a production app you might prefer a smoother transition, which could be accomplished with a different moderator authorization method.

Another thing you may have noticed is that we ask for device permissions when you join, even if you’re a listener. This allows us to immediately turn on your mic when the time comes, but if you prefer a less invasive approach, you can always rework things so permissions are requested only when you’ve been promoted.
The not-so-secret sauce of the the iOS and Android clients is that they’re loading daily-js in a "headless" WebView and then interacting with it via a "bridge" (🍏 🤖). This is made possible by additions to platform specific WebView implementations which allow the audio tracks to be played off-screen. This works for this audio-only use case because there’s no video layout logic to deal with. We wanted to demonstrate the power of a lightweight integration like this, but rest assured that we’re actively working on fully featured mobile SDKs which we’ll release later this year™.

So you’ve now got a flourishing multiplatform audio-only application. But you’re finding that your speakers can get a little carried away and sometimes you want to inject some audience participation. For this reason we’ve added the ability for listeners to raise their hands so they can be promoted to speakers. Since we’ve already "creatively" stored user roles in usernames, why not publicly show when someone raises their hand there as well? To do this, we call setUserName() and prepend ✋ (🕸 ⚛ 🍏 🤖). A moderator can then decide to promote, in which case the ✋ will magically disappear. Or a listener can lower their hand if it was "more of a comment than a question".

So there you have it, a suite of awesome demos that we built in a "weekend" (emphasis on week), but…

What's next?

Here are just a few ideas on what to do next with Party Line:

Add proper authentication and user roles
Make rooms persistent and add room metadata
Add the ability to schedule a "Party"
Send notifications when someone joins (via webhook or push)
Add user profiles (avatars, custom fields, etc)
A Party list / overview page
Livestream and scale up!

Now that you’ve got a billion dollar app, don’t forget to create a deck and go after that hard-won VC money. 🤑

In all seriousness, communities are only as good as their members. We want to take the guesswork out of the technical communications part of yours so you can focus on building.

Please reach out if we can help you!

Deploy a Daily Node.js backend server instantly

Phil Miller — Thu, 15 Oct 2020 18:49:04 +0000

If you’ve been following our Daily DEV tutorials, you might’ve noticed Paul’s note in his post about building a video chat app with React:

“In real production code, you'll want to create rooms by calling the Daily REST API from your backend server, to avoid storing API keys in your client-side JavaScript.”

In the future, we’ll go into great detail about how to implement your server-side code, but for now we prefer to give you some building blocks to get you up-and-running as quickly as possible.

What we’ll build

We’re going to set up an instant Node.js server on Glitch. Glitch is a friendly, community-oriented developer tool that allows you to create projects from scratch or "remix" others for inspiration. Every project is backed by a real server, so you have everything you need to get started and to scale.

What you’ll need to build it

Daily account and API key: Sign up if you don’t have these yet.
Glitch account: If you plan on tweaking your server over time, we highly recommend signing up for Glitch. Though, you can still follow this tutorial without creating an account!

Get started

Click the Remix button below.

You should now have an editable copy of the server, which includes public API endpoints that return data via the Daily API. You’ll also have a handy web-based development environment.

Add your key

All you need to do to get going is to add your Daily API Key, which you can get from the dashboard in the Developers section.

Copy it to your clipboard and open the .env file in the Glitch editor. Paste it there (replacing Variable Value):

At your service

Now let’s have a look at the server code (in server.js) and send a sample request.

First, open up the log view (Tools > Logs, located in the bottom left) and you should see:

💗🌴 Your app is listening on port 3000

This means the express server is running and listening for incoming requests [0].

Looking at the code you will see three sections.

In the first section we’re importing dependencies, clearing some useful constants, and setting up an axios instance to reference the Daily API.

const express = require("express");
const axios = require("axios");
const app = express();
app.use(express.json());

// MAKE SURE YOU HAVE ADDED YOUR API KEY IN THE .env file
const BASE_URL = "https://api.daily.co/v1/";
const API_AUTH = process.env.DAILY_API_KEY;

// create an axios instance that includes the BASE_URL and your auth token
// this may be useful to put in an external file to it can be referenced
// elsewhere once your application grows
const api = axios.create({
  baseURL: BASE_URL,
  timeout: 5000,
  headers: { Authorization: `Bearer ${API_AUTH}` }

Next up are all the endpoints we’re creating on our server. Each of them is essentially a loose wrapper that calls its equivalent in the Daily API. Let’s look at the first one, as an example:

app.get("/rooms", async (request, response) => {
  try {
    const rooms = await apiHelper("get", "/rooms");
    response.json(rooms);
  } catch (e) {
    console.log("error: ", e);
    response.status(500).json({ error: e.message });
  }
});

Here, we’re saying when a request comes in at /rooms we want to execute this async callback that makes a request to the Daily API using the apiHelper we defined below. If the request is successful then we send the response back to the requester as json. If it fails, then we send back an http 500 error with an accompanying error message.

Lastly, let’s look at the apiHelper function:

const apiHelper = async (method, endpoint, body = {}) => {
  try {
    const response = await api.request({
      url: endpoint,
      method: method,
      data: body
    });
    return response.data;
  } catch (error) {
    console.log("Status: ", error.response.status);
    console.log("Text: ", error.response.statusText);
    // need to throw again so error is caught
    // a possible improvement here is to pass the status code back so it can be returned to the user
    throw new Error(error);
  }
};

The goal here is to have a reusable way to call the Daily API. It takes the following parameters:

method: the http request method
endpoint: the Daily API endpoint
body: the optional request body, required for POST, PUT, etc.

We’re using the request method from the axios instance we defined above, so we don’t have to worry about specifying the BASE_URL and Authorization header with every request. We’ve included some basic error handling here, but feel free to modify this as needed [1].

Sample request

You can verify all is working as intended by opening the Glitch preview (Click Show -> Next to The Code). Next click 'Change URL' and add [/rooms](https://docs.daily.co/reference#list-rooms). You should see some json, which is the list of rooms on your account.

Your server should now be publicly accessible at the following url:

https://YOUR-PROJECT-NAME.glitch.me

What’s next?

You now have a functional server to make calls to the Daily API which protects your API key. We’ve added a few endpoints as a reference but there are many others you can add as a next step (/recordings for example).

This server also implicitly “trusts” the client that is making these requests. A great next step would be adding some authentication to your client and checking for that on the server. You don’t want just anyone generating tokens with “is_owner” privileges, for example.

Finally, while this is totally viable as a development server, you may want to consider becoming a Glitch member and “Boosting” this app. This gives you a bunch of benefits, most important being that it will always be awake. You will also be supporting the team at Glitch and all the excellent work they do.

[0] I’ve glossed over express and axios. If either of these are unfamiliar, please read their documentation first. At a high level, we’re using express to handle and respond to incoming requests, and we’re using axios to make requests to external Daily APIs.

[1] We’re using async/await to simplify dealing with promises. If this is unfamiliar, do check out the docs on MDN.