Profile cover photo
Profile photo
Yoichiro Tanaka
3,615 followers
3,615 followers
About
Posts

Post has shared content
Multivocal 0.9.1 and auth samples now available

There have been a few updates that we didn't release notes for, and these are below. Even bigger is that we have some new sample code - focusing on how to use Multivocal with Account Linking and Google Sign In for Assistant (now generally available).

Multivocal is a library to help you build great agents for the Google Assistant (and other platforms in the future). We take a different approach - letting you focus on what you want to do and say, rather than the boilerplate. Learn more at https://multivocal.info/

As always - we are looking for your feedback. What else can Multivocal help you with?

Updates in 0.8.1
- Added Multivocal.getConfig() to allow non-Multivocal code to access the same resources in the same way.
- The Firebase configuration option now maps vertical lines in keys to forward slashes (in addition to underscores being mapped to periods).
- Bug fixes in the requirement handlers
- Added the ability to register new requirements and handlers
- Improved documentation about requirements and requestors
- Bug fixes in sending cards

Updates in 0.9.0
- Added support for precondition validation
- Added short circuiting for the Actions on Google healthcheck

Updates in 0.9.1
- Bug fix in ssml template function
- Bug fix in preconditions

New samples

We have three new samples available from https://multivocal.info/:
- multivocal-sample-auth0 : Provides an example for using the popular Auth0 Identity service with Mutlivocal and Actions on Google Account Linking. This lets you manage your accounts with Auth0, and gives your users a single sign-in.

- multivocal-sample-auth1 : Uses the newly available Google Sign In for Assistant to get a user's public Google Profile with Multivocal.

- multivocal-sample-auth2 : Builds upon using Google Sign In for Assistant to get the user's permission to access Google's APIs on their behalf. Once they have signed in and given your Action permission, either through the web or through the Assistant, you'll be able to access information about their files in Google Drive.
Add a comment...

Post has shared content
I posted a new blog entry about how to use the End-to-End testing library for the Google Assistant apps. The library is "actions-on-google-testing". You can test your actions with the library automatically by writing a test code to communicate with your actions and validating the response.

http://bit.ly/2um5RFa
Add a comment...

Post has attachment
I posted a new blog entry about how to use the End-to-End testing library for the Google Assistant apps. The library is "actions-on-google-testing". You can test your actions with the library automatically by writing a test code to communicate with your actions and validating the response.

http://bit.ly/2um5RFa

Post has shared content

Post has attachment

Post has shared content
Today we’re announcing the deprecation of the anonymous user identifier feature. This is an important change which may require you to make changes to your Action by June 1, 2019. See more details below.

When we launched Actions on Google, we provided developers with an anonymous user identifier for storing basic state about the user (like preferences, or the number of times they have accessed an Action to remember it for future interactions) without the overhead of maintaining an authentication system. Since then, we’ve launched better tools, like the userStorage API and will soon be adding Google Sign in for the Assistant, to improve the identity experience for your users.

To determine whether this affects your Action, do a code search to see if you are using the anonymous user identifier. With the Node.js client library, look for the id property and if you’re reading raw JSON, look for the userId string.

If you are using the feature, we recommend that you switch to using the userStorage API (https://developers.google.com/actions/assistant/save-data). You can find our migration guidelines here https://developers.google.com/actions/identity/user-info. Any actions that are not updated to use userStroage API or Google Signing will no longer be able to identify returning users (all users will be seen as new users).

We apologize for the inconvenience and appreciate your continued support. We are eager to hear your feedback as we continue to improve Actions on Google. If you have more ideas to share with our team, don't hesitate to join the conversation: https://developers.google.com/actions/support/
Add a comment...

Post has shared content
Today, I posted a proposal to support an action name matching feature for the actions-on-google-nodejs version 2.

In v1, we could register handlers mapped to each action name. However, we could not use the action name matching since v2. Instead, we need to use an intent name to register the handlers. This change was so big. Most developers must pay the large migration cost, and I guess that we lost the flexibility of the architecture between AoG and Dialogflow.

I think that the `app.action` function I proposed brings developers another option. Also, introducing the app.action() function never encumber the current intent name routing behavior. That is, I think that I can continue to keep current compatibility if the app.action() function is added.

If you agree that, it would be great if you post +1 or comment.

https://github.com/actions-on-google/actions-on-google-nodejs/issues/164
Add a comment...

Post has attachment
Today, I posted a proposal to support an action name matching feature for the actions-on-google-nodejs version 2.

In v1, we could register handlers mapped to each action name. However, we could not use the action name matching since v2. Instead, we need to use an intent name to register the handlers. This change was so big. Most developers must pay the large migration cost, and I guess that we lost the flexibility of the architecture between AoG and Dialogflow.

I think that the `app.action` function I proposed brings developers another option. Also, introducing the app.action() function never encumber the current intent name routing behavior. That is, I think that I can continue to keep current compatibility if the app.action() function is added.

If you agree that, it would be great if you post +1 or comment.

https://github.com/actions-on-google/actions-on-google-nodejs/issues/164

Post has shared content
On 19th May, the event "I/O Extended 2018 Tokyo@GDG" was held. I talked about Google Assistant, Actions on Google, the integrating Android and Web with Assistant. I would like to share the slides here. I believe that this I/O was "Assistant I/O", and Android and Web will be a part of Google Assistant ecosystem, and finally Google Assistant will be the next of the internet... Is this a too strong word? :)

https://speakerdeck.com/yoichiro/o-extended-2018-tokyo-at-gdg-assistant
Add a comment...

Post has attachment
On 19th May, the event "I/O Extended 2018 Tokyo@GDG" was held. I talked about Google Assistant, Actions on Google, the integrating Android and Web with Assistant. I would like to share the slides here. I believe that this I/O was "Assistant I/O", and Android and Web will be a part of Google Assistant ecosystem, and finally Google Assistant will be the next of the internet... Is this a too strong word? :)

https://speakerdeck.com/yoichiro/o-extended-2018-tokyo-at-gdg-assistant
Wait while more posts are being loaded