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.
Related
I am with my daughter in the hospital and she is asleep. I would like to leave the room for a few minutes but don't want to upset her if she wakes up (she can't see or move much)
The first thing I though about is leaving the phone in the room and have it play a message if she speaks. I thought about the 'OK Google' type hotwords but I don't think they are customizable.
Any ideas or suggestions?
The Voice Actions API should have what it is you're looking for. There's another post which will lead you in the right direction. Custom Voice Actions from my understanding allow developers to implement their own commands.
However if all you want to do is detect voices and then perform an action, i would go down the route of just detecting a voice. A similar post should have the information you need.
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.
I have a design question about Android app and I am not sure if I can ask it here (If not please advise when I can ask).
I want to make an app where it gets information from a website (or actually make the website push locations to the app). Imagine a webform that has 3 fields (3 trucks locations). I want that everytime I put those values and click submit, The android app on the devices will show the location of the trucks on the map. I am familiar with the google maps so I know how to show 3 dots on the map given the location. I also know how to write HTML code that would do POST/GET upon press of a submit button But the communication and how to initiate this trigger on the app is what I am confused about. So it is more of an architecture design question. I need a starting point to know where to start looking. I hope I delivered my point here.
sooo Any help ?:)
Your talking about setting up push notifications, look at http://parse.com/products/push
This may be a use case for using Google Cloud Messaging (GCM). I have not worked with GCM yet but this is one option.
Another idea is to setup an AlarmManager to schedule the fetching for data. One draw back I can think of is if you set the AlarmManager to be frequent (ex: every 10 minutes) then all those network requests are going to drain the battery quickly.
Another alternative and similar to the polling, is to have a button within the application where the user manually presses to get the latest data.
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.
I am developing one GPS based application. in that i given few default values to user those are phone number which will used to make a phone call. and server address which is used to sent the location data to server.. In this I got 2 major and critical problems..
1) I have hide that default values in regular menu and that should display when user presses some key or combination of keys then only it should display.
2)When ever the Default phone number and server address is changed at provider side that should be updated at user side that should happen through SMS from a specific number in a encrypted format by accepting that SMS those values has to change
Please Any body knows about these things help which are very very very useful to me
Thanks for reading
Lots of good info here.
Having used SMSes to communicate with apps in the past, I highly recommend finding another way if possible. The messages coming in are often gibberish to the user, and practically never contain any information that the user needs to know about. They're confusing and they clutter up the user's phone experience.
I'd recommend using WAP pushes or periodic device-side checks instead. If you have to use SMSes, you may want to consider using the SMS content provider to delete the messages after your application responds to them. It'll still be annoying to the user, but at least you won't be leaving behind garbage in their messaging app. Be aware though that the SMS/MMS content providers aren't published, which means that they're not guaranteed to work, manufacturers can modify them however they want, and they could be phased out in a future SDK release.