I have a requirement wherein, I need to stop user logging out from ICN based on certain condition i.e. if a user is on a specific page of a custom plugin and then clicks on Logout, I need to stop log out event and alert the user. Tried using desktop onLogout event and was able to bring the alert but couldn't stop the icn being logged out. Please help.
The desktop.onLogout is indeed only triggered after logout.
ecm.widget.layout.CommonActionsHandler#actionLogOut is what you're looking for.
Using aspect.around would enable you to alert, cancel and postpone the actual action.
Related jsdoc:
https://www.ibm.com/support/knowledgecenter/en/SSEUEX_2.0.1/com.ibm.developingeuc.doc/doc/JavaScriptdoc/symbols/ecm.widget.layout.CommonActionsHandler.html#actionLogOut
Related
I have a working USSD gateway, messages between the user's device and the app are set.
But there is a particular type of message where I don't want to send any dialog back to the user. When a user puts a sim inside a phone for the first time, an automated USSD call is made - I receive it and handle it, to send a configuration SMS or such.
The thing is, then I don't want to send anything to the user - there is no need for the user to be aware of that call. I didn't succeed to do that up to now. Using type End, Unidirectional or Abort didn't change anything. The message processUnstructuredSSRequest_Response still has a string that will show on screen, needing the user to click the "OK" button.
How can I make this happen ?
Found it. It's the prearrangedEnd dialog attribute, look for it in the doc https://www.restcomm.com/docs/core/ussd/USSD_Gateway_Admin_Guide.html#_attributes
I have AoG action that is logging-in to external backend and once logged in it can control specific appliance via external backend's API. Action basically controls home alarm via commands like arm section XY, disarm section garage, etc. Before getting control to alarm it is necessary to login and this takes considerable time (approx. 20-30 seconds). This is much longer than AoG actually allows resulting in timeouts. I am initiating login as asynchronous operation in actions.intent.MAIN handler (i.e. not waiting for the result of login within handler) and just saying to user to tell the command (arm/disarm garage, etc.) in couple of seconds. I have also implemented push notification which is working fine. Problem with push notification is that it just pops up on mobile phone without any sound & user has to open notifications and tap it. Then it will trigger intent and do requested action.
This is not really good user experience (typically I would like to use my action in the car when coming home and having the possibility to disarm the home alarm without need to touch the phone, tap the notification, etc).
Any idea how to implement it in more proper way? What I would really appreciate is if google assistant could actually re-initiate the conversation & tell me something like: 'hey I am already logged in into alarm service provider, what do you want me to do now?'.
I will be grateful for any advice dealing with similar problem.
I am using ActionsSDK for Node.JS to build my action.
You've already looked at the ways that the Assistant can initiate (or re-initiate) a conversation. Actions are really designed for something that is conversational, and a 30 second pause in the conversation would be awkward.
One other option you have is to use a Media Response as part of your reply to the user logging in (or as part of your welcome intent? Not entirely clear, but the approach would be the same). This would let you play some "hold music" for several seconds. At the end of the music playing, an actions.intent.MEDIA_STATUS would be sent to your Action, which you can use to make sure the login has completed and, if so, respond to the user appropriately.
The only way for AoG to "take initiative of starting a conversation" is through push notifications. There is no way for the assistant to strike up a conversation after a period of time or when an event occur.
Perhaps another way of doing might be to only send push notification if your action fails to execute the long sequence of events and the triggering action could invoke an intent to try again. The assumption would be that everything's fine unless said so.
You could also notify the user that it'll take a couple of seconds to complete the action once it's initated and implement followup intents that handles if the user asks "Is it done?" or "How's it going?". Making it part of the flow to check on progress, but with the assumption that it should be successful.
You can easily dislocate the long running background process by implementing a task queue in Firebase where your intent is creating a child similar to this.
firebase.database().ref("tasks").push({action: "disarm_garage"});
And then you create a cloud function trigger to handle it
functions.database.ref('tasks/{id}').onCreate((snap) => {
const action = snap.val().action;
switch (action) {
case 'disarm_garage':
// ...
break;
}
// Remove the task after processing
return snap.ref.remove();
});
That would ensure that you have enough time to complete the task in background without blocking the conversation.
I have created a google action project with dialog flow and action SDK, webhook and Android app to talk to it. Everything works fine except the "cancel" speech. I am asking user "Say cancel to cancel the order" but it closes the conversation itself.
Really need help here.
When the user says "cancel", AoG's App Exits functionality is triggered. This causes the app to immediately exit. We do this with certain key words (e.g. "exit", "cancel", "stop", "nevermind", "goodbye") so that users are never stuck inside an Action with no clear way to get out.
While you can handle an event that will allow you to return a custom response when an App Exit is triggered, there is no way to prevent this behavior.
To avoid this, you should guide the user towards using different language, or provide affordances such as suggestion chips that will allow them to easily take action.
The Actions on Google design documentation recommends steering clear of "commands", avoiding statements such as Say cancel to cancel the order. Instead, you could ask the user if they'd like to cancel their order and handle yes or no as a response.
I have a Google Action (using API.AI) that is very similar to the Silly Name Maker webhook example.
However, my app was rejected for the following reason:
One or more of your actions does not allow a user to easily exit a conversation. Please make sure that you do not continue to converse with a user if they ask to cancel or exit.
When you say stop, cancel or quit when the mic is open, it responds "Sure, canceled", closes the mic and exits. However, when you try using those commands while the agent is speaking, it does close the mic and exit but it doesn't say "Sure, canceled" as it's supposed to.
My Action is set up like this:
Welcome intent: User is asked for two parameters
Webhook response: Once all the parameters have been supplied, a webhook (structured exactly like this Silly Name Maker webhook) delivers a single sentence and then immediately ends the conversation.
During the Welcome intent, if a user says "Okay Google, cancel" while the agent is speaking, it responds "Sure, canceled" and exits.
However, while the agent is speaking the webhook response (from assistant.tell()), if you say "Okay Google, cancel" it will exit immediately without saying "Sure, canceled."
How do I get the Google Assistant to say "Sure, canceled"? Do I have to set up a "cancel" intent in API.AI, and use an actionMap on my webhook to handle a user's request?
Use assistant.ask(), not tell, then cancel should work. You can have a look at https://github.com/actions-on-google/actions-on-google-nodejs/blob/master/assistant.js
I know this is an old question, but I have an answer nonetheless.
You can trap "Cancel" type requests from the user, if necessary, to play your own 'goodbye' message, as your yellow highlighted request seemed to desire.
(Is that review feedback? Weird...)
As described here:
https://developers.google.com/actions/assistant/app-exits
The basic trick is to setup an Intent in Dialogflow that is configured for the 'event' of "actions_intent_CANCEL".
Set it to 'end the conversation' (or it won't work, I think).
Don't set any example phrases.
Set the desired 'Response', or set it to hit your webhook.
With that setup, you can get "Cancel" requests to say anything you want on app exit, up to a 60-character limit (To allow the user to quit quickly).
Currently, there is no way to open up the mic when you are doing an app.tell() from inside your custom app. So, there's no way to interrupt the response.
Only the phrase "ok google" opens up the mic. So you could add user says for "ok Google" to go to your fulfillment. That way you can handle the interruption in your own app.
My iPhone app includes a subscription service for a web server, which Apple insists that I make available as an in-app purchase. However I not entirely happy about the way the user dialog pans out. Some time after the app submits the purchase to iTunes, the user gets a confirmation request from iTunes. But this could happen at any time after the purchase is submitted.
I am wondering whether my app should pop up an alert, after the submission is made. Is there a standard procedure for this? If the confirmation request comes back straight away, then the user would see two alerts one after the other, which could be confusing. On the other hand, if he is going to have to wait a while, it would be nice to let him know that this is the case.
Is there a standard procedure for this?
I think standard procedure would be to disable user interaction and show a spinner, or otherwise let the user know that the transaction is pending. You can then handle the purchase if it comes back, or implement a timeout and then show a pop-up notifying the user that the transaction could not be completed.
If you really don't want to make the user wait for completion before continuing in the app, I would put your notifying pop-up before you send the request. So when the user presses the button, you pop-up and say "This may take a while", and when they press "OK", THEN you send the request. Personally I don't think this is particularly good UX though, since in the majority of cases it will not take very long.