We have an existing set of applications that use Urban Airship for notifications. We want to automate the testing of the server component.
We use automated testing as far as possible. Specifically, I want to be able to validate that when I make a /api/post call for a specific tag, then Urban Airship generates a notification for that tag.
In an ideal world, I'd make a web REST call along the lines of 'return when notification received for tag=XXX or timeout', and validate that the response was what I expected.
Does such a call exist, or can anyone suggest another approach other than including phone hardware?
Charles
There's no end to end callback for any push service since it goes through a variety of other services (APNS, GCM). In other words, you can't do an HTTP request to Urban Airship, then have a call back when the notification is received on the device. The best that you could do, is use Urban Airship's API to do a post call to send the message, then check that the response is a 2XX response. The 2XX response doesn't indicate that the push was received on the device, but it at least validates that UA has received the request to try and send that notification.
Another option that you could look into is using a service such as appthwack: https://appthwack.com/ I'm not sure if they are able to test push notifications, as it looks like they use emulators, but it's worth looking into imo.
Related
I use Twilio's WhatsApp API.
Incoming messages, status updates, are sent to my server via callbacks - standard stuff.
I also use several services which ride on the same callbacks - e.g., Frontapp, Missive, and the like.
What is the best way to 'fan out' callbacks to the other services? Is making a separate HTTP post call to each of the other service, mimicking the format of Twilio's callback the best way?
Intuitively, I shouldn't be able to use HTTP redirect, because it'd only allow me to forward, and not fan out the call. Am I right?
I’d go with a simple function (e.g. Lambda, Zapier, etc.) that will:
receive the webhook from Twilio
respond ‘200’ (otherwise Twilio will try the fallback Url)
replay the payload to other listeners
Your stretch goals could include:
async delivery/retries (write the payload to a DB, listeners pickup on that write and deliver/retry their respective services, independently)
Twilio signature checks (duh)
Happy dev
So I managed to connect to the websocket with my API token and I do get notifications. For incoming calls, I do get a push with all info like so:
{"type":"push","targets":["stream"],"push":{"type":"mirror","source_device_iden":"XXXXXXX","source_user_iden":"ujC7S24sQxw","client_version":206,"dismissible":true,"title":"5555551212","body":"Incoming call","application_name":"Pushbullet","package_name":"com.pushbullet.android","notification_id":"6","icon"
"Big value here"}}
So I can see that call came from 555-1212 (I changed number for privacy) and it all makes sense. However, for SMSs, all I get is a notification that SMS changed. No body field so I can't see where it came from and what the message is. All it says is sms_changed for type:
{"type":"push","targets":["stream"],"push":{"type":"sms_changed","source_device_iden":"XXXXXXXXX"}}
What am I doing wrong? I would like to get the SMS message and sender info so that I can publish it. Any and all help will be greatly appreciated.
This is not publicly documented yet and we might be changing the implementation in the near future so I'm hesitant to make it public. Also I don't know the specifics of the current implementation.
You can view how it works right now by using www.pushbullet.com and looking at the network traffic (in chrome inspector) when you do SMS stuff on the website.
I know that push notifications are being sent from a backend server. Is it possible to send notification from client itself? My application goes like this: It acquires its position using Location services API. once it enters a specific circle, the trigger calls a callback function. What i want to do is to use the callback function to push a notification to the device. Is there any way to do this?
Thank you very much in advance!
If you just want a notification when the app is active in the background, you can use local notifications: https://github.com/katzer/cordova-plugin-local-notifications. The plug-in Javascript has to be modified somewhat to work with a Worklight app, but with some simple modifications it works great, and allows your app running in the background to raise a notification without going through the server side round trip involved when using push.
That said, I implemented an app that did exactly what you are looking for (in my case, I needed some server side processing to figure out what the text of the push message should be) The geo-fence callback called an adapter, providing it with event details and the device ID. The adapter determined what message to send, and used unicast push to send it back to the device.
You can invoke a procedure in the client side. I tried to invoke in the client side with httpAdapter and its working.
If the notification doesn't need to come from the server, you can also create a service that will run in the background and show a dialogbox once it enters the geofence.
If a call is incoming when using a Client Browser (twilio.js) and I am already connected to an active call in the Client Browser. Client Browser doesn't ring or given any indication of an incoming call while I'm already on a call with someone else.
Is this a bug? What can be done about it so I can tell if there is an incoming call? I need to be able to answer that 2nd, 3rd, 4th, etc... incoming call should I have multiple people calling my Twilio number at the same time.
Kind of a late reply but you can use the Enqueue verb to place your callers in a queue, and then use the REST API with a javascript setInterval to list the callers in the queue. After that you can dequeue them with a Dial method or via the REST API.
We have crafted call-center functionality in node using a similar method where callers are placed in a queue which triggers a setInterval loop that monitors the queue for its members, and also looks for available agents to call.
For anyone interested I have solved this problem for myself, but in a different way to what #Ding suggests.
I'm not sure if the API has changed since this questions but you are able to access multiple Connections from a single Twilio.Device(). See this question for more details: Twilio call routing/management for small customer service team
I am using RestKit to request data and perform actions using this data.
Once I have parsed the data and displayed it to the user, they can select an item to initiate playback. When the user has selected the playback the server will respond with a response code, but the server also notifies the app when the playback has finished.
e.g.
client server
request data ->
<-respond with JSON
request_playback ->
<-playback_started OK
<-playback_stopped OK
Hope that the diagram helps out.
I need the App to be aware of changes on the server, in this example playback started/stopped or recording started/stopped.
So basically Is there a way for RestKit to accept a response that is not initiated by a request?
Thanks for your help.
Greg.
You should look into things like 'long polling' or 'reverse AJAX' or 'web sockets'. These are all techniques to be able to leave a connection open to the server and continuously receive responses from the server.
Maybe an alternative cleaner solution is to use Apple's push notification mechanism.