Jan König
After creating the intent and state structure in the previous step, we're now adding logic to the intents of our Quiz Game Alexa Skill.
Introduction to App Logic in Jovo
Currently, we have the following handlers in our Jovo project:
Let's add some life to the intents. The application logic in Jovo voice apps usually involves two core concepts, data and output. We will take a look at these concepts in this section:
Creating Speech Output
In Jovo projects, we usually use methods like ask or tell to creat speech output. You can find an example in our Jovo "Hello World" project:
In the next few sections, we will convert the typical ASK SDK output to this format. We already did this in step 3 when we turned the LaunchRequestHandler into a Jovo LAUNCH intent:
We will take a look at other advanced output methods (for example, visual output) in the next sections. Let's first investigate the next key concept, data.
Working with Data and Session Attributes
Many Alexa Skills work with session attributes to store session specific data in requests and responses. For example, the askQuestion (find code here) helper method uses them like this:
In Jovo, this concept is called Session Data and can be accessed like this in a handler:
The $session.$data object is automatically stored in the response that is sent back to the Alexa platform, so there is no need to use the getSessionAttributes and setSessionAttributes methods.
The above example could look like this:
However, for readability, you could also keep the attributes variable as a reference to the session data object and do it like this:
First Intent: QuizHandler
Let's go through the handlers in the ASK SDK v2 project and migrate each of them step by step. For now, we will write all the logic into our intent handlers in Jovo. At a later point of this course, we can take a look at modularizing the structure to keep everything organized.
Let's start with QuizHandler (find code here). We will go through all the things that need to be updated compared to the ASK SDK v2 version.
Migrating the Handle Logic to Jovo
Let's first take a look at things that need to be updated in the handle method of the QuizHandler. We can first go ahead and copy all its content to our QuizIntent handler in the Jovo Framework project.
Fortunately, there aren't too many things to be changed. For example, for session attributes, it does not need a lot of updates if we just replace the getSessionAttributes part with this:
The responseBuilder can be deleted:
There is also a difference how states are set in Jovo. The framework stores states in a session attribute called _JOVO_STATE_ to minimize potential conflicts. This is why typically the followUpState or setState methods (they do the same) are used in Jovo:
Also, we don't have the handlerInput object anymore, so we will pass the Jovo context object (this) when calling helper functions:
We will talk about this more in the Updating the Helper Functions section.
There is also a section with visual output that calls the supportsDisplay helper function:
We will leave this out for now and take a look in a later subsection (Adding Visual Output).
The last step is to convert the response to ask:
After this, our QuizIntent handler should look like this:
If we do jovo run in the command line though and test out the QuizIntent in the Jovo Debugger, it throws an error:
This is because we're calling the askQuestion helper method. Let's take a look at this one in the next section.
Updating the Helper Functions
We've already takken a quick look at the askQuestion (find code here) helper method in the introduction above.
Instead of passing handlerInput in to the function in our QuizHandler, we passed the this Jovo context object. To make it work, we now need to update the method to accept this object. this is not allowed, but we can use jovo, for example:
We don't need to care abou the rest, except we need to update the session attributes to the Jovo session data object. We already demonstrated this in the introduction above, but this time, we need to use jovo instead of this:
That's it. Good news: We won't need to update any of the other helper methods for now, as they don't use the handlerInput from ASK SDK v2 (except the supportsDisplay helper which we will delete anyways in a later section).
Testing
Now it should work if we do jovo run and test the QuizIntent in the Jovo Debugger:
In the screenshot above, you can see the speech output and also the session attributes (all elements that have been saved into the response based on the Jovo $session.$data object).
Advanced Migrations
Slot Validation
The DefinitionHandler (find code here) calls a getItem function to get all slot values. In Jovo, you can get the slot (we call it input) values with the this.$inputs object:
The AnswerIntent uses five slots (StateName, Capital, StatehoodYear, StatehoodOrder, Abbreviation), of which only one can be triggered (there is only one slot per utterance). This is why the getItem function can seem a bit daunting. We could either rewrite it to fit the Jovo input structure, or access the request with the this.$alexaSkill.$request method like this:
This way it returns the right output for the following code (visual output will be discussed later):
This is the result in the Jovo Debugger:
Adding Visual Output
The Quiz Game uses visual output in some parts of the app logic. For example, the QuizHandler (find the code here) has the following snippet:
Let's go through thi step by step.
The ASK SDK template has a helper function that is called to make sure the user's device supports display interfaces:
In Jovo, this is a supported feature, which you can access like this:
If you use this feature, you can get rid of the supportsDisplay helper function of the template.
You can initialize display templates (see Jovo Docs for more information) with the templateBuilder. In the code example, ListTemplate1 is used, which we can create like this with Jovo:
Next Step
In the next step (coming soon), we will learn how to structure our app's content into i18n language resource files.