Alexa-skills-kit-sdk-for-nodejs: How make alexa give the user output then emit a new intent

[GeorgeHosuAdswizz]

Lets say I have the following code:

"NewSession": function() {
this.emit(":tell", "New session");
this.emitWithState("AMAZON.HelpIntent");
},

I'd like for Alexa to speak something to the user (in this case inform him about the start of a New Session) than automatically emit and event that will trigger a new intent (in this case HelpIntent). Is this possible with Alexa ? Is this possible using the SDK ?

I've seen no examples of how to do this but otherwise it seems pretty nonsensical to have an option to emit a new intent in the first place.

[GitTom]

No, you can't do that - it's one to one, responses & intents. What I mean is that you receive 1 intent and you send back 1 response. If you do not mark your response endSession, and if the user says something that matches an intent (yours or system) then you can get another intent within that same session.

You can't get back a 2nd intent from 1 response, and there is nothing your response can do to ensure that you get another intent other then guiding the user to say what you want.

[GeorgeHosuAdswizz]

Fair enough,
But in that case what is the purpose of being able to emit an Intent in the first place ? Is the purpose of something like:

this.emitWithState("AMAZON.HelpIntent");

Simply meant to be a sort of re-direct ?

[GitTom]

Good question - I don't know.

But your skill implementation can not emit an intent. It can only emit a response to an intent.

[GeorgeHosuAdswizz]

Hmhm, that seems rather strange, I mean, I don't actually have a physical alexa, I'm using a test JSON generate from the alexa dev website, but it seems that any handler can simply end with:

emit("nameOfAnotherHandler")

and they will invoke that handler/intent/w.e you want to call it. It does seem a bit couterintuitive and strange indeed.

[nstublen]

When you do something like:

this.emitWithState("AMAZON.HelpIntent");

You can effectively "redirect" within your handler. I have done this to jump between handlers with something like this:

var promptQueue = [];

var launchHandlers = {
    "LaunchRequest": function () {
        promptQueue.push("Welcome to the game.");
        // Continue handling the response as though responding to
        // "StartGameIntent".
        this,emitWithState("StartGameIntent");
    },

    "StartGameIntent": function () {
        this.attributes['game'] = { ... };

        promptQueue.push("Player 1, it's your turn. How old are you?");

        this.handler.state = states.GET_AGE;

        // Welcome the user and ask his age.
        this.emit(':ask', promptQueue.join(" "));
    },

    ...
};

The promptQueue let's me build up a complete response across different intent handlers, then emit the response using ":ask". You can only emit one ":tell" or ":ask" in response to an intent, but you can use multiple emitWithState calls to jump between intent handlers while responding to an intent.

I've found it useful for handling common parts of a response, such as intro text or prompting the user with a question at the end of each response.

[ghost]

@GeorgeHosuAdswizz. Re-iterating @GitTom 's answer above. The SDK and skills framework is designed to support a conversation between an Alexa device and a web service. Since the device must initiate the request, there is no way to programmatically have the skill Emit a 'HelpIntent' unless a request is initiated from the device and said request has not already been responded to.

Regarding @nstublen 's answer -- he's correct. If your skill has been invoked and you haven't yet emitted a response, you can call

this.emitWithState('someOtherIntent')

and dispatch the request to a different intent handler to handle.

I'm closing this for now, feel free to re-open if you have any further questions.

[juh079]

Hi, I still don't really understand the difference between using emit and emitwithstate. In the alexa-sdk github repo example code I see that there are places where they do:

this.handler.state = 'wow';
this.emitWithState('NewSession');

and in other places they simply use emit, like so:

this.handler.state = 'wow';
this.emit('NewSession');

And so I'm not sure when it is appropriate to assign the state and use emit, or assign the state and then use emitwithstate.

[pawan-mittal]

@koumorikun I only see option 1:

this.handler.state = 'wow';
this.emitWithState('NewSession'); works for me

[bcnichols3]

A stateless version of a handler can be accessed intentionally by using this.emit whereas a stateful version is accessed by this.emitWithState. Often I expect a lot of people will only have one version of a handler, so the pattern of assigning state then emitting with state will be very common. But state does allow you to have multiple versions of one handler. This feature's purpose is obvious in the context of AMAZON.YesIntent and AMAZON.NoIntent but there may be other instances where you want the generic, stateless version of a handler without having to jump through hoops to discard then reapply your desired state. this.emit lets you access those generic handlers, without having to reassign state. Note if you're using :ask or :tell, you don't ever need to emit with state. User replies always respect state.

[westlakem]

How do you perform this with the new API? handle(handlerInput)? handlerInput.responseBuilder doesn't have an emit or emitWithState

[joaquinbeltran]

Hi, was anyone able to find an answer to @westlakem question? I'm also trying to figure out how to do this with the new API

[saikiranmun]

is state management possible in new python ask sdk (the one without flask) ?

[tianrenz]

Hi @saikiranmun ,

Let me forward this to @nikhilym .

Regards

[nikhilym]

Hey @saikiranmun , can you please create an issue on the ASK Python SDK repo with more context?

[westlakem]

The recommended way breaks dialog flow. You cannot pass the intentHandler to a "handle" function and then in that other intent have it delegate because the request & slots are of the wrong intent.