Google home to send card to the Google Home app - android

I made a small Google Home App and my service returns a response with a SimpleMessage + Card.
It works perfectly when running the app in the console.actions.google.com simulator. I get the card all good.
But when I test talking to the Google Home, it only sends the text, no trace of the Cards anywhere.
However If i talk to the Google home app on my phone, it does send the card correctly.
Is there something to enable to be able to receive cards sent by Google Home? Is it possible at all?

There is no way to make cards that were sent while the user is talking via Google Home visible, but there are several techniques that you, as a developer, can use if cards are necessary.
First of all - good design suggests that cards should be use to supplement the conversation, not be the focus of the conversation. Make sure the voice conversation itself is important and use the visual elements only when necessary. If your action is overly visual - it may be better suited as a mobile or web app, rather than an Action.
If your device requires a screen, then you can set this in the Action Console when you configure your question. This will, however, prevent it from being used on a Google Home device.
If you don't want to go this route, and want to allow it to be used on a smart speaker, but still take advantage of a screen where it is available, you have a few options.
First is that you can just send the cards. As you've discovered, they won't show up, but they won't cause any problems.
If you want to act slightly differently if a screen is available, you can check for the surface capabilities that the user's Assistant is capable of at that moment. If you're using the node.js library, you can have a command such as
let hasScreen = app.hasSurfaceCapability(app.SurfaceCapabilities.SCREEN_OUTPUT)
to determine if a screen is available and take action based on the variable hasScreen. If you're using JSON, you need to check the array at surface.capabilities or data.google.surface.capabilities to see if "actions.capability.SCREEN_OUTPUT" is one of the available surfaces.
If not, and you get to a point in the conversation where you feel you need to send a visual result, you can also request to continue the conversation on a device that does support screen output.
First, you'll need to make sure that they have a screen available. You'll do this with the node.js library with something like
const screenAvailable = app.hasAvailableSurfaceCapabilities(app.SurfaceCapabilities.SCREEN_OUTPUT);
or by checking the availableSurfaces.capabilities or data.google.availableSurfaces.capabilities parameters in JSON.
If one is available, you can request to continue the conversation there with something like
app.askForNewSurface(context, notif, [app.SurfaceCapabilities.SCREEN_OUTPUT]);
where context is the message that will be said on the Google Home, and notif is the notification that will appear on their mobile device (for example) to let them continue the conversation. If using JSON, you'll need to use a actions.intent.NEW_SURFACE next intent.
Either way, the user will get a notification on their mobile device. Selecting the notification will start up the Assistant on that device and your Action will be called again with parameters that let you check if they are on the new surface. If so - you can send the card.

Related

Wear OS/Android communication method recommendation

I am trying to determine the appropriate communication method between the mobile device and wearable for an application. I have been using notifications, which are ok, but the output is not always formatted the way I want. Example: when I include an image (a simple check mark) with no text, the image does not sit right in the center of the wearable. It's just below for scrolling purposes. Also I cannot control things such as vibration variations for different notifications. Also for future enhancements, I might need multiple smaller images in a single alert.
I have been looking at syncing data items but don't know if it will work for my first scenario and was hoping I could get some advice from the community.
Example:
There are a list of items on the wearable (this will be configurable). Each will have a image/png associated with them. Some items may have the same image. When the item is pressed the image (plus some text potentially) needs to appear on the watch with a specific vibration, then disappear.
A running history will be kept on the mobile app, but is not necessary for the watch. My concern with using the data sync is that this is that this is not really syncing data between the two devices, unless there is a "current item" which is being synced.
Hoping for some guidance from the community.
The Data API is really for keeping persistent items in sync between phone and watch. I'm not clear enough about your app's architecture to be sure if this is your best choice, though your configurable "list of items" sounds like a classic Data API use case. If you're not syncing these items, how will the list appear on the watch?
The Message API is more for one-off event signaling: something has happened on one device that needs to trigger an action on the other, and then it's done. And some of your description does sound more like this scenario... but again, I'm not clear enough about what your app is really doing.
And it's always possible that the you'll use both APIs for different aspects of your app; perhaps sending the configurable list of items via the Data API, then triggering events using Message.
Hopefully that's enough clarity on the two APIs to move you forward. If not, some additional details on your particular use case(s) would probably be helpful.
Edit after clarification in comments:
Your use case is still not entirely clear, but here's what I'd say:
If you're only showing a notification (or equivalent) on the watch at the point that an item on the phone is clicked, use the Message API to send those events.
If your watch app will show what has been clicked - whether just the most recent, or more extensive history - use the Data API to both "send the event" (by updating the DataItem) and maintain that record.

Insert App option to call logs

I am developing an App that need to have an option or should i say a link when user gets the properties or menu list from call logs i.e when a user long press on an entry in call logs of phone. I have trying for hours now but not getting any useful information in internet. Please help.
Adding options to context menus of other apps is really not possible. For your example specifically if you see the Contacts app over there is made by Samsung and this may vary for other OEMs and it is totally up to them how they decide to design their user interactions within their apps.
Another point to this discussion can be related to apps like WhatsApp whose options (like calling) appear in the Phone app itself. This is because it has registered itself as having that ability in its <intent-filter> and the Phone app itself shows all apps with that ability. However, you cannot decide what options the default Phone app shows.

Custom dialler for Internet Calls (Android)

I'm trying to get an idea of what's possible and what isn't in terms of using a custom dialler app for internet calls.
The idea is that the standard Android dialler be used when no internet connection is available, but use a custom-written VOIP dialler / caller app whenever an internet connection is available.
I see that in the Android call settings you can set it to use Internet calling whenever a connection is available. How does this work? Does this simply tell the native dialler app to use internet calling, or is there actually a specific Intent or something that gets fired when an internet call is made so that I can open my custom SIP app?
And also, is the 'standard phone app' icon always linked to the standard phone app, or can you override this phone icon to open your custom VOIP app when a connection is present?
So basically, is there a way to seamlessly and automatically switch between the standard dialler and the custom SIP dialler based on whether or not the phone is connected to the internet?
If not, is this something that could be done by customizing Android?
Thanks,
There are four possible ways of doing what you want that I know of:
1. Replace the Android Dialer
This is hard and a lot of work. The Android Dialer (last time I checked anyway) WAS the telephony stack in Android. So to replace it you have to replace the complete telephony stack (including any public API) i.e. handle all cellular (and now sip) calls in and out of the device. Also the only way to replace it is to root the device as it can't be replaced normally.
2. Provide your own Dialer that is separate to the main dialer.
This has it's advantages that you will never get into "trouble" with anything else.
3. Hook into the outbound call API (ACTION_NEW_OUTGOING_CALL)
This is something that is pretty cool and I haven't seen any other OS allow you to do. Basically you can trap when either the normal dialer starts to dial a number (or when another application starts to dial a number as well) and you can either allow it through, modify it or cancel it. Behavior I've seen from sip clients is that they will cancel the call and put up a selection screen prompting where you want to send the call (sip, cellular or something else).
Here is an example of it's use.
The downsides are:
You can be fighting with other applications to which gets first go. There is a 'priority' setup, but all I've seen is everybody wants to be number one.
On some Android devices where the OEM providers that own Dialer, they don't always fire it!!!
4. Detect when the dialer is shown and show your own dialer in front of it.
This works and does allow you to provide a nicer more integrated feel as you can provide call type selection within the dialer, as well as other custom number lookups but that can be a little tricky to do on some devices.
I would suggest 3 to begin with as it's pretty easy to do and you can get something up going pretty fast. In code that I have worked on, we have done 2, 3 and 4 and also looked into 1.

Why does one app launch faster than the other?

I'm curious about this. I have an app called GoSMS PRO and an app called Contacts+ installed in my phone. They both popup an alert notification when a text message is received. However, GOSMS PRO always beats Contacts+'s popup. I was wondering how this was happening in a programming perspective? Is there a way to give a certain app more preference than the other.
From security and permission side every app from Google Play has similar privilege, if they are not signed by the certificate of device manufacturer. This also means that none of the app will get extra preference.
Some time app do many type of checking/initialization/loading before showing their UI and when this type of things happens apps take longer period to load or display UI.
Most common things people do
Creating and initializing database
Reading database.
User validation (reading file)
Device state scanning(network)
Most common case is database access. I wonder if the app reading Content Provider before showing UI it might take long time depending on your device hardware and number of contacts.
Key strategy would be showing the UI right way and load data in background. Android has lots of Asynchronous api, just to avoid this type of scenario.

Remove or Consume pop up coming after sending SMS

I have an android app which needs to keep sending SMS. My problem is that whenever we send a message we get a pop up showing (your SMS charges and your curent talktime balance in phone). When i send many SMS these pop ups keep getting accumulated one over the other which is undesirable for me. I need a way out to either remove or somehow consume these pop ups.
Any ideas ??
a pop up? Do you mean a toast? or notifications accumulating below the status bar?
You'll have to pardon my seemingly simple question. In the US, I've had multiple Android phones on at least two carriers, and I don't get any such message in any form, but may be that's because I've always had unlimited texting so additional texts do not cost me anything.
I bet you're talking about notifications accumulating in the status bar. So if your carrier is doing that, take a look at the code in the "API Demos" > App > Notification > Status Bar
There in the callback attached to the "Clear Notification" button, you'll find the code you're looking for.
And if I could suggest something, I know that many notifications accumulating on top of each other can be super annoying, but if you can try to consolidate all those notifications into one notification at least with the running count (unless your user explicitly opts out from being notified). This way, you still communicate to the user the most important part of the information - how many texts in total his phone has been sending so far, without completely overwhelming him with many-many notifications about basically the same event happening over and over again.
For those who don't know, "API Demos" is a free application you can download from the Market. And there may be several to choose from, so just pick the one with five stars next to it, but "API Demos" is also the same sample code that comes with different SDKs when you download it with the SDK Manager, and you can access that code when you create a new Android Project with the New Android Project... wizard from within Eclipse and then select the radio button "Create Existing Project from Sample" (or something like that, I don't have Eclipse in front of me, so the wording may be slightly incorrect). And of course, if you don't use Eclipse, you can always find that sample code through the Sample code directory itself.
As a potentially more elegant alternative, or may be just in case your carrier is indeed crude enough to pop up an actual modal dialog every time a text is sent, it may be that your carrier is using a broadcast receiver to trigger those notifications or those dialogs, so if that's the case, and hopefully the carrier isn't using "100" as a priority for its receiver, it may be possible for you to register a receiver with "100", and then kill the broadcast before it propagates to the other receivers. But of course, that's assuming that your carrier designed it that way for you.

Categories

Resources