What is a difference when sending push notifications using templates SendTemplateNotificationAsync vs native SendAppleNativeNotificationAsync?
In a back-end we keep a track of device types that users are using. But I don't see what is the point to send native, as template works fine.
Template are indeed a powerful feature, especially when used for personalization.
The disadvantage is that changing the platform-specific payload of a notification requires updating the registration.
Usually template registrations are a good fit for notifications that have always the same format and target multiple platforms
Using native notifications sending might enable you to easily target specific devices, however you can achieve the same goal by using Tags.
The bottom line is that I also see no real value in using the native notifications other than simplicity on the client side development.
I also wouldn't be surprised to find out that the Notifications Hub itself is using the templates to send the native notification (but that is of course an assumption of mine...)
Related
I have used Dialogflow for developing the app for Google Assistant. I have created intents and entities in the Dialogflow web GUI and I'm using a webhook response for further conversation.
Now I want to build a chatbot that is part of an existing Android or iOS app and use the code I already wrote for Dialogflow as part of this. What do I need to be aware of when I do so? It looks like I can use the SDK for that platform or make calls to the Dialogflow REST API. Which is faster or are there any tradeoffs? Can I use the Dialogflow NLP without going over the network?
Note: Dialogflow API V1 is deprecated and will be shut down on October 23th, 2019.
That means that the official Javascript, native Android, native iOS and Cordova clients will stop working since they all use V1. There's no word if and when these clients will be upgraded to V2.
So the best bet right now is to use the REST APIs.
There are a few things to be aware of when moving from fulfillment that was built for Actions on Google to using this to also provide responses for other platforms. Actions on Google expects the responses to be formatted slightly differently, and if you're using AoG specific characteristics (such as a SimpleResponse object or a Card object), then it might not appear for other Dialogflow integrations. So you'll need to go over your webhook code to make sure what you send back works across platforms. Your logic and the Dialogflow UI builder should pretty much remain the same - it is just your backend that might need some work.
To make the call, as you say, you can either do the REST call yourself or use the SDK built by Dialogflow. While the SDK will be slightly faster, since it is using ProtoBuffs instead of REST, the difference will likely be fairly slight in most cases. If you're planning to stream audio, you will likely need to either use the SDK or your own ProtoBuff implementation because REST doesn't handle that as well. If you're just sending text, and are more comfortable with doing REST APIs, then this is a perfectly reasonable approach.
There is no "local Dialogflow" library. All calls have to go over the network. There are other libraries that do Speech-to-Text and NLP locally if that is what you need.
My problem is that I am building a app using parse (http://parse.com) and also a website to support it but didn't find a solution to add the "instant messaging" feature to web (Like facebook messaging)
The app (IOS) has a messaging feature that uses push notifications and works just fine.
What can I use for the web part to emulate that? Is it possible to use long polling somehow? What options are available?
I have tried using cloud code but was unsuccessful
We are working on Chromecast integration into our app. The development agency has one Chromecast and we have one here in office. Both have been whitelisted using the same HTML reciever.
Our agency is sending us test versions (with our App key), but the App is not recognizing our Chromecast (in iOS and Android).
We are guessing that there is an issue with possible multiple app keys running off of the same receiver html?
or
The serial number we provided is incorrect?
Google-cast
It's quite possible to have multiple devices using the same App Key, just register the additional devices and mention the prior key. If there is a problem you can write us at Chromecast-updates#google.com
Is there such a thing as a Spotify remote control API? I want to write an app which lets the user control the Spotify desktop client (play, pause, volume, playlists, etc.) but I can't seem to find any documentation anywhere.
There are iOS and Android remote control apps out there so I'm just wondering how they do it if there isn't an API.
On Mac OS X, Spotify can be controlled 'remotely' (i.e. from other apps) using AppleScript, either using the bundled API or the System Events service.
Here's an example of using the bundled API: https://github.com/activars/spotify-applescript/blob/master/spotify_control.applescript
And another one using System Events (it isn't quite as elegant): http://www.jacktams.net/2010/04/28/spotify-applescripts-version-0-4-3/
Official documentation is a bit thin, although you should be able to use the AppleScript editor's library feature to find out more about the methods offered.
Is there a way to get an app to receive the remote push notification while it is in the background?
I don't want to see the regular (close,view ) notification on my device. i want to go silently into the app - and the app will do it's magic from their...showing it's own AlertView (with custom buttons, and playing the alert sound (even when the device is on mute)
Is that possible?? How can i convince apple to support such scenario?
Update: What about in iOS 5.0? is there going to be a change regarding the push notification mechanism now that it uses the notification center?
Sorry, you probably out of luck. The only idea I have is that you can try to push notifications that only set different badge number (without view and sound) and when you are inside you app download rest of the data. However, I'm not sure how good this idea is.