DEV Community: Joaquín Engelmo (a.k.a. Kini)

Alexa skills de audio con la interfaz AudioPlayer: built-in intents (IV)

Joaquín Engelmo (a.k.a. Kini) — Tue, 13 Apr 2021 13:46:51 +0000

Sigo con la serie donde voy detallando todos los aspectos a la hora de construir una Alexa Skill con la interfaz AudioPlayer.

En este artículo vamos a entrar en detalles en los built-in intents, ya predefinidos por Alexa, que son obligatorios en este tipo de skills. Si nuestro backend falla al responder a algunos de ellos es muy posible que se reporte como fallo en el proceso de certificación.

¿Cómo obtiene mi skill la info necesaria para "reanudar un audio" o para "pasar al siguiente/anterior"?

Antes de avanzar con los intents necesito explicar una parte clave en las skills con AudioPlayer. En el post de introducción comento que este tipo de skills tienen la peculiaridad de permitir interacciones fuera del contexto de una skill activa. Esto quiere decir que un usuario va a poder usar los built-in intents sin abrir nuestra skill y esas requests van a llegar correctamente a nuestro back. Por ejemplo, sin la skill abierta, incluso tiempo después de haberla usado, serán correctas interacciones como: "Alexa, siguiente/anterior" o "Alexa, para/continúa".

Esos intents llegarán al back de nuestra skill si:

Es la última skill que ha usado AudioPlayer para reproducir un audio en Alexa.
No se ha invocado después algún servicio nativo que reproduzca audio, como el servicio de música o los resúmenes de noticias.
No se ha reseteado el dispositivo.

Esto hace necesario el uso de persistencia ya que no vamos a poder contar con tener una sesión que mantenga información sobre el audio que se está reproduciendo o el offset en el cual se ha pausado, por poner un par de ejemplos.

DynamoDB al rescate

Si queremos manejar los built-in intents ofreciendo una buena experiencia al usuario, tendremos que hacer buen uso de los atributos de persistencia que nos ofrece el SDK de Alexa. Además, la información que guardemos habrá que segmentarla por el userId, información que nos llega en cada petición al back.

Por ejemplo, una skill básica de audio de tipo radio, o con un solo audio, necesitará guardar solamente el offset para pausar/reanudar. O, una skill algo más compleja que maneja diferentes audios, como "El informativo de Ángel Martín" (por días, por semanas, etc), necesita saber qué audio se estaba reproduciendo para intents como "anterior/siguiente":

{
  "audio": "chiste-1"; // O una fecha si es por día: 2020-12-24
  "offsetInMillis": 1234456789;
}

Ya he hablado en otro post sobre el uso de los atributos de persistencia en el SDK y cómo configurar el uso de DynamoDB. Lo más importante a destacar es que vamos a crear registros por userId y ahí, con un modelo JSON como el anterior, podremos controlar el estado del playback de una forma consistente para todos los built-in intents.

Built-in intents

El primer paso para usar AudioPlayer en una skill es activar el uso de esa interfaz. Esto lo cuento en el primer post de la serie. Para no repetirme sobre lo que explico en ese artículo voy a ir directo a contar el manejo de algunos built-in intent en el back. Digo "algunos" porque hay todo un listado pero no todos los he usado hasta ahora en las skills de audio que he hecho. Voy a comentar los que han sido más habituales para mí.

Amazon.PauseIntent/Amazon.CancelIntent y Amazon.ResumeIntent

Hay un par de acciones básicas que son obligatorias de cubrir y que van a ser comprobadas en el proceso de certificación: pausar/parar un audio y poder continuarlo luego.

Mientras se esté reproduciendo un audio que hayamos enviado con la directiva de Play, un usuario podrá decir:

"Alexa, para" > enviará un Amazon.PauseIntent
"Alexa, cancela" > enviará un Amazon.CancelIntent
"Alexa, continúa" > enviará un Amazon.ResumeIntent

Tanto la acción final de parar el audio, como de retomarlo, recae en la lógica del back. Y la respuesta esperada siempre tendrá interacción con el AudioPlayer enviando alguna de sus directivas. Concretamente:

Amazon.PauseIntent/Amazon.CancelIntent

Si nos llega el intent de pausar/cancelar, vamos a querer básicamente lo mismo en ambos casos. Parar el audio y persistir en que segundo se ha quedado la reproducción actual. De esa forma luego podremos continuar desde ese punto.

De la forma que funciona AudioPlayer tenemos que dividir esta acción en dos pasos:

1) Le decimos al AudioPlayer que tiene que parar la reproducción actual enviándole la directiva de de Stop:

2) Al recibir lo anterior, Alexa parará el audio y nos enviará un evento de reproducción. Concretamente una PlaybackStoppedRequest. Desde esa request podremos saber el segundo en cuál se ha pausado:

Siempre tendremos primero que persistir el audio en curso, por ejemplo antes de lanzar una directiva de Play. Así después podemos recuperarlo de la siguiente forma:

input.attributesManager.persistentAttributes["lastPlayedAudio"] =
            JacksonSerializer().serialize(Audio(audioUrl, offsetInMillis))
input.attributesManager.savePersistentAttributes()

Con ese modelo de persistencia tan simple, un objeto Audio con un par de campos: audioUrl y offsetInMillis; sería suficiente para el control de toda la lógica de pausado y continuar.

Amazon.ResumeIntent

Si nos llega el intent de continuar, tomando la información persistida para el usuario, lanzaremos una directiva de Play con la URL del audio correspondiente en el segundo que se pausó.

1) Recuperamos de persistencia la información del último Audio reproducido por el usuario. Supuestamente ahí tendremos la URL y el momento en el que se quedó la reproducción.

2) Enviamos la directiva de Play con la información anterior.

Aquí os pongo una extensión (magia de Kotlin) que le añadí a los HandlerInput para crear una respuesta de PlayDirective donde reemplazo cualquier cosa que esté sonando y meto el audio que quiero en el segundo donde se quedó.

Amazon.RepeatIntent y Amazon.StartOverIntent

A partir de lo anterior, donde hemos asentado la base del modelo de persistencia y cómo lo usaremos, nos resultará mucho más fácil manejar estos dos intents.

Amazon.RepeatIntent

Cuando el usuario diga: "Alexa, repetir", por ejemplo, nos llegará este built-in intent. Aquí, según mi opinión, podemos ver la acción deseada de dos forma:

1) El usuario quiere repetir el audio actual una vez finalice. Esta es una funcionalidad habitual en interfaces de reproducción de audio.

2) El usuario quiere reiniciar el audio actual sin esperar a que finalice. Pueden darse casos de uso, igual con audios orientados al aprendizaje o similar, que el usuario quiera repetir un audio corto desde el principio inmediatamente.

En el caso 1, lo que tenemos que hacer es, a partir de la información persistida del audio en curso, enviar una directiva al AudioPlayer de Play pero "encolando el audio" en vez de "reemplazando" (que es como lo hemos venido haciendo en ejemplos anteriores). Encolar el audio, desde el principio, lo que hará será meterlo en la lista de reproducción del AudioPlayer para que suene una vez acabe el actual.

En el caso 2, tendremos el mismo escenario que para Amazon.StartOverIntent.

Amazon.StartOverIntent

Tal como yo entiendo este caso de uso, el usuario diría: "Alexa, ponlo desde el principio" o similar. La intención es poner, de forma inmediata, el audio actual desde el principio.

Amazon.NextIntent y Amazon.PreviousIntent

Aquí tenemos otra pareja de built-in intents que suelen ir de la mano. Cubren los casos de uso de "navegar" en una lista de reproducción:

"Alexa, siguiente" > se envía un Amazon.NextIntent
"Alexa, anterior" > se envía un Amazon.PreviousIntent

La forma de manejar estos intents ya va a depender muy concretamente de la funcionalidad de la skill que tenemos entre manos. Por ejemplo:

Si es una skill con solamente un audio podemos, o no manejarlos (tendremos un fallo en el back si le llega este intent) o manejarlos por igual y retornar una respuesta vacía para no impactar al AudioPlayer.
Si es una skill, como "el informativo de Ángel Martín", que permite navegar entre audios (días del informativo en este caso), podremos manejar estos intents para reemplazar el audio actual por el nuevo que corresponda.

En el código que pongo, sacado de la skill del informativo, lo que hago es recoger esos intents y, según el que sea, busco la fecha anterior/siguiente al audio actualmente en reproducción y lo envío al AudioPlayer con la directiva de Play (lo tengo en una función auxiliar).

Y aquí terminamos con el penúltimo post de la serie. Es posible que aquí hayáis echado en falta otros built-in intents relacionados con el AudioPlayer. Con lo contado aquí, combinando las directivas del AudioPlayer, se pueden cubrir todos.

En el siguiente post veremos lo último que falta, el AudioPlayer y qué implica usarlo en dispositivos Alexa con pantallas táctiles :)

Alexa skills de audio con la interfaz AudioPlayer: eventos de playback (III)

Joaquín Engelmo (a.k.a. Kini) — Wed, 13 Jan 2021 09:27:07 +0000

En esta serie de artículos estoy contando todo lo que necesitas saber para usar la interfaz AudioPlayer en tus skills. Es una funcionalidad de Alexa que tiene bastante por detrás y le dedicaré varios posts.

En esta tercera entrega voy a hablar de los eventos que se producen relacionados con la reproducción de audio en un dispositivo Alexa, también denominados eventos de playback.

Eventos de Playback

Estos eventos son simplemente peticiones que nos llegarán al back de la skill y nos informan de cambios de estado en la reproducción del audio. Son emitidos por el reproductor nativo de Alexa y llegarán a la skill sin necesidad de tener una sesión abierta.

El back de nuestra skill tiene la responsabilidad de manejar correctamente cada uno de los eventos de manera que no influya de forma negativa en la reproducción en curso. El uso de cada evento dependerá de la skill que tengamos entre manos y a veces bastará con generar una respuesta vacía. Además, no podemos responder a estos eventos con una respuesta estándar que contenga texto para Alexa. Solo podemos responder con las directivas de AudioPlayer que vimos en el artículo anterior.

Como decía antes, estos eventos no van a llevar información de sesión pero sí que tendrán información de contexto con lo que podremos sacar de ahí, por ejemplo, la info del userId. Esta información la usaremos para la capa de persistencia.

Los tipos de eventos son:

AudioPlayer.PlaybackStarted > Se envía cuando el audio indicado por la directiva de Play ha comenzado a reproducirse de forma exitosa.
AudioPlayer.PlaybackFinished > Vamos a recibir este evento cuando la reproducción finalice.
AudioPlayer.PlaybackStopped > Alexa lo envía para responder a la directiva de Stop al parar el audio que se estaba reproduciendo.
AudioPlayer.PlaybackNearlyFinished > Se envía para indicar que la reproducción en curso está próxima a terminar.
AudioPlayer.PlaybackFailed > Indica que no se pudo reproducir el audio indicado debido a algún problema.

Los cuatro primeros eventos tienen la misma información en la petición:

{
  "type": "AudioPlayer.[type]",
  "requestId": "unique.id.for.the.request",
  "timestamp": "timestamp of request in format: 2018-04-11T15:15:25Z",
  "token": "token representing the currently playing stream",
  "offsetInMilliseconds": 0,
  "locale": "a locale code such as en-US"
}

En el caso de uso de nuestra skill, por el modelo de datos persistente, nos vendrá bien la información del campo offsetInMilliseconds que indica en qué punto de reproducción está el audio en cuestión. Para una explicación del resto de campos os enlazaré la documentación oficial según los detalle.

Para el evento de AudioPlayer.PlaybackFailed, además de lo anterior, vamos a tener información del error y del estado del playback en el momento que ocurre el problema. Lo veremos en su propio apartado.

AudioPlayer.PlaybackStarted

Al recibir este evento tendremos la confirmación de que el audio que se indicó en la directiva Play ha comenzado su reproducción sin problemas. Alexa lo envía tanto si se ha iniciado un audio desde su inicio, como si hemos continuado un audio que estaba pausado.

A la hora de responder a este tipo de eventos tenemos varias opciones:

Usar las directivas de AudioPlayer Stop o ClearQueue.
Cualquier otro tipo de respuesta que NO contenga un texto para Alexa u otras directivas (como las de Dialog Management).

Una respuesta básica válida podría ser (en Kotlin):

Veremos el caso concreto de nuestra skill de ejemplo en otro post.

AudioPlayer.PlaybackFinished

Alexa envía esta petición cuando el audio finaliza por haber llegado al final de la reproducción del mismo.

A la hora de responder a este tipo de eventos tenemos varias opciones:

Usar las directivas de AudioPlayer Stop o ClearQueue.
Cualquier otro tipo de respuesta que NO contenga un texto para Alexa u otras directivas (como las de Dialog Management).

Una respuesta básica válida podría ser (en Kotlin):

En nuestro ejemplo no necesitaremos manejar este evento para dar una respuesta distinta a la anterior.

AudioPlayer.PlaybackStopped

El back recibirá esta petición como respuesta a:

Diretiva deStop .
Directiva de Play indicando un comportamiento de REPLACE_ALL .
Directiva de ClearQueue con un comportamiento de CLEAR_ALL .
Durante una reproducción de audio en curso el usuario hace una petición a Alexa, con lo que el audio se pausa de forma momentánea.

A este tipo de eventos solo está permitido responder algo básico (en Kotlin):

AudioPlayer.PlaybackNearlyFinished

Se envía cuando la reproducción está llegando a su fin, siendo un evento especialmente útil cuando se trabaja con una lista de reproducción.

Posibles respuestas:

Cualquier directiva de AudioPlayer.
Cualquier otro tipo de respuesta que NO contenga un texto para Alexa u otras directivas (como las de Dialog Management).

Al recibirlo podríamos responder con una directiva de Play y de esa forma preparar siguientes audios sin interferir en la reproducción actual. Alexa automáticamente se encarga de ir transicionando entre los elementos de la playlist.

AudioPlayer.PlaybackFailed

Vamos a recibir este evento en el back cuando se produzca algún tipo de problema con la reproducción del audio en el dispositivo.

El formato de la petición es distinto a los anteriores:

{
  "type": "AudioPlayer.PlaybackFailed",
  "requestId": "unique.id.for.the.request",
  "timestamp": "timestamp of request in format: 2018-04-11T15:15:25Z",
  "token": "token representing the currently playing stream",
  "offsetInMilliseconds": 0,
  "locale": "a locale code such as en-US",
  "error": {
    "type": "error code",
    "message": "description of the error that occurred"
  },
  "currentPlaybackState": {
    "token": "token representing stream playing when error occurred",
    "offsetInMilliseconds": 0,
    "playerActivity": "player state when error occurred, such as PLAYING"
  }
}

Podemos ver que en este caso vamos a tener información del error e información del estado del playback en el momento del error (currentPlaybackState). En el caso de las skills con AudioPlayer que yo he creado, y en el ejemplo que estamos desarrollando, no nos aporta nada conocer el estado del playback, pero sí los tipos de errores que nos vamos a poder encontrar:

MEDIA_ERROR_UNKNOWN > Error desconocido al intentar reproducir el audio.
MEDIA_ERROR_INVALID_REQUEST > Suele ser un error con el acceso al audio, como por ejemplo: no es público, no se encuentra, etc.
MEDIA_ERROR_SERVICE_UNAVAILABLE > No es posible conectarse a la URL indicada.
MEDIA_ERROR_INTERNAL_SERVER_ERROR > En este caso no hay problema con la URL pero Alexa encontró algún problema.
MEDIA_ERROR_INTERNAL_DEVICE_ERROR > Error en el dispositivo al intentar reproducir el audio.

En mi opinión, estos errores son bastante pobres y no aportan mucho sobre lo que está ocurriendo realmente. Por poner unos ejemplos con la skill de "El informativo de Ángel Martín":

Tuve un problema con los formatos del audio. Al principio usaba audios en formato m4a, las pruebas fueron bien y pasó el proceso de certificación. Al publicar la skill empecé a ver en los logs muchos MEDIA_ERROR_INTERNAL_DEVICE_ERROR pero no tenía más detalles. La solución para ese caso fue usar mp3. No fue nada intuitivo sino que tuve que buscar posibles problemas por otros sitios.
Una vez realizado el cambio anterior y desaparecer esos errores vi que seguía recibiendo algunos de MEDIA_ERROR_UNKNOWN o MEDIA_ERROR_INTERNAL_SERVER_ERROR. Esto se debía a que, dependiendo del firmware del dispositivo Alexa, había incluso problemas al reproducir el mp3. En esos casos la solución consistía en que los usuarios actualizaran el firmware.
Y, por último, a modo anécdota (y metedura buena de pata mía), cuando recibía un MEDIA_ERROR_INTERNAL_DEVICE_ERROR estaba retornando un audio en m4a que, a su vez, provocaba otro MEDIA_ERROR_INTERNAL_DEVICE_ERROR... os podéis imaginar el bucle infinito de peticiones a la lambda y a s3.

A este tipo de eventos podemos responder con:

Cualquier directiva de AudioPlayer.
Cualquier otro tipo de respuesta que NO contenga un texto para Alexa u otras directivas (como las de Dialog Management).

Un ejemplo en Kotlin:

Si recibo el error MEDIA_ERROR_INTERNAL_DEVICE_ERROR > construyo una respuesta vacía (basado en lo que os comentaba antes de mi experiencia con un bucle infinito).
Si recibo cualquier otro error > genero una respuesta con una directiva de Play y un audio de fallback.

Y hasta aquí el post sobre los eventos de playback. Me ha quedado un poco largo pero había ciertas cosas necesarias de explicar que me han dado más de un dolor de cabeza a mí.

En el siguiente artículo veremos los built-in intents, la tercera pata principal de una skill de audio, y nos permitirá ir dibujando la imagen global del back :)

Alexa skills de audio con la interfaz AudioPlayer: directivas (II)

Joaquín Engelmo (a.k.a. Kini) — Tue, 05 Jan 2021 07:02:47 +0000

En el primer post de la serie sobre AudioPlayer hacía una introducción a esa interfaz de Alexa que nos permite crear skills que reproducen audio. Te recomiendo leerlo primero, si aún no lo hiciste, para tener claros los conceptos básicos antes de entrar en algunos detalles más avanzados aquí.

En este post vamos a ver las directivas básicas del AudioPlayer que nos permitirán o bien reproducir un audio o parar una reproducción en curso. Las directivas son información especial que se añade a una respuesta desde el back para que el dispositivo Alexa que se está usando haga algo.

Siempre aviso al inicio de este tipo de artículos que voy a usar el SDK de Java, programando en Kotlin, para el backend. Esto hace diferente la experiencia del desarrollador para esta parte pero los conceptos y la información que cuento aplica igualmente. Al final lo que cambian son detalles derivados por un SDK concreto o la "syntactic sugar" de un lenguaje determinado.

Y otro friendly reminder: para probar este tipo de skills no podemos usar el simulador de la Alexa Developer Console ya que no permite reproducir audio. Vamos a necesitar disponer de un dispositivo con Alexa para ir probando cualquier cosa que hagamos con el AudioPlayer.

Audio Skill de chistes

Antes de entrar en detalles voy a plantear una skill que pone a disposición del usuario varios audios. Por ejemplo, podríamos hacer una skill que reproduzca chistes ya grabados en mp3, sin usar la voz de Alexa.

Alojamiento de los audios

Supongamos que esos audios están alojados en S3 de forma pública con nombres como "chiste-1", "chiste-2", etc. Además hemos decidido que sean archivos MP3. De esa forma estamos cubriendo los requisitos que pone Alexa para que no tengamos problemas al intentar reproducirlos.

La URL de acceso a un chiste podría ser: https://skill-chistes.s3.[region].amazonaws.com/chiste-[n].mp3. Así podemos fácilmente movernos entre audios (anterior > chiste-[n-1] o siguiente > chiste-[n+1]) e identificar de forma inequívoca para los intents de pausar/continuar, comenzar desde el principio, repetir, etc.

Directivas de AudioPlayer

Para indicar al dispositivo Alexa que está utilizando el usuario que tiene que realizar algún tipo de operación especial, como reproducir como audio el contenido de una URL, hay que usar una directiva.

Estas directivas tienen un formato concreto y forman parte de una respuesta normal que se envía desde el back. Para el AudioPlayer tenemos tres directivas posibles:

AudioPlayer.Play > Le dice a Alexa que reproduzca el audio indicado por la URL, campo audioItem, que va en la respuesta.
AudioPlayer.Stop > Indica parar la reproducción del actual audio, sea cual sea.
AudioPlayer.ClearQueue > Se usa para limpiar la cola de audios que estuvieran programados para sonar.

Yo aún no tengo experiencia gestionando colas de reproducción con lo que no voy a contar cómo usar la directiva de AudioPlayer.ClearQueue pero dejo el link a la documentación oficial.

Directiva AudioPlayer.Play

A la hora de hacer una skill de audio lo primero que nos interesará será que Alexa reproduzca el fichero MP3 que tenemos alojado, en este caso, en un supuesto S3. Esta directiva la podemos añadir a la respuesta de cualquier petición, ya sea un LaunchRequest o IntentRequest.

Cosas a tener en cuenta a la hora de añadir la directiva de play a una respuesta:

El formato de esta directiva es bastante extenso ya que permite, por ejemplo, indicar metadatos si estamos en un dispositivo con pantalla pero no estamos usando APL. De esta forma a la salida de audio se le podría acompañar con una salida visual mínima.
Podemos incluir también una salida de texto que Alexa dirá justo antes de reproducir el audio.
Normalmente querremos que Alexa finalice la sesión y reproduzca el audio simplemente. En caso contrario, Alexa comenzará a reproducir el audio y de forma inmediata lo pausará para quedarse a la escucha del usuario. Ese no sería el comportamiento esperado para este tipo de skills.

Antes de ver el código de la directiva es necesario comentar un campo obligatorio de la misma: el PlayBehavior. El valor de este campo va a indicar el comportamiento que tiene que tener el playback de Alexa con el audio que se le envía. Hay tres posibles valores:

REPLACE_ALL > que comienza la reproducción del audio que se le está pasando remplazando el actual y la cola pendiente que hubiera. Será el usado en nuestro ejemplo.
ENQUEUE > que encola el audio indicado al final de la actual cola sin afectar a la reproducción en curso.
REPLACE_ENQUEUED > remplaza la cola actual sin afectar a la reproducción en curso.

Para añadir la directiva a la respuesta, usando el SDK de Java y Kotlin, tenemos un builder que nos facilitará la vida bastante:

En el builder añadimos la directiva de AudioPlayer. Esto equivaldría a poner el type: AudioPlayer.Play si estuviéramos usando Javascript/Typescript.
Indicar el comportamiento del playback a REPLACE_ALL como ya dijimos anteriormente, ya que no vamos a usar una cola de reproducción.
Indicar desde qué punto tiene Alexa que reproducir el audio que se le pasa. Para comenzar desde el principio usamos el valor de 0 ( 0L en Kotlin ya que es un Long). Cuando lleguemos a la parte de reanudar un audio pausado indicaremos aquí otro valor.
El valor de un "token previo", obligatorio si estamos usando colas, para identificar cualquier reproducción previa. En este caso no lo necesitamos y lo ponemos a null.
Un token para la reproducción que estamos enviando. Es obligatorio siempre. Para nuestro ejemplo vale cualquier valor como: audioSkill.
La URL que identifica el audio.

Directiva AudioPlayer.Stop

Esta directiva para parar la reproducción del audio en curso es mucho más sencilla que la de play al no tener parámetros ni nada de configuración. Basta con añadirla a la respuesta que nos interese:

El uso de estas directivas va a provocar que se generen los eventos del playback y tengamos que manejarlos correctamente en nuestro back. Esto va íntimamente relacionado con los built-in que se pueden generar por peticiones del usuario.

Veremos todos los detalles en siguientes entregas de esta serie de artículos :)

Codemotion Madrid 2020 - Taller: Crear una skill para Alexa es fácil, sencillo y para toda la familia

Joaquín Engelmo (a.k.a. Kini) — Sun, 03 Jan 2021 12:28:18 +0000

Aquí os dejo el vídeo completo del taller que impartí en Codemotion Madrid 2020. En poco más de hora y media repaso parte de la teoría básica y conceptos esenciales de los asistentes de voz. En la parte práctica, siguiendo el taller, cualquier persona podrá crear una Alexa skill en cuestión de minutos y tenerla publicada en poco tiempo.

Usando la interfaz AudioPlayer para crear Alexa skills que reproducen audio (I)

Joaquín Engelmo (a.k.a. Kini) — Wed, 23 Dec 2020 06:57:30 +0000

En un post anterior contaba cómo crear una Alexa skill de audio siguiendo una serie de pasos y usando para el back un código ya creado por mi. Ese tipo de skills que hacen streaming de audio usan la interfaz AudioPlayer de Alexa. El uso de AudioPlayer no es complicado pero todo lo que quiero contar da para varios artículos.

En este primer post voy a hacer una introducción al AudioPlayer y explicar en qué consiste su funcionamiento. Es un caso bastante particular con respecto al uso habitual de skills. Iré soltando muchos conceptos que enlazaré con la documentación oficial. Para terminar indicaré cómo habilitar la interfaz en una skill y qué efectos tiene eso en el modelo de interacción.

La carga de trabajo de este tipo de skills recae en el back y es lo que iremos viendo en futuros artículos donde podré detallar y explicar bien todo lo contado en esta introducción.

Interfaz AudioPlayer

¿Qué es?

La interface de AudioPlayer nos permite crear skills que reproduzcan audio y nos ofrece información sobre el estado de la reproducción, playback, para que nosotros en el back podamos reaccionar a eso en caso necesario.

El AudioPlayer se puede controlar tanto por voz como por botones o vía táctil. Dependiendo del origen de la acción que hagamos sobre el audio nos llegarán distintos tipos de requests al back.

En el código que tengo publicado se recogen la mayoría de eventos relacionados con el playback, así como intents específicos para el control del audio. Lo que no tengo cubierto en mi ejemplo de código son eventos de botones/táctiles pero los comentaré igualmente aquí porque añadirlo es trivial.

¿Cómo funciona?

La interfaz de AudioPlayer habilita una forma bastante particular de usar Alexa e interactuar con una skill. El punto de entrada inicial siempre va a ser arrancar la skill de forma normal con su nombre de invocación. Una vez que un audio se reproduzca a partir de nuestra skill, Alexa de forma nativa tomará el control del resto de interacciones sin que el usuario tenga que volver a invocar la skill. Además de esto vamos a tener eventos que van a llegar al back cuando pasen ciertas cosas, así como comandos si se está usando una interfaz táctil.

Por tanto, si tuviéramos una skill que reproduce un audio pasaría lo siguiente:

El usuario invoca la skill y se empieza a reproducir un audio. Para ello se usa una directiva, AudioPlayerPlayDirective, desde el back. Se finaliza la sesión y toma el control Alexa. De esta forma ya no estamos en el contexto de nuestra skill.
A partir de este momento podemos hacer uso de ciertos built-in intents, predefinidos por Amazon, para manejar el audio en curso (pausar, parar, repetir desde el principio, etc). Por ejemplo el usuario va a poder decir: "Alexa, para" o "Alexa, siguiente", sin invocar a la skill.
Igualmente, si tenemos un dispositivo con pantalla, podremos hacer uso de los controles del reproductor de audio. Este controlador enviará distintos comandos por cada operación elegida. Ejemplos aquí serían los típicos botones de cualquier reproductor multimedia.
También, de forma transparente para el usuario, Alexa va enviando eventos al back de la skill que inició la reproducción del audio. Estos eventos están asociados a distintas cosas como, por ejemplo, la reproducción del audio comenzó o falló, la reproducción se ha parado, está a punto de finalizar, ha finalizado, etc

Un apunte importante aquí: Amazon deja en manos del desarrollador toda la gestión de saber identificar qué audio se ha pausado/ se quiere retomar, en qué offset, cuál sería el siguiente audio o el anterior a reproducir, etc. Cada evento de playback o intent predefinido (como Resume/Previous/Next/Pause) ocurren fuera del contexto de una skill abierta y, por tanto, no tienen información de sesión con lo que no podemos hacer uso de los atributos de ese tipo en estas skills. Esto hace inevitable tirar de algún tipo de solución de persistencia. En mi caso uso DynamoDB.

La "magia" en este tipo de skills radica en cómo Alexa gestiona la reproducción del audio. Una vez que una skill lanza la directiva de play y comienza el playback del audio, Alexa va a recordar esa skill. Gracias a eso, si el usuario dice: "Alexa, siguiente", se generará una petición de Amazon.NextIntent al back de la skill correcta. Y esto puede ocurrir al poco tiempo de haber usado la skill o mucho después.

Alexa va a recordar la última skill que reprodujo audio y, de esta forma, va a poder enviarle built-in intents sin necesidad de usar el nombre de invocación. Si, por ejemplo, usamos la skill de "el informativo de Ángel Martín" por la mañana y por la tarde, sin usar el nombre de invocación, decimos: "Alexa, anterior", la skill del informativo recibirá la petición e intentará enviar el nuevo audio correspondiente.

Para "olvidar" esta última skill que reprodujo audio tiene que pasar uno de los siguientes casos:

Que el usuario use otra skill con AudioPlayer que reproduzca audio.
Que el usuario use algún servicio nativo de audio, como el de música o los resúmenes de noticias.
Que el usuario reinicie el dispositivo.

Requisitos para reproducir una audio

Lo que se le proporciona a Alexa para reproducir el audio es una URL que tiene que cumplir ciertos requisitos:

El fichero tiene que estar alojado en un endpoint accesible por https en el puerto 443.
El servidor web debe presentar un certificado SSL válido y de confianza. La mayoría de servicios de almacenamiento son validos como S3 o Dropbox. Yo he usado ambos sin problema.
Si lo que se envía es la URL de una playlist, lo anterior aplica a cada elemento de la misma.
Formatos soportados: AAC/MP4, MP3, PLS, M3U/M3U8, and HLS. Bitrates: 16kbps to 384 kbps.

Habilitar la interfaz de AudioPlayer en tu skill

Para que un skill pueda usar la interfaz de AudioPlayer primero tenemos que activarla en el listado de interfaces posibles a implementar. Desde la Alexa Developer Console, dentro de la skill, vamos a Custom > Interfaces.

Al activarla veremos que se añaden dos nuevos built-in intents, predefinidos por Amazon, para las acciones de pausar (Amazon.PauseIntent) y de reanudar (Amazon.ResumeIntent). Estos los tendremos que tener en cuenta de forma obligatoria en nuestro back y manejarlos correctamente. Cualquier cosa que se nos pase la detectarán en el proceso de certificación y nos informarán.

Aparte de estos dos built-in intents obligatorios se recomienda que una skill de audio controle sin fallar otros tantos intents listados en la documentación oficial de Alexa. Estos otros intents no hay que definirlos en el modelo de interacción, simplemente manejarlos en el back.

En mi caso no los he controlado nunca todos y eso no ha supuesto un problema en el proceso de certificación. Serían:

AMAZON.CancelIntent > Lo he usado para cancelar el audio que en ese momento esté sonando.
AMAZON.LoopOffIntent > No lo he usado. Sería para desactivar la reproducción en bucle.
AMAZON.LoopOnIntent > No lo he usado. Sería para activar la reproducción en bucle.
AMAZON.NextIntent > Lo he usado, en la skill del informativo de Ángel Martín, para reproducir el resumen del día siguiente, a modo playlist.
AMAZON.PreviousIntent > Lo he usado, en la skill del informativo de Ángel Martín, para reproducir el resumen del día anterior, a modo playlist.
AMAZON.RepeatIntent > Lo he usado para repetir desde el principio el audio que estuviera sonando en el momento.
AMAZON.ShuffleOffIntent > No lo he usado. Sería para desactivar el modo aleatorio.
AMAZON.ShuffleOnIntent > No lo he usado. Sería para activar el modo aleatorio.
AMAZON.StartOverIntent > Lo he usado para repetir desde el principio el audio que estuviera sonando en el momento.

En el siguiente post comenzaré a explicar cómo manejar en back cada uno de los tipos de interacciones que hemos visto aquí: built-in intents, eventos del playback y comandos del reproductor.

Hay bastante chicha con todo el AudioPlayer y nos dará para unos cuantos artículos. Cero aburrimiento :)

Creando una Alexa Skill de video en cuestión de minutos (Java/Kotlin edition)

Joaquín Engelmo (a.k.a. Kini) — Wed, 09 Dec 2020 09:46:19 +0000

En el artículo anterior contaba cómo hacer una skill de audio en pocos pasos usando un template del back ya generado en Kotlin. También hice un vídeo contando el proceso.

A raíz de ese ejemplo de skill se me ocurrió aplicar el mismo concepto para crear una skill que reproduzca un vídeo, por cubrir el otro elemento multimedia en un dispositivo Alexa. He creado uncódigo base a modo de plantilla para tener una skill muy simple que reproduzca un vídeo a partir de una URL pública, hosteando el back en AWS Lambda.

En este post voy a contar cómo crear esa skill paso a paso (sin entrar en el código o en el proceso de distribución ni certificación). Si hay muchos conceptos que desconoces puedes ver mis primeros posts, que cuentan gran parte de la teoría. El código está liberado y con licencia GPL-3.0. Hay pasos que son pura configuración y burocracia de trabajar con AWS pero no son complicados.

Crearé también un video sobre el proceso, así que si te da pereza leer, puedes esperarte a la película ;)

Casos de uso

Con una skill de este tipo, con el código base, se puede crear una skill que reproduzca un video al que se debe acceder a partir de una URL pública, HTTPs y en uno de los formatos soportados documentados aquí.

En el ejemplo vamos a hacer uso de la VideoApp Interface de Alexa, que permite reproducir un vídeo en un dispositivo con pantalla. La limitación es que no se pueden encolar varios vídeos, algo que se podía hacer con el audio. Si queremos hacer cosas más elaboradas con vídeo ya habría que crear algo usando APL. Lo tengo en la recámara también, espero no tardar mucho en poder contaros cómo :)

De todas formas ese vídeo vamos a poder "cambiarlo en caliente", sin desplegar código, porque lo he creado usando variables de entorno en AWS Lambda. Así como el vídeo, podrás configurar otros dos campos que son obligatorios: título y subtítulo.

No tiene opciones para personalizar respuestas de Alexa porque en principio el caso de uso está orientado a reproducir el video con simplemente arrancar la skill y, aunque tiene un intent por ser obligatorio, invocarlo de forma one-shot tendrá el mismo resultado que arrancar la skill con un launch request. Si el dispositivo que ejecuta la skill no tiene pantalla, Alexa informará al usuario.

Una vez esté reproduciéndose el vídeo Alexa toma el control de forma nativa. De esa forma vamos a poder realizar acciones táctiles, con un mando o con la propia voz. Por ejemplo podremos pararlo, avanzar unos segundos, volver al inicio del vídeo, etc.

Creando la skill en la Alexa Developer Console

Lo primero que tenemos que hacer es crear una skill y para ello podemos hacer uso de la Alexa Developer Console. Ya tengo otros posts donde se cuentan los pasos iniciales, por lo que no me voy a repetir aquí pero como resumen:

Crearse una cuenta de desarrollador de Amazon Alexa.
Crear una skill desde la Alexa Developer Console que sea de tipo Custom y provisionaremos el back por nuestra cuenta.

Elegimos la plantilla básica para el modelo de interacción. Luego vamos a sustituir lo que se cree, entonces no será problema.

Elegimos el invocation name.
El modelo de interacción creado ya tiene un Intent custom que se llama HelloWorldIntent. Vamos a sustituir ese Intent por uno propio. Es cierto que para usar esta skill no vamos a necesitar un intent pero es obligatorio tener uno propio. En el editor JSON sustituimos el código de ese intent por:

Al ser una skill que va a reproducir un vídeo tenemos que activar la interface de VideoApp o nuestra skill fallará al intentar reproducirse en un dispositivo.

Llegados a este punto deberíais poder construir el modelo de forma exitosa. Nos faltaría el paso de declarar el endpoint correcto pero eso lo haremos después de configurar la función lambda.

Creando la función AWS Lambda

Al igual que antes ya había explicado en posts anteriores cómo crear una función lambda para usarla como endpoint de nuestra skill. Voy a resumir los pasos:

Nos tenemos que crear una cuenta de desarrollador de Amazon para los servicios AWS. Así tendremos acceso al servicio de AWS Lambda (entre otros).
Creamos una función (ojo con la región, para España la mejor opción actual es la de París). El código de mi proyecto está en Kotlin con lo que seleccionaremos el lenguaje Java 8 (es donde lo tengo ya probado). Vamos a crear también un rol nuevo a no ser que ya tengas uno de antes con permisos correctos para el lambda y los logs de CloudWatch.

Desplegando el código de la función lambda

Llegados a este punto tenemos que generar un paquete para desplegarlo en la función lambda. Aquí hay dos opciones:

Se puede construir en local a partir del código en el repositorio ejecutando la task de Gradle de shadowJar. Esto generará un fichero .jar en el directorio build/libs con el nombre alexa-skill-video-1.0-all.jar.
Coger el paquete ya generado y que he metido en la raíz del repositorio con el nombre de alexa-skill-video-1.0-all.jar.

Una vez tenemos el paquete hay que desplegarlo en la función lambda. Aquí lo vamos a hacer a mano pero hay formas de integrar en Gradle esto.

Ahora pasamos a la configuración básica de la lambda (controlador, memoria, etc). Desde la última vez que lo usé he visto un cambio en la interfaz de la consola web de AWS Lambda y han separado en dos partes distintas indicar el controlador de otras opciones como la memoria.

Lo primero que hacemos es indicar el controlador poniendo la ruta tal como está en el código fuente: com.kinisoftware.videoSkill.VideoSkillStreamHandler

La memoria se puede bajar a 256 (incluso sobre 200) pero creo que cada ejecución usaba 160 o así (eso se puede ver en los logs).

Enganchando la skill

Ahora ya podemos pasar a enganchar la skill con nuestra función lambda. En la Alexa Developer Console habíamos dejado sin modificar la parte del endpoint. Eso es lo que vamos a preparar.

Copiamos el skill id desde la Alexa Developer Console > Endpoint. Ese id lo vamos a meter en la parte de la lambda.

Añadimos el trigger de Alexa en la función lambda. Y le ponemos el id de la skill.

Copiamos el ARN de la función lambda que será lo que llevemos al campo del endpoint en la Alexa Developer Console.

Y al guardar el endpoint se validará esto que acabamos de configurar de tal forma que sabremos si está todo bien.

¿Y dónde se indica la URL del video a reproducir?

Como os contaba antes, solo vamos a poder configurar un vídeo a reproducir. Además, junto con el vídeo vamos a poner un título y un subtítulo. Para ello vamos a usar variables de entorno.

En la zona de variables de entorno simplemente tenemos que añadir la variable con clave videoUrl y el valor será la URL que contenga el video.
De la misma forma, para el título usamos la variable title y para el subtítulo la de subtitlte.

Una vez tengamos la(s) variable(s) creada(s) y guardada(s) ya podremos usar nuestra skill. Para probarla necesitamos un dispositivo con Alexa que tenga pantalla (aquí el móvil no vale). Con el simulador no vamos a poder ver el vídeo ni inspeccionar que la respuesta es correcta porque al no ser compatible con VideoApp Interface, no se enviará la reproducción del vídeo desde el back.

One more thing...

Cuando haces una skill que reproduce un vídeo surge el reto de la resolución y el tamaño del vídeo. Si pones un vídeo muy pesado o con una resolución muy grande es posible que no tenga mucho sentido si la mayoría de dispositivos de tus usuarios no lo van a aprovechar. Y viceversa, si te basas en resoluciones pequeñas te puedes llevar una sorpresa si un usuario le da por invocar la skill con un FireTV.

¿Cómo puedo saber que dispositivos/resoluciones tienen mis usuarios?

En el template del backend de esta skill he metido un log adicional para así conocer la información del context, que es la parte de la request que nos da eso. Esto solo lo voy a meter como log si el dispositivo es compatible con la interface de VideoApp. Para los dispositivos que no la soporten no tiene sentido conocer esa info para nuestro caso.

Una vez vayamos teniendo usos de la skill vamos a poder usar esa información del context para identificar, por ejemplo, la resolución soportada por los dispositivos de los usuarios. Esto lo podemos hacer con una consulta en CloudWatch:

| stats count_distinct(System.user.userId) as devices by Viewport.currentPixelWidth
| filter @message like /(Context)/
| sort by devices desc

Y ya solo tendríamos que rellenar la info de distribución de la skill y mandarla a certificar :D

Para cualquier error no dudéis en contactarme por aquí o por twitter. Igualmente recordad que se pueden ver los logs de la AWS Lambda en la zona de "Monitorización" y ya está el código preparado para meter ahí peticiones y respuestas ;)

Creando una Alexa Skill de audio en cuestión de minutos (Java/Kotlin edition)

Joaquín Engelmo (a.k.a. Kini) — Wed, 11 Nov 2020 10:01:47 +0000

A raíz de la skill de "El informativo de Ángel Martín" he tenido varias preguntas relacionadas con la creación de una skill que simplemente reproduzca una URL con audio. Pensando en eso, sin entrar en complejidad de fechas que tiene la skill del informativo, se me ha ocurrido crear un código base, a modo de plantilla, para tener una skill muy simple que reproduzca audio a partir de una URL pública, hosteando el back en AWS Lambda.

El proceso en este caso se podría hacer también con Alexa-Hosted y Node.js. Haré otro post para eso pero por ahora quería aprovechar lo que ya tenía en Kotlin. He creado también un video sobre el proceso, por tanto, si te da pereza leer, puedes ver la película ;)

Casos de uso

Con una skill de este tipo, con el código base, se puede crear una skill que reproduzca un audio al que se debe acceder a partir de una URL pública, HTTPs y en formato MP3 (hay más formatos soportados documentados aquí pero este parece la opción más segura).

Se podría crear una radio, por ejemplo, si tenemos una URL que haga streaming continuo o podemos ir cambiando la URL del audio "en caliente", sin desplegar código, porque lo he creado usando variables de entorno en AWS Lambda. Además le he metido la opción de tener otra variable de entorno para un audio de "fallback" por si falla el audio principal por algún motivo.

No tiene opciones para personalizar respuestas de Alexa porque en principio el caso de uso está orientado a reproducir el audio con simplemente arrancar la skill y, aunque tiene un intent por ser obligatorio, invocarlo de forma one-shot tendrá el mismo resultado que arrancar la skill con un launch request.

Una vez esté sonando el audio vamos a poder pararlo y continuarlo con "Alexa, para" y "Alexa, continúa" respectivamente.

Creando la skill en la Alexa Developer Console

Lo primero que tenemos que hacer es crear una skill y para ello podemos hacer uso de la Alexa Developer Console. Ya tengo otros posts donde cuentan los pasos iniciales por lo que no me voy a repetir aquí pero, como resumen:

Crearse una cuenta de desarrollador de Amazon Alexa
Crear una skill desde la Alexa Developer Console que sea de tipo Custom y provisionaremos el back por nuestra cuenta

Elegimos la plantilla básica para el modelo de interacción. Luego vamos a sustituir lo que se cree entonces no será problema.

Elegimos el invocation name

El modelo de interacción creado ya tiene un Intent custom que se llama HelloWorldIntent. Vamos a sustituir ese Intent por uno propio. Es cierto que para usar esta skill no vamos a necesitar un intent pero es obligatorio tener uno propio. En el editor JSON sustituimos el código de ese intent por:

Al ser una skill de Audio tenemos que activar la interface de Audio Player o nuestra skill fallará al intentar reproducirse en un dispositivo.

Llegados a este punto deberíais poder construir el modelo de forma exitosa. Nos faltaría el paso de declarar el endpoint correcto pero eso lo haremos después de configurar la función lambda.

Creando la función AWS Lambda

Al igual que antes ya había explicado en posts anteriores cómo crear una función lambda para usarla como endpoint de nuestra skill. Voy a resumir los pasos:

Nos tenemos que crear una cuenta de desarrollador de Amazon para los servicios AWS. Así tendremos acceso al servicio de AWS Lambda (entre otros).
Creamos una función (ojo con la región, para España la mejor opción actual es la de París). El código de mi proyecto está en Kotlin con lo que seleccionaremos el lenguaje Java 8 (es donde lo tengo ya probado). Vamos a crear también un rol nuevo a no ser que ya tengas uno de antes con permisos correctos para el lambda, los logs de CloudWatch y escritura/lectura en DynamoDB.

Configurando los servicios para usar DynamoDB

Este tipo de skills necesita de persistencia para manejar la acción de "retomar el audio" (pausa/continúa) desde donde lo dejaste si lo paras en algún momento. Para eso haremos uso de DynamoDB.

Por tanto hay dos cosas que debemos hacer:

Añadir los permisos de lectura y escritura en DynamoDB al rol que se creó al crear la función lambda. Para eso desde la pestaña de "Permisos" accedemos a los detalles del rol y le asociamos la política correspondiente.

Crear la tabla previamente o la primera ejecución de la skill fallará porque no estará la tabla creada. Nos vamos al servicio de DynamoDB y creamos una tabla con el nombre que ya está configurado en el código de la lambda skill-audio.

Desplegando el código de la función lambda

Llegados a este punto tenemos que generar un paquete para desplegarlo en la función lambda. Aquí hay dos opciones:

Se puede construir en local a partir del código en el repositorio ejecutando la task de Gradle de shadowJar. Esto generará un fichero .jar en el directorio build/libs con el nombre alexa-skill-audio-1.0-all.jar.
Coger el paquete ya generado y que he metido en la raíz del repositorio con el nombre de alexa-skill-audio-1.0-all.jar.

Una vez tenemos el paquete hay que desplegarlo en la función lambda. Aquí lo vamos a hacer a mano pero hay formas de integrar en Gradle esto.

Ahora pasamos a la configuración básica de la lambda (controlador, memoria, etc):

Hay que poner la ruta del controlado tal como está en el código fuente. Habría que cambiarla a: com.kinisoftware.audioSkill.AudioSkillStreamHandler
La memoria se puede bajar a 256 (incluso sobre 200) pero creo que cada ejecución usaba 160 o así (eso se puede ver en los logs).

Enganchando la skill

Ahora ya podemos pasar a enganchar la skill con nuestra función lambda. En la Alexa Developer Console habíamos dejado sin modificar la parte del endpoint. Eso es lo que vamos a preparar.

Copiamos el skill id desde la Alexa Developer Console > Endpoint. Ese id lo vamos a meter en la parte de la lambda.

Añadimos el trigger de Alexa en la función lambda. Y le ponemos el id de la skill.

Copiamos el ARN de la función lambda que será lo que llevemos al campo del endpoint en la Alexa Developer Console.

Y al guardar el endpoint se validará esto que acabamos de configurar de tal forma que sabremos si está todo bien.

¿Y dónde se indica la URL del audio a reproducir?

Para esta skill básica de audio decidí que solo iba a manejar un audio, es decir, una URL, pero que se pudiera cambiar sin tener que tocar código. Para ello lo que tenemos que hacer es indicar la URL por una variable de entorno de la AWS Lambda.

En la zona de variables de entorno simplemente tenemos que añadir la variable con clave audioUrl y el valor será la URL que contenga el audio.

He añadido la opción de indicar también un audio de fallback en el caso de que haya algún error. Para eso tenemos que añadir la variable de fallbackAudioUrl de la misma forma que la anterior.

Una vez tengamos la(s) variable(s) creadas y guardada(s) ya podremos usar nuestra skill. Para probarla podemos usar el simulador de la Alexa Developer Console o un dispositivo con Alexa (ya sea un Echo o la aplicación de Amazon Alexa para el móvil). Con el simulador no vamos a poder escuchar el audio pero si inspeccionar la respuesta de la skill para ver si ha lanzando la operación de play contra la URL correcta:

Para escuchar el audio tendremos que probar la skill en un dispositivo Alexa o en la aplicación del móvil.

Y ya solo tendríamos que rellenar la info de distribución de la skill y mandarla a certificar :D

Profundizando en APL: Pager y navegación por voz

Joaquín Engelmo (a.k.a. Kini) — Tue, 27 Oct 2020 10:59:19 +0000

Hacía mucho que no escribía un artículo y ya iba teniendo ganas :)

Han pasado 6 meses de pandemia, eventos online, retransmisiones por Twich y muchas novedades del mundo Alexa.

Quiero profundizar en algunos temas de APL y voy a usar mi skill de Estrenos de Cine para ello. En este post vamos a ver concretamente cómo añadir un Pager a nuestra skill con APL y cómo añadirle navegación por voz.

¿Cómo ha evolucionado visualmente la skill Estrenos de Cine con APL?

En antiguos post ya conté el paso de la skill de tener salida solo para voz a tener salida para dispositivos con pantalla. He de reconocer que lo que hice en su momento fue muy simple, me faltaban muchos conocimientos y algún que otro copy&paste de skills de ejemplo acabaron en la mía.

Es posible que cuando estéis leyendo este post esa versión ya no esté en producción y esté la que voy a contar ahora (o una incluso posterior). Por eso os pongo por aquí un gif de cómo era esa versión inicial de la skill con APL:

Y con lo que voy a contar en este post, le he dado un lavado de cara que pinta así:

Además del cambio visual quise añadirle navegación por voz, simplemente por probarlo y jugar con eso.

Añadiendo APL Pager

Desde que metí APL a la skill siempre quise añadir el póster a la respuesta por pantalla. En realidad a nivel de arquitectura de información no ha cambiado nada aparte de llegar la imagen. Los otros dos campos por cada película son los mismos de antes: título y fecha de estreno.

Hay un par de soluciones provistas por APL para hacer "un tipo de carrusel":

Sequences > te darían algo como lo que tenía en la versión inicial: un carrusel por el cual puedes hacer scroll. A ese carrusel le podría haber añadido la imagen y haberlo usado perfectamente. Así a la vez normalmente tendrías más de un elemento visible.
Pager > es un carrusel pero a pantalla completa. Es decir, tienes un elemento de carrusel en cada momento. Mi intención era crear una experiencia de "showroom" y por eso opté por esta opción.

La idea de esta primera evolución visual es darle un lavado de cara aprovechando las pantallas con el detalle de la imagen.

Antes de entrar en detalle técnico del Pager quería decir que la imagen usa el componente AlexaImage en vez de APL Image. El primero sería como una versión vitaminada del segundo con temas como responsive entre otros. Veréis el código y por eso no merece la pena explicar mucho más de esta parte.

Eso si, no seáis como yo. Leed bien la documentación porque la URL tiene que cumplir ciertos requisitos y me tiré un tiempo para descubrir por qué a mi no me hacía render en el Echo Show pero sí en el simulador :D

Documento APL

Yo ya usaba un componente Sequence para el listado vertical de estrenos. Lo que hice fue reestructurar un poco el layout para meter el Pager ocupando todo el ancho y la parte de alto restante de la cabecera y el footer (del footer os hablo luego).

El resto, los params de entrada y tal, es todo igual que lo que había ya antes. Es casi cambiar un componente por el otro. Fijaos en que tiene un "id" definido. Esto lo usaremos luego para la navegación por voz.

En el back no hay cambios que hacer para empezar a usar este componente. Si el dispositivo que tienes es táctil o tienes mando, podrás pasar de página sin hacer nada más.

Añadiendo navegación por voz

A modo experimento quería añadir la capacidad de navegación por voz a la skill. Con navegación me refiero en este caso a pasar de página diciendo a Alexa: "Alexa, siguiente estreno", "Alexa, siguiente", etc

Aunque para este caso de uso puede no resultar muy interesante, sí que creo que puede haber otros casos de uso (en la cocina por ejemplo) donde tengas alguna skill con Pager y se pudiera implementar esto así.

Para el experimento implementé la capacidad de "navegar hacía el siguiente elemento" pero no "navegar hacía el anterior" aunque aplica lo mismo que voy a contar y sería bastante simple. Comentar relacionado con esto que el Pager tiene distintas configuraciones para la navegación:

normal – Por defecto. Te puedes mover libremente hacía adelante o atrás.
none – El usuario no puede cambiar de página. En este caso se usa un comando, AutoPage, para moverlo de forma programática.
wrap – Aun no he conseguido ver la diferencia entre este modo y el modo normal :D
forward-only - Solo te puedes mover hacia delante.

A nivel del documento APL no hay que añadir nada para tener navegación por voz, todo el peso aquí recae en el modelo de interacción y el back.

Interaction Model

Para reconocer la acción vocal de avanzar en la paginación tenemos que crear un nuevo intent y meterle los utterances correspondientes:

Backend

Ahora la parte más interesante de esto. Desde el back tenemos que hacer varias cosas para que todo funcione. Pero, antes de eso, voy a contar un concepto nuevo que vamos a usar: APL Commands.

Los APL Commands nos permiten cambiar la presentación, visual en este caso, de la skill en el dispositivo. Os pongo el link a la documentación oficial y me voy a centrar en los dos que nos interesan hoy:

AutoPage: este comando permite configurar la transición automática de cada elemento del Pager. Permite configurar el delay de comienzo y cada cuánto tiempo cambia de elemento.
SetPage: este comando permite cambiar el elemento representado en el Pager indicando o un valor relativo (desde donde estás se mueve N posiciones) o un valor absoluto (se mueve al índice que se le indique).

En mi caso, al querer hacer navegación por voz, con una transición hacía delante de los estrenos, opté por usar el comando de SetPage de forma relativa. Esto lo podemos ver en el código del handle para nuestro nuevo NextPageIntent:

En el método handle es donde está toda la magia y creamos una respuesta que ejecutará el comando de SetPage. Al comando le vamos a decir que usaremos posición relativa y que el valor a mover será 1. Con ese valor podemos jugar para distintos efectos como saltarnos elementos (con un 2 nos saltamos uno por ejemplo), ir hacía detrás (con un número negativo), etc.
Necesitamos indicarle el id del componente Pager sobre el cual queremos ejecutar el comando. Este id será el mismo que le hayamos puesto en el documento APL.
Por último, indicar un token es obligatorio. Este token es el mismo con el que se hace el comando de RenderDocumentDirective del documento en pantalla. De esta forma queda relacionado el documento donde está el componente sobre el que tiene que aplicar el comando. Yo no hacía uso de ese token por lo que tuve que añadirlo en los dos handlers donde se crea el documento con los estrenos .withToken("newReleasesSkillAPLToken")

El Footer

Al tener ahora más interacción disponible para el usuario en modo vocal, es recomendable hacer uso de un footer en la skill para dar pistas o sugerencias de interacciones.

Para ello añadí un footer al documento APL con, de momento, una cadena estática que dice "siguiente estreno", para que el usuario tenga una pista de que puede navegar de esa forma.

Para ello he usado el componente AlexaFooter pero lo oculto si el dispositivo Alexa es redondo (el Echo Spot) porque no se ve bien ahí.

Para añadir la "wake word" que cada usuario tenga en su dispositivo le tenemos que añadir una función en el template de datos que ya nos creará la frase hint final.

Y con eso tendríamos la skill funcionando con el Pager y la navegación por voz. Es verdad que en este caso igual no es tan útil pero quería hacer el experimento y ver la complejidad. En una segunda evolución quiero añadir un segundo nivel de detalle para cada película donde tener información concreta como duración, puntuación, sinopsis, etc. Quizás haya información que no sea visual, si la sinopsis es grande igual es mejor que esa parte la dé por voz, y así combinar ambas experiencias. Ya veré qué hago cuando llegue a ese punto ;)

Gestión de atributos en una Alexa Skill (II)

Joaquín Engelmo (a.k.a. Kini) — Tue, 28 Apr 2020 08:39:02 +0000

En el anterior artículo sobre la gestión de atributos hice una introducción básica a los tipos existentes y comenté con algo más de detalle los de Request y los de Session. En este post veremos los que nos quedaban: Persistent attributes.

Como ya conté en el artículo de introducción, los atributos persistentes se caracterizan por tener un ciclo de vida que va más allá de la sesión. Es información que será guardada en el sistema de almacenamiento que configuremos al crear la skill en el back.

Configurando la capa de almacenamiento

Para poder hacer uso de atributos persistentes tenemos que configurar un PersistenceAdapter cuando creamos la skill. Este adapter será usado por el AttributesManager para guardar y leer los atributos persistentes.

Podemos hacer uso de algunos adapters que ya existen en el SDK o podemos crear los nuestros propios siempre que siga la interfaz marcada. Podéis consultarla en la doc oficial.

En mi caso he usado DynamoDB, una base de datos NoSQL de Amazon, como capa de persistencia y el SDK ya te ofrece un adapter que puedes usar y configurar para tus necesidades. Para S3, un sistema de almacenamiento también de Amazon, existe un adapter que podrás igualmente usar.

Cada sistema tiene sus propias opciones de configuración. Los valores que necesites los podrás indicar en la creación del adapter. Vamos a ver un ejemplo básico en código:

Aquí podemos ver:

Un método llamado withPersistenceAdapter al cual tenemos que pasarle el adapter del sistema de almacenamiento ya configurado.
La creación de DynamoDbPersistenceAdapter con la config que nos hace falta. Hay varios atributos posibles que están documentados. Como mínimo requerido hay que indicar el nombre de la tabla. El resto son opcionales.

Un punto importante antes de arrancar nuestra skill con persistencia. En el caso de estar usando AWS Lambda tendremos que configurar los permisos del role para poder leer/escribir en la base de datos. En mi caso añadí un permiso bastante completo que, entre otras cosas, te da acceso a DynamoDB.

Otro punto interesante a destacar es la posibilidad de indicar una función generadora del partitionKey. Si no indicamos nada, ya que es opcional, por defecto el SDK usará el campo completo userId que viene en cada request. Este campo tiene una parte que no varía por usuario y no nos aporta valor al guardarlo. Por eso, en mi caso, hice una función que se queda solo con la parte identificadora del usuario, la parte final de la cadena "amzn1.ask.account.[unique-value-here]".

Uso del AttributesManager con los atributos persistentes

Una vez tenemos configurada nuestra capa de persistencia ya vamos a poder hacer uso de los atributos persistentes en nuestra skill. Al igual que con los otros tipo de atributos vamos a usar el AttributesManager para leer/guardar la información.

Antes de explicar los métodos hay que reseñar que, por temas de rendimiento, el AttributesManager gestiona una caché local. Esto afecta al funcionamiento de los métodos que nos ofrece el SDK:

getPersistentAttributes => lee la información, primero de la caché y, en caso de no tenerla, irá al sistema de almacenamiento.
setPersistentAttributes => guarda la información pero solo en la caché local. De esta forma el método de lectura siempre tendrá los últimos cambios.
savePersistentAttributes => este método es el que realmente guarda la información en el sistema de almacenamiento.
deletePersistentAttributes => este método elimina la información, tanto de la caché como del sistema de almacenamiento final.

Una práctica bastante extendida a la hora de trabajar con atributos persistentes es crear un par de interceptores, uno para la request y otro para la response, que se encargarán de lectura y escritura de los mismos respectivamente. Lo habitual es volcar información a la sesión y trabajar desde ahí.

Para el interceptor de lectura podemos destacar:

Solo carga los atributos persistentes si la sesión es nueva. En caso contrario se supone que ya los debería tener de la primera petición.
Crea la estructura necesaria para volcarlos a los atributos de sesión. En mi caso creé una interfaz para tipar esa estructura y así facilitar su uso en las otras partes de código. De esta forma evitamos equivocarnos al coger los atributos y nos lo valida en tiempo de compilación.
Al final usamos el método setSessionAttributes para, a partir de este punto, trabajar con la información a nivel de sesión.

Para el interceptor de escritura podemos ver:

La capa de persistencia solo se maneja si la response es sobre finalizar la sesión del usuario. De esta forma se optimiza la escritura contra el sistema de almacenamiento.
Recuperamos los atributos de sesión y cogemos lo que necesitemos llevar a la capa de persistencia. Los volcamos a los PersistentAttributes con el método setPersistentAttributes.
Por último, guardamos la info anterior en el sistema de almacenamiento final configurado.

Y con esto tendríamos la información necesaria para usar información persistente en nuestra Alexa Skill. Esta claro que, además de este sistema, podríamos tener nuestra propia conexión con una base de datos y gestionarla a mano. Lo interesante en este caso es ver si el SDK nos facilita un poco la vida y exprimirlo al máximo :)

Programar el back de una Alexa Skill con Typescript

Joaquín Engelmo (a.k.a. Kini) — Wed, 08 Apr 2020 09:12:29 +0000

Gran parte de la comunidad de desarrolladores de Alexa Skills usa Javascript como lenguaje del back con node.js como runtime. Desde luego tiene mucha popularidad y se ha convertido en todo un referente en la industria. En el mundo de Alexa hay más herramientas a día de hoy para JS o incluso el propio SDK de JS va siempre por delante de los otros.

Mis conocimientos de JS son mínimos ya que nunca he trabajado profesionalmente con el lenguaje, si acaso alguna cosa puntual, y me faltan los conocimientos relacionados con el runtime, con el sistema de dependencias, librerías, tooling, etc. Pero ahora me he puesto a aprender Typescript y eso me lleva de cabeza a todo el universo node.js. Al igual que pasa con Kotlin y Java, con Typescript y Javascript vas a tener de la mano la interoperabilidad de ambos lenguajes y todo su ecosistema.

Mi setup para usar Typescript en una Alexa Skill

De momento solo estoy empezando y creando de cero una skill con Typescript. De todas formas, los pasos serán los mismos, ya sea empezar algo nuevo o migrar el back de una skill con Javascript. De echo, en mi caso, yo empecé con una skill creada en base a una plantilla con Javascript.

Ya de paso introduciré brevemente ASK CLI, la herramienta por línea de comandos que ofrece Amazon para la gestión de skills.

ASK CLI

Seré breve ya que no es el objetivo de este post y se puede consultar todo muy bien en la documentación oficial. Alexa Skills Kit Command Line Interface es una herramienta que, mediante línea de comandos, te permite gestionar todo lo relacionado con una Alexa Skill, incluso temas de back como lambda, S3, etc.

En la documentación oficial verás cómo puedes instalarla y configurar todo para su uso. Podrás crear skills a base de plantillas (node.js y python por ahora), ya sean alexa-hosted o no. En el caso de tener el back en AWS lambda podrás también gestionar esto de forma sencilla.

Desde la propia herramienta podrás hacer también deploy de la skill y usar ciertos comandos para probar la skill que te permite iniciar diálogos o simular conversaciones. Además hay herramientas en el mercado que se basan en ASK CLI para construir por encima temas de integración continúa o testing.

Creando una Alexa Skill básica en JS con ASK CLI

Como decía antes, yo partí de una plantilla básica de skill que te facilita usar ASK CLI con el comando new.

En la imagen anterior se puede ver los tres puntos básicos que te pedirá el comando:

Elegir el runtime > por el momento, node.js v10 o python.
Elegir una plantilla > crea la skill basándose en una plantilla previa que puede tener más o menos features ya cubiertas (hay algunas ya con APL). No sólo puedes usar los templates de Amazon sino que puedes usar otros. En la doc oficial lo cuentan. Aquí os dejo una plantilla creada por Xavi Portilla que sigue más o menos la estructura que cuento en este post con Typescript y todo configurado.
Darle nombre a la skill > el nombre que tendrá el directorio que se crea y la skill en el listado de skills de tu Alexa Developer Console.

En la estructura básica que nos crea (yo he eliminado ficheros que no me interesaban) vamos a centrarnos en la parte de la lambda. Para que funcione correctamente tenemos que seguir dos pasos: configurar el proyecto para usar Typescript y configurar el despliegue.

Configurar el proyecto

Aquí debemos configurar todo para que se pueda escribir código Typescript que luego se transpilará a Javascript. Podría bastar con añadir la dependencia en el package.json pero yo he usado GTS, una guía de estilo de Google, que además te configura prettier, eslint, etc. Además, si no tienes Typescript también te lo pone.

Soy consciente de que la magia conlleva un precio y que las decisiones que tome Google sobre esta guía de estilo son cuestionables pero a mi, de momento, me vale. Lo único que hay que hacer dentro del directorio lambda/custom es instalar GTS tal como viene en el readme del proyecto. Esto nos pondrá las dependencias necesarias, creará los ficheros de eslint y prettier, y creará algunos scripts para npm. Además, creará un directorio src donde pondrá un primer fichero index.ts. Me gusta eso de separar los ficheros de "configuración", como el package.json y tal, del código fuente.

El siguiente paso es tan simple como llevar los ficheros Javascript que ya existían en el proyecto al directorio src y cambiar su extensión a ts. Con eso ya tenemos el backend en Typescrit! Esto es así porque Typescript no es más que un superset de Javascript aunque, probablemente, el código que ya existía no vaya a compilar :) Tendremos que arreglar los errores, basado en tipos en su mayoría, antes de poder generar el código final que será desplegado en la lambda.

Configurar el despliegue

Partiendo del proyecto de cero no tenemos información de despliegue de ninguna AWS lambda. Eso lo podemos ver mirando el fichero .ask/config que, en este punto, estará prácticamente vacío.

Con el primer ask deploy se va a crear todo lo necesario para usar AWS lambda como hosting del back. Para que todo funcione correctamente es necesario que tengas configuradas unas credenciales AWS.

Una vez finalice la ejecución del deploy se habrá modificado el fichero .ask/config con la información referente a la lambda. Aquí simplemente debemos indicar el directorio donde estará el código Javascript que se generará desde Typescript. En mi caso, por defecto lo deja así GTS, estará en lambda/custom/build/src. Esto es totalmente personalizable.

Pero no basta solo con el código en ese directorio sino que harán falta el package.json y las dependencias. Para esto os recomiendo mirar el artículo de Javi Mora, que lo explica muy bien y nos enseña algunos scripts para npm muy útiles. Es el artículo que tomé de referencia para toda esta parte del despliegue.

Aunque no está exento de la típica burocracia de configuración, una vez que hemos realizado lo contado en este post, podremos usar Typescript como lenguaje de nuestro back tranquilamente :)

Probando nuestras skills con Alexa Skill Beta Testing

Joaquín Engelmo (a.k.a. Kini) — Tue, 24 Mar 2020 09:25:35 +0000

En este post voy a hablar de uno de los grandes desconocidos dentro de las herramientas que Amazon pone a nuestra disposición para probar Alexa skills: el Beta Testing. Es una pregunta que sale a menudo en charlas y talleres: ¿cómo puedo probar mi skill y hacer que otros la prueben sin tener que certificar? La respuesta en este post :)

Beta Testing

El concepto de Beta Testing no es nuevo y es usado por la industria del software desde siempre. Al final el concepto reside en poner a disposición de ciertos usuarios nuestro producto, ya sea una web, una aplicación mobile, una skill de Alexa, etc. pero orientado a recoger feedback, probar cosas, tener solo ciertas features habilitadas, etc. Hay muchas variantes y aspectos que se pueden tener en cuenta en un Beta Testing.

Y para nuestras Alexa Skill tenemos también esta opción en dos sabores: integrado en la consola de desarrolladores, la que veremos en este post, o en versión de API.

Alexa Beta Testing en la Alexa Developer Console

La herramienta de beta testing de la consola nos va a permitir, como decíamos antes, probar nuestra skill antes de certificar poniéndola a disposición de los usuarios que nosotros decidamos.

Al final puedes hacer lo que se denomina un Friends & Family, invitar a amigos y familiares, y que usen tu skill para que te den feedback y puedas recoger datos de esas interacciones. El límite son 500 invitaciones por skill y tienes la gestión completa de los testers.

Para acceder a la herramienta de Beta Testing tienes que ir a la pestaña de "Distribution", para una skill concreta, en la Alexa Developer Consola. Una vez ahí tendrás que hacer click en la opción de "Availability". Esta claro que el equipo de Amazon tiene que hacer esto más visible ya que hay que navegar por varios sitios hasta encontrarlo.

Para que una skill pueda optar a usar esta herramienta tiene que cumplir algunos criterios que se evalúan. Básicamente, si tu skill pasa los tests básicos para empezar el proceso de certificación, entonces, podrás usar Beta Testing. En la doc oficial dan detalles sobre los criterios específicos.

Si la skill que quieres usar cumple los criterios, podrás acceder a la zona que se muestra en la anterior imagen. Desde ahí gestionarás:

El mail del administrador del Beta Testing que no tendría que ser la misma persona que esté desarrollando la skill.
Añadir invitaciones usando el mail de los testers. Esto lo puedes añadir de diferentes formas. Ahí te pone lo que decía antes del límite de 500 invitaciones. Sobre el tema de no querer usar el mail de los testers o en caso de querer hacer esto más amplio a gente cuyo correo no conoces, una vez habilites el beta testing tendrás una URL que podrás compartir con quien quieras para que formen parte.

Para habilitar la fase de beta testing tienes que incluir al menos un beta tester por mail.

Una vez lo hagas verás cómo aparece una nueva tabla con los beta testers ya añadidos y podrás hacer cosas como mandarles un recordatorio o quitarlos. Además, en la parte superior, aparece ahora la opción de copiar una URL para invitar a gente a probar tu skill.

La gente que use la invitación por URL tendrá que usar una cuenta asociada a un dispositivo Alexa. Esa cuenta se la puede crear en ese momento o usar una que ya tenga. Esta invitación se abre en la aplicación Alexa del móvil si usas la URL ahí o en la aplicación Alexa en el navegador. En cualquier caso saldrá una pantalla como la siguiente:

Y desde ahí podrás aceptar si quieres formar parte. Además te informa que si ya estabas usando una versión de esa skill empezarás a usar la versión en beta testing en las siguientes interacciones.

Si añades los mails de los testers les llegará un correo con:

El link para habilitar la skill.
Un correo en el cual van a poder dar feedback.
Una sección de FAQ.

Una vez que un usuario acepta formar parte del beta testing cambiará su estado y las acciones para gestionar. En este punto lo más interesante es la opción de pedir feedback a los testers.

Con esa opción se le envía un correo al beta tester recordando que el desarrollador de la skill valora mucho su feedback y le pasa el correo directo del mismo para que se ponga en contacto.

Por último, podríamos borrar a un beta tester del programa y sería notificado, igual que en los pasos anteriores, vía correo electrónico.

Con este post quería mostrar una herramienta para poder poner a prueba nuestras skills sin tener que pasar por certificación. Es una opción que mucha gente parece desconocer porque me lo preguntan habitualmente. Creo que con un poco más de visibilidad esta herramienta sería muy usada por todos los developers.

Gestión de atributos en una Alexa Skill (I)

Joaquín Engelmo (a.k.a. Kini) — Wed, 26 Feb 2020 08:02:03 +0000

En el anterior post hablé del concepto de sesión en Alexa y qué tipo de información podemos manejar entre peticiones. Sentar esa base me venía bien para comentar lo que veremos en este post. Parte de esa información que podemos manejar en la sesión son los "atributos de sesión" pero no son los únicos que el SDK nos ofrece.

Tipos de atributos

El SDK de Alexa nos permite gestionar, persistir y recuperar atributos en nuestra skill a varios niveles:

Request: Los atributos de request viven dentro del contexto de una petición al back de nuestra skill. Están inicialmente vacíos en cada petición y son descartados una vez se produce una respuesta al front. Pueden ser de utilidad usados conjuntamente con los interceptores de request para incluir información adicional por cada petición y así tenerla disponible en el handler que toque.
Session: Los atributos de sesión persisten dentro de la sesión de una skill hasta que se cierre. Todas las peticiones realizadas dentro de una misma sesión tienen acceso a estos atributos y viajan en el JSON de request/response. No usan un sistema de almacenamiento aparte y solo están disponibles si se opera dentro de esa sesión. Se descartan cuando la sesión en curso muere. Son especialmente válidos para mantener información sobre la interacción actual del usuario con la skill.
Persistentes: Los atributos persistentes son el siguiente paso y están disponibles en todo momento. El sistema de almacenamiento es configurable, así como la key que se usa entre otras cosas. Para poder usarlos hay que configurar de forma explícita un adaptador en nuestra skill. Sin ese paso obtendremos un error si intentamos hacer uso de ellos. Son la solución usada si necesitamos persistir información que se recuperará en futuros usos de la skill o que serán consultados por otros sistemas.

Haciendo uso de estos atributos desde nuestro código

Para poder gestionar esos atributos en el back de nuestra skill el SDK nos ofrece un AttributesManager. Esta clase expone una serie de métodos que nos permiten recuperar y actualizar todos los tipos de atributos comentados antes.

El acceso al AttributesManager se hace vía el HandlerInput. Veamos con código de ejemplo cómo se maneja cada uno de los tipos disponibles.

Request Attributes

El uso de los atributos a nivel de request es muy sencillo. No es más que un mapa de clave/valor al cual se accede a través del InputHanlder. Pongo aquí un código de ejemplo cualquiera porque yo no lo uso en las skills que tengo.

Session Attributes

El manejo de los atributos de sesión es igual que lo visto para los de request. La diferencia radica en el tiempo de vida de cada uno. Los atributos de sesión estarán disponibles durante todo el tiempo que dure la sesión y viajan en cada ciclo de petición/respuesta.

Para ver su uso voy a usar el código de la skill de ejemplo que preparé para la charla conjunta con Jordi y Diego "Asistentes de voz, una charla para dominarlos a todos". Pensamos en una skill que pudiera servir para ilustrar ciertas features de cada una de las plataformas (Google, Alexa y Microsoft). Lo que hicimos fue un ejemplo básico de aplicación de voz para pedir comida a domicilio.

En esta skill necesitamos ir pidiendo al usuario cierta información dependiendo del contexto o estado en el cual se encuentra la interacción. Por ejemplo, el usuario no debería poder realizar el pedido final si antes no dijo qué comida quiere y a dónde hacer el pedido. Esos flujos de recogida de información los dividimos en distintos intents. Como si una máquina de estado (muy rudimentaria) se tratara usamos los atributos de sesión para persistir esa información e ir controlando el flujo de la skill.

En el código vemos un IntentHandler que recibe la comida que ha indicado el usuario y la guarda como atributo de sesión. Como decía antes el mecanismo es igual al de atributos de request pero cambiando el mapa donde guardamos ese valor. Eso hará que luego esa información persista a través de toda la sesión.

Para recuperar ese valor solo tenemos que acceder a través del mapa. Siguiendo nuestro ejemplo, el usuario ya ha elegido el tipo de comida y el restaurante donde quiere pedirla. El último paso sería realizar la orden de pedido. Una de las características de las aplicaciones de voz es que no fuerzan un flujo de pasos secuenciales y el usuario podría haber llegado al último paso con cierto utterance. Para controlar esto podemos validar los atributos de sesión que tenemos en el handler, ya sea en el método que controla la ejecución, canHandle, o en el método que lo procesa, handle.

En este código podemos ver el handler que realiza el pedido. Para su correcto funcionamiento necesita que el usuario ya haya indicado la comida que quiere y el restaurante. Eso lo controlamos mirando si tenemos esos valores en los atributos de sesión.

Ahora veamos cómo viajan los atributos de sesión entre petición y respuesta. Para eso usaremos la información que nos da el simulador de la Alexa Developer Console.

En la petición inicial no tenemos nada referente a los atributos de sesión. Tal y como contamos en el anterior post, la sesión se crea y se lanza un LaunchRequest al back.

Y en la respuesta del back tampoco tenemos nada referente a los atributos. Aquí por ahora simplemente tenemos el texto que tiene que decir Alexa y el flag que indica si se debe cerrar la sesión.

Sigamos evolucionando en el flujo de la skill y vamos a decirle qué nos apetece comer.

En la petición vemos cómo la sesión ya no es nueva y en la request llevamos el valor del slot correspondiente a la comida. Ese valor lo vamos a persistir en la sesión ya que nos hará falta para el paso final de la orden de pedido. Esto hará que sea parte de la siguiente respuesta al usuario.

Ahora ya ese valor será parte de la sesión durante el tiempo que ésta dure. Si avanzamos en el flujo de la skill veremos cómo aparece ya en la información de la request.

En el anterior JSON ya vemos que el tipo de comida elegido por el usuario anteriormente viaje entre peticiones. Así es como el back podrá hacer uso del valor tal como vimos en el código de los IntentHandler.

Aún nos falta por ver los atributos persistentes pero este post ya se hizo demasiado largo y he decidido dividir en dos el contenido. En el próximo veremos cómo manejar información persistente y elegir entre diferentes tipos de almacenamiento :)