Here’s my final and long overdue post in my Writing an Alexa Skill series; if you want to read the previous entries, here they are:
In the previous part I wrote about adding persistence to the skill so that it can remember which zone a user lives in. That information gets stored into a DynamoDB table which is all fine and good, but what happens when a user no longer wishes to use the skill and disables it?
I needed a way to clear out the database entry when my skill get disabled, and naturally, there’s an event for that. To read all about working with Alexa skill events, you can visit the documentation page here. There were a number of steps I had to go through which I’ll summarize below.
Step 1 — Working with events requires using the Alexa Skill Management API (SMAPI), which is not supported directly in the online Alexa developer console. So step 1 was to get the ASK CLI (Alexa Skills Kit Command Line Interface) and set it up on my system.
Step 2 —Next, I used the ASK CLI’s init command (passing it my skill’s ID) to get the skill’s code downloaded to my system as well.
Step 3 — Up until now I had only been developing my skill using the online Alexa developer console. Now that I’m working with the code locally, I needed an IDE. My goto IDE choice these days is VS Code and not surprisingly, there’s an Alexa Skills Toolkit extension for it.
Step 4 — Now I had everything I needed to add an event to my skill. The event that I’m interested in receiving is the SKILL_DISABLED event. At the end of this step my skill.json had the following section added to its manifest object:
"events": {
"endpoint": {
"uri": "arn:aws:lambda:..."
},
"subscriptions": [
{
"eventName": "SKILL_DISABLED"
}
]
},Step 5 —Lastly, I added a handler for the event in my skill’s code:
And that’s it, now when my skill is disabled it will get notified with an event containing the user’s ID, which the skill uses to remove the corresponding database entry before it fully unloads.
