I'm using this endpoint to subscribe for changes on a file: https://developers.google.com/drive/v3/reference/files/watch. While I'm receiving callbacks, some notifications don't happen right away and others seem to be dropped completely. I'm trying to figure out whether this is an issue with the service or something I'm not understanding about the API.
I've tried testing our setup with several different types of files and have gotten similar results with inconsistent notifications.
Wonder if anyone has done tests or has insider information about the reliability of change notifications? Is it around 99% or more like 50%? What is the expected distribution of delays? (it's definitely not instantaneous)
Without knowing what you have already done, I can only suggest that you check Push Notifications and see if you've missed some of the important things.
It was discussed that, to use push notifications, you need to do three things:
Register the domain of your receiving URL.
Set up your receiving URL, or "Webhook" callback receiver.
Set up a notification channel for each resource endpoint you want to watch.
In addition to that, note that there are required properties when making watch requests:
An id property string that uniquely identifies this new notification channel within your project. We recommend that you use a universally unique identifier (UUID) or any similar unique string.
A type property string set to the value web_hook.
An address property string set to the URL that listens and responds to notifications for this notification channel. This is your Webhook callback URL, and it must use HTTPS.
Also, Drive API will be able to send notifications to this HTTPS address only if there is a valid SSL certificate installed on your web server. Invalid certificates include:
Self-signed certificates.
Certificates signed by an untrusted source.
Certificates that have been revoked.
Certificates that have a subject that doesn't match the target hostname.
Hope that helps.
Related
According to the documentation it should be possible to receive messages from multiple senders, but I have not been able to accomplish this.
To enable this feature, make sure you have each sender's sender ID. When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field, using the token retrieval method for the given platform
This was indeed possible some time ago, by specifying the sender(s) id(s) when getting the token, but it was deprecated and the current getToken() method does not accept a senderId parameter any longer.
I also tried configuring multiple projects in the app, but Firebase Messaging does not seem to support instantiating with a different project name (while Firestore, Database, etc. do).
So my question here, in the current scenario, is how am I supposed to accomplish the reception of messages from different senders. After the deprecation of the senderId parameter in getToken(), is there an official approach to this that I'm unaware of?
Alternatively, is there any other approach you would recommend?
Note: I'm working with Flutter, but according to the documentation the same limitations are valid for native Android (and iOS?)
I have an OpenEdge database, I have created a REST Service and am able to CRUD to it from the outside World.
I have created a Nativescript app that can pull data from the REST service etc, but now i want Push notifications.
I know about the Progress Kinvey backend, and Firebase backend with their push notification features but i don't want to use them.
is there a way to create my own Push notifications on my REST server etc?
So first I would like you to understand how Push Notification works just to make sure we are on same page,
Once your app is installed, you can query for a unique token and save it in your backend for future use. Whenever you want to send a push notification, you have communicate with APNs (Apple Push Notification Server) / FCM (Firebase Cloud Messaging) in order to send a push notification to your iOS / Android device using the unique token you acquired earlier.
So now you must use Firebase as that is the only way you can communicate with Android, yet you may choose to communicate with APNs yourself. But in my opinion, it will be a overhead for you as both have their own protocols, you will have to distinguish your tokens between iOS & Android, use appropriate protocols etc.,
I would suggest you to go with just Firebase plugin (until you are super familiar with APNs already), so you don't have to worry which platform the token belongs to, update / revoke invalid tokens over time etc., FCM has pretty decent APIs & Documentation that can make your life easy here.
i strongly recommend you to see my answer here answer here.
from it:
when you want to pull anything from place_1(e.g. api) to place_2(e.g. browser_client) you most have an identifier of the
place_1_resource (which commonly is the uniform-resource-locator of
api)
when you want to push anything from place_1(e.g. notification_central_server) to place_2(cellphone_client) you most
have an identifier of the place_2_resource
if you don't have any identifier for a cellphone which you want to
send it a notification, your server dont know where to send that
notification so we need a resource_identifier_like for cellphones
which is actually a device_token_like and you have just one approach
to get this device_token_like and that is the FCM/APNS
I am running into an issue with NotificationHubs where occasionally notifications silently fail to get delivered to an iOS client.
My Notification Hub is setup to use token authentication with APNS (as opposed to the legacy certificate authentication).
I updated my notification hub pricing tier to standard so I could get some more information about it. Most of the time (over 95%) notifications go through correctly. I added logging to track the NotificationId of each push notification that was queued with Notification Hubs. Then, when I was alerted of a failure, I went and looked up the details for that specific notification via the following method:
var details = await notificationHub.GetNotificationOutcomeDetailsAsync("<notification id>");
Inspecting the details I noticed that while the State was "Completed" (meaning NotificationHubs had received and processed the operation) the PnsErrorDetailsUri had a non-null value, indicating there was an issue delivering the notification:
Navigating to the value of the PnsErrorDetailsUri in a browser caused the following file to be downloaded:
In here, I noticed that the NotificationSystemError says there was an "InvalidToken". This token seems like it should be related to some "under the covers" communication between Azure and APNS. It is definitely NOT due to the device token registered in NotificationHubs being invalid. I verified that the registrationId was still in notification hubs, and that it pointed to the correct device. In addition, grabbing the raw NotificationBody from the details and re-submitting it with the same tag causes the new notification to be delivered successfully.
Does anyone know what the InvalidToken may be referring to, or what could be the cause of these intermittent NotificationHub delivery failures?
UPDATE:
I have found mention of the different NotificationSystemErrors here, one of them being my InvalidToken error. However, I can't find a description of what the actual causes of these errors are.
I never really got a definitive answer why the error was happening, but I appear to have been able to resolve my issue.
We have 2 separate notification namespace/hub, one for apple production notifications and one for the apple sandbox notifications. We have a switch in place so devices register with the correct hub. I investigated all of our registrations, and they all looked to be in the correct location.
However, during this inspection I noticed that many devices had a large number of registrations. Each of these registrations had the SAME apple PNS identifier (which was a valid token), but it seemed odd to me that there were dozens (in one case hundreds) of the same PNS token registered. Each RegistrationID was the same, except it has a hyphenated incremented number after it (for instance, 1231231231235396312-6910179870480973035-1, 1231231231235396312-6910179870480973035-2, 1231231231235396312-6910179870480973035-3, etc.). It looks like each time I call NotificationHubClient.CreateAppleNativeRegistrationAsync, it is adding a new entry without de-duping. Clearing out these duplicate items seems to have resolved the issue I was encountering. Seems like NotificationHubs was getting confused sometimes with too many registrations being linked to a device.
I ended up adding some code on my end to attempt to filter out duplicates for the time being. However, I would expect that NotificationHubs should be handling this for me...
I want to allow people to privately share data with each other using their contacts list to select people to share with. I'm planning on using Push Notifications to notify others that they have been shared with, but how can I handle those that do not have the app installed?
The cases are that I have their phone # and/or email. I can simply send them a message saying "X wants to share Y with you", but how can I determine if I need to send a Push Notification or an email/text?
If you're looking for API then you're out of luck. You can always collect this personal data server-side with agreement of your users. There you can also manage groups and other community relations.
Check here:
https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
The crux of it though will be that you will need to store a token when the device is registered anyway to be able to send notifications to them, so you can use that.
And using The Feedback Service alluded to in the documentation, you can remove the token, should it fail too often.
But, as rokjarc said, if you're expecting a third-party API to exist, you're pretty much out of luck. Apple ahs done most of the work for you already anyway.
When the app registeres for push notifications you need to pass additional data to your server. The user could input their own email/phone which will be sent to the server so that users can find each other. The email/phone can be stored alongside with the push token. When someone wants to share something, you would search the corresponding push token in the database and send the notification through APNS. Note there can be multiple push tokens for one email or phone i.e. when a user has multiple devices.
The users of your app should be aware of the data which is stored on your server and should have the option to delete it. Also use the APNS feedback service to detect and remove invalid push tokens.
We have a site and we developed a chat system for it using strophe.js library and ejabberd XMPP server. We use session attachment that was initiated with PHP (using an in-house library). What we do is get the RID and SID from the PHP script, then use strophe's session attachment. The said RID and SID is stored on a cookie and the RID value on the cookie is updated every update of the RID on strophe.js.
This works fine, after logging in we receive the presence status of each of our contacts. The problem with this is, when you go to another page on the site, and attach using the said RID (we use the incremented value produced by strophe) and SID, the server wouldn't send presence information of your contacts anymore as opposed to when you logged in. This caused our contacts area to appear all invisible even though they are online. They would only appear online if you (or your contact) log out on the chat, then log in again (since you will receive a presence update from the XMPP server).
I have written a workaround where the presence status of your contacts is saved on a cookie (all online contacts will have their JIDs saved on the cookie) when a presence is received from the server. This is checked every page load, if the cookie is set, it will be read, and all JIDs on the cookie will be marked as online. This is working fine but there might be some better ways to solve this, using XMPP's default behaviors.
XMPP servers send presence probes to all your contacts on your behalf when you send your own initial presence to the server. From then on, you will only receive presence status changes from your contacts.
If you lose the presence state of your contacts, you will need to send your own presence probes to re-establish that state. However, this is probably not something you want to do a lot, and passing around the presence state is probably preferred in most cases.
You could try passing the state via XMPP. For example, you could use Private XML Storage (XEP-0049), Pubsub (XEP-0060), or PEP (XEP-0163).
Another option instead of cookies for passing it client side is to use an HTML5 SharedWorker object to hold the state.
I shudder to think of the scale properties associated with storing all of the presence you just received from the server back to the server in private storage. Private storage almost always is backed to long-term storage rather than stored in memory, so you're going to grind your server's disk to dust.
If you want to store more state in the browser, and insulate yourself from browser version, and you're already using jQuery, then jStore is pretty sweet.