Compartir a través de

Inicio rápido: Incorporación de videollamadas a la aplicación cliente de WebView

La tecnología Webview es un explorador incrustable que se puede integrar directamente en una aplicación móvil nativa. Si quiere desarrollar una aplicación de llamadas de Azure Communication Services directamente en una aplicación Android nativa, además de usar Azure Communication Calling Android SDK, también puede usar Azure Communication Calling Web SDK en Android WebView. En este inicio rápido, aprenderá a ejecutar aplicaciones web desarrolladas con el SDK web de llamadas de comunicación de Azure en un entorno de Android WebView.

Prerrequisitos

Importante

Esta característica de Azure Communication Services se encuentra actualmente en versión preliminar. Las características de la versión preliminar están disponibles públicamente y se pueden usar en todos los clientes nuevos y existentes de Microsoft.

Esta versión preliminar se ofrece sin un Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean compatibles o que las funcionalidades estén restringidas.

Para más información, consulte Términos de uso complementarios de las Versiones Preliminares de Microsoft Azure.

En esta guía de inicio rápido se da por supuesto que ya tiene una aplicación WebView de Android. Si no tiene una, puede descargar la aplicación de ejemplo WebViewQuickstart.

Si usa la aplicación de ejemplo WebViewQuickstart, se aplican todas las configuraciones necesarias y el control de permisos. Puede ir directamente a Problemas conocidos. Lo único que tiene que hacer es actualizar defaultUrl en MainActivity a la dirección URL de la aplicación web de llamada que ha implementado y compilar la aplicación.

Adición de permisos al manifiesto de aplicación

Para solicitar los permisos necesarios para realizar una llamada, debe declarar los permisos en el manifiesto de aplicación. (app/src/main/AndroidManifest.xml) Asegúrese de que tiene los permisos siguientes agregados al manifiesto de aplicación:

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
    <uses-permission android:name="android.permission.RECORD_AUDIO" />
    <uses-permission android:name="android.permission.CAMERA" />

Solicitar permisos en tiempo de ejecución

Agregar permisos al manifiesto de aplicación no es suficiente. También debe solicitar los permisos peligrosos en tiempo de ejecución para acceder a la cámara y al micrófono.

Tiene que llamar a requestPermissions() e invalidar onRequestPermissionsResult. Además de los permisos de aplicación, para controlar las solicitudes de permisos del explorador invalide WebChromeClient.onPermissionRequest

La aplicación de ejemplo WebViewQuickstart también muestra cómo controlar las solicitudes de permisos desde el explorador y solicitar permisos de aplicación en tiempo de ejecución.

Configuración de WebView

Azure Communication Calling Web SDK requiere JavaScript habilitado. En algunos casos, vimos el mensaje de error play() can only be initiated by a user gesture en el entorno de Android WebView, pero los usuarios no podían escuchar el audio. Por tanto, se recomienda establecer MediaPlaybackRequiresUserGesture en false.

WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);
settings.setMediaPlaybackRequiresUserGesture(false);

Problemas conocidos

La API MediaDevices.enumerateDevices() devuelve etiquetas vacías.

Es un problema conocido en Android WebView. El problema afectará a la siguiente API en el SDK web:

  • DeviceManager.getCameras()

  • DeviceManager.getMicrophones()

  • DeviceManager.getSpeakers() (Si el dispositivo admite la enumeración del altavoz)

    El valor del campo name del objeto de resultado será una cadena vacía. Este problema no afectará a la función de streaming en la llamada de vídeo, pero los usuarios de la aplicación no podrán conocer la etiqueta de cámara que seleccionan para enviar el vídeo. Para proporcionar una mejor experiencia de interfaz de usuario, puede usar la siguiente solución alternativa en la aplicación web para obtener etiquetas de dispositivo y mapear la etiqueta con deviceId.

    Aunque no podemos obtener etiquetas de dispositivo de MediaDevices.enumerateDevices(), podemos obtener la etiqueta de MediaStreamTrack. Esta solución alternativa requiere que la aplicación web use getUserMedia para obtener la secuencia y asignar deviceId. Si hay muchas cámaras y micrófonos en el dispositivo Android, puede tardar un tiempo en recopilar etiquetas.

async function getDeviceLabels() {
    const devices = await navigator.mediaDevices.enumerateDevices();
    const result = {};
    for (let i = 0; i < devices.length; i++) {
        const device = devices[i];
        if(device.kind != 'audioinput' && device.kind != 'videoinput') continue;
        if(device.label) continue;
        const deviceId = device.deviceId;
        const deviceConstraint = {
            deviceId: {
                exact: deviceId
            }
        };		
        const constraint = (device.kind == 'audioinput') ?
                { audio: deviceConstraint } :
                { video: deviceConstraint };
		try {
            const stream =  await navigator.mediaDevices.getUserMedia(constraint);
            stream.getTracks().forEach(track => {
                let namePrefix = '';
                if (device.kind == 'audioinput') {
                    namePrefix = 'microphone:';
                } else if(device.kind == 'videoinput') {
                    namePrefix = 'camera:';
                }
                if (track.label === '' && deviceId == 'default') {
                    result[namePrefix + deviceId] = 'Default';
                } else {
                    result[namePrefix + deviceId] = track.label;
                }
                track.stop();
            });
		} catch(e) {
		    console.error(`get stream failed: ${device.kind} ${deviceId}`, e);
		}
    }
    return result;
}

Captura de pantalla del resultado getDeviceLabels().

Después de obtener la asignación entre deviceId y label, puede usarla para relacionar la etiqueta con id desde DeviceManager.getCameras() o DeviceManager.getMicrophones()

Captura de pantalla que muestra la solución alternativa del nombre del dispositivo.

WKWebView de iOS permite insertar contenido web sin problemas en la interfaz de usuario de la aplicación. Si desea desarrollar una aplicación de llamada de Azure Communication Services en iOS, además de usar el SDK de iOS de llamadas de comunicación de Azure, también puede usar el SDK web de llamadas de comunicación de Azure con wKWebView de iOS. En este inicio rápido, aprenderá a ejecutar aplicaciones web desarrolladas con el SDK web de llamadas de comunicación de Azure en un entorno WKWebView de iOS.

Prerrequisitos

Importante

Esta característica de Azure Communication Services se encuentra actualmente en versión preliminar. Las características de la versión preliminar están disponibles públicamente y se pueden usar en todos los clientes nuevos y existentes de Microsoft.

Esta versión preliminar se ofrece sin un Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no sean compatibles o que las funcionalidades estén restringidas.

Para más información, consulte Términos de uso complementarios de las Versiones Preliminares de Microsoft Azure.

En esta guía de inicio rápido se da por supuesto que está familiarizado con el desarrollo de aplicaciones de iOS. Mencionaremos la configuración y sugerencias necesarias al desarrollar la aplicación WKWebView de iOS para el SDK de llamadas de Azure Communication Services.

Agregar claves en Info.plist

Para realizar una videollamada, asegúrese de que tiene las siguientes claves agregadas a Info.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSMicrophoneUsageDescription</key>
	<string>Camera access is required to make a video call</string>
	<key>NSCameraUsageDescription</key>
	<string>Microphone access is required to make an audio call</string>
</dict>
</plist>

Gestionar el mensaje de permisos

En el Safari de iOS, los usuarios pueden ver la solicitud de permisos con más frecuencia que en otras plataformas. El motivo es que Safari no guarda los permisos durante mucho tiempo a menos que se adquiera una secuencia.

WKWebView proporciona una manera de controlar la solicitud de permisos del explorador mediante WKUIDelegate.webView. Esta API solo está disponible en iOS 15.0 y versiones posteriores.

Este es un ejemplo. En este ejemplo, el permiso del explorador se concede en decisionHandler, por lo que los usuarios no verán la solicitud de permisos del explorador después de conceder los permisos de la aplicación.

import WebKit
import SwiftUI

struct WebView: UIViewRepresentable {
    private(set) var url: URL
    private var webView: WKWebView

    init(url: String) {
        self.url = URL(string: url)!

        let prefs = WKWebpagePreferences()
        prefs.allowsContentJavaScript = true
        prefs.preferredContentMode = .recommended

        let configuration = WKWebViewConfiguration()
        configuration.defaultWebpagePreferences = prefs
        configuration.allowsInlineMediaPlayback = true
        configuration.mediaTypesRequiringUserActionForPlayback = []
        let webView = WKWebView(frame: CGRect(), configuration: configuration)
        self.webView = webView
    }

    class Coordinator: NSObject, WKUIDelegate {
        let parent: WebView
        init(_ parent: WebView) {
            self.parent = parent
        }
        func webView(_ webView: WKWebView, requestMediaCapturePermissionFor origin: WKSecurityOrigin, initiatedByFrame frame: WKFrameInfo, type: WKMediaCaptureType, decisionHandler: @escaping (WKPermissionDecision) -> Void) {
            decisionHandler(WKPermissionDecision.grant)
        }
    }

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }

    func makeUIView(context: Context) -> WKWebView {
        return webView
    }

    func updateUIView(_ uiView: WKWebView, context: Context) {
        uiView.uiDelegate = context.coordinator
        uiView.load(URLRequest(url: self.url))
    }
}

Configuración de WebView

Azure Communication Calling Web SDK requiere JavaScript habilitado.

allowsInlineMediaPlayback también es necesario que sea true.

let prefs = WKWebpagePreferences()
prefs.allowsContentJavaScript = true
prefs.preferredContentMode = .recommended

let configuration = WKWebViewConfiguration()
configuration.defaultWebpagePreferences = prefs
configuration.allowsInlineMediaPlayback = true
let webView = WKWebView(frame: CGRect(), configuration: configuration)

Problemas conocidos

El micrófono se silencia cuando la aplicación pasa a segundo plano

Cuando un usuario bloquea la pantalla o la aplicación WkWebView va a segundo plano, la entrada del micrófono se silenciará hasta que la aplicación vuelva al primer plano. Este es el comportamiento del sistema WkWebView de iOS y el micrófono no está silenciado por el SDK web de llamadas de Azure Communication Services.

La conexión cae poco después de que la aplicación pase a segundo plano

Este también es el comportamiento de la aplicación iOS. Cuando cambiamos a otra aplicación de audio/vídeo, la conexión se quitará aproximadamente 30 segundos más tarde. Esto no es un problema si la aplicación solo permanece en segundo plano durante un breve tiempo. Cuando la aplicación vuelva al primer plano, la llamada se recuperará. Si la aplicación permanece en segundo plano durante un período más largo, el servidor pensará que el usuario está fuera y quitará al usuario de la lista de participantes. En este caso, cuando el usuario vuelve a cambiar la aplicación WkWebView a primer plano, la llamada se desconectará y no se recuperará.

Pasos siguientes

Para obtener más información, consulte los artículos siguientes: