Is it possible to send progressive response in google_home? - actions-on-google

In alexa custom skill, it is possible send an intermediate response before sending the final response. For example, we can send "Please wait, I am looking for the rental car .." if it takes time to search for the rental car. Is it possible to send such "Please wait.." message in Google home custom action before sending the actual response?

No.
The best you can do is to send a response and include a Media object with it (sorta like "hold music"). When the music is done, your Action will get a MEDIA_STATUS Intent.
Your search needs to run in the background and save its results in a cache of some sort. When you get the MEDIA_STATUS, check the cache to see if results are available. If so, send the results, otherwise, repeat.

Related

Restcomm USSD - do not return a dialog

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

Is there a maximum length or amount of time that a user can respond for (in response to an Action on Google intent)

I see there is a limit that a user has to respond by before the conversation ends:
"Your response must occur within about 5 seconds or the Assistant assumes your fulfillment has timed out and ends your conversation."
How long does it take for the app to time out and exit the conversation
But is there a maximum that a user can respond for (type voice)? We want to allow for longer responses (and then access the response text).
Ideally we would like an unlimited response time and the ability to access the raw input (type voice) when received
It would be excellent if we could access the audio from the user's response, but as I understand that is not possible.
As I explained here, you can't have access to the raw audio recordings of interactions with your actions as of now. You only get access to the transcription of the user's utterance.
The quote you've supplied:
"Your response must occur within about 5 seconds or the Assistant assumes your fulfillment has timed out and ends your conversation."
isn't about the user's response. Your webhook fulfillment must complete in 5 seconds, otherwise, your system persona will time out.
As far as the length of users prompt goes; if the user doesn't say anything it will trigger a no-input prompt (on smart speakers) or just close the mic (on smartphones) in around 8 seconds. (I don't know if there's an official resource that proves 8 seconds, this is just my experience)
But once the user starts speaking, it will keep listening until the user stops talking. So you can theoretically have a long prompt from the user. However, I wouldn't recommend this since it would be a terrible user experience if you look at it from a conversation design stand point.

Email Application, Fetch message previews

I'm working on an email client for iOS. Currently I'm using MailCore for IMAP/SMTP interactions. I'm currently working on getting message previews for the inbox view. The only way I can think to do this would be to actually fetch the whole message body (only body for speed) from the server, and then display only a portion of the message. But then I would have to download the whole message again (this time all headers, etc) when the user opens the message. This seems a bit inefficient to me, but I can't figure out another way to approach this. I've considered just downloading the entirety of each message to begin with, but that seems like an abuse of user's mobile data, and it would be slower to populate the inbox with previews. Any thoughts on how to approach message previews?
Also, for the purposes of this question, assume that the message sender name, date, subject and flags are already loaded on the device.
there exists a raw fetch command but am not sure if there exists any wrapper api on top it.
FETCH 2 (BODY[]<0.size>)
for example if you want to fetch first 100 bytes of mail then you can fire a command as
FETCH 2 (BODY[]<0.100>)

How can my app facilitate a message to multiple friends?

I have a facebook app that needs to allow a user to send a message to multiple friends (potentially all their friends) at once. This isn't any kind of spam, and I don't need the app to send the message incognito (behind the scenes), I just need to open a dialog with specific friends pre-populated (that the user has selected within my app in a prior step) and then send them a custom message. Is this possible? I see the api for sending a message to a single friend, and I see the API for inviting users to my app (but that's limited to some very small number of invitations per day)... what I need is a dialog that lets me send messages to as many of the user's friends as they want, but for me to control *which friends are selected... I don't want to give them control to add/remove from the friends list.
Is this possible?
No, the Send Dialog allows prefilling only a single friend, but would otherwise be the best option here if you need a custom message displayed to the recipient. You could get the user to send to several friends in a loop by prefilling this - or fire the dialog without prefilling and let the user chose who to send to - your app won't receive a callback with the recipient IDs but you could put a referrer param in the URL sent?
Failing that, the Requests dialog / 'invites' are the only thing you can prefill with multiple recipients without the expectation that your app will be shut down for spam shortly thereafter - there's no limit per day on the number of requests sent, but you don't get to set the message shown to the recipient.
In case this is helpful to anyone else, I just found this... it's a relatively new API (still in beta) that allows for (just about) exactly what I was asking for. I've tested it and it appears to work...
https://developers.facebook.com/blog/post/2012/08/31/reach-users-1-1-with-the-notifications-api/

Availability of Push notification service in this situation?

i'm working on a football application. the application connects to a webservice and gets the required data via soap request whenever a tab is opened. one of the tab shows live matches of the current day. when the live tab is opened, it refreshes the view by a timer and shows the status updates (goal scored, half time or full time). what i need to do is getting the status updates when the app is closed. the user will select max 2 competitions from settings of the app. then the status updates about these 2 competitions needed to be alerted. can i use push notification service to send soap requests and make alerts according to the response? or does it only allow getting response? or is there anyway that i can do it?
thanx in advance.
I'm not entirely clear what you are asking. The part where you write:
can i use push notification service to send soap
requests and make alerts according to the response?
or does it only allow getting response?
isn't really clear to me. What response are you talking about?
In any case.. push notification is what is says. It pushes a notification to the iPhone.
It does not:
activate your application in the background
allow for any action of your application without the user opening said application first
allow any kind of data to be gather from the phone
If you want the user's phone to talk to your server, the user will need to open your application. If that's what you're asking.