Artifactory has a neat feature of sending emails for changed repositories but I wasn't able to find a place where I can configure how much time to wait before sending such notification.
As a result it does send lots of incremental emails if you are trying to upload a lot of data.
I suspect that it does have a place where this happens because the notifications are send in batches, not one per uploaded artifact.
The delay between event notification email is 60 seconds.
Currently, there is no easy way of changing this value.
It could be a nice feature request.
Related
We have 1M+ devices registered. Is there a way to limit how quickly the messages get delivered? Obviously it's real hard to scale if 1M+ notifications at the exact same time cause a massive spike of traffic to your backend. Would be great if instead of all the messages getting delivered immediately to all devices, you could make it only send X messages per second.
The best way to control the delivery of those message is actually by calling FCM with the token IDs yourself, preferably with the batched delivery feature from the legacy API (look for the registration_ids parameter there). You can scale this up to as many calls to the API as you need to deliver your message to all devices.
Using topics is also possible, but you lose control of the delivery performance since the fan-out happens in a process you don't control.
Alternatively: consider sending a data message that contains a timestamp on when it should be displayed. That way you separate the delivery time from the display time, removing the critical path (but of course introducing other considerations).
With GCM, when user expresses their preference whether they are willing to get notifications, we could mark their preference as active or inactive
How can I achieve similar effect with FCM?
When user says they don't want to receive pushes, we'd have to unsubscribe the user from all the topics we have?
Are there better approaches?
Depending on the scenario, unsubscribing from the topics is the way to go.
However, if your goal is to simply prevent the user from seeing any push notifications appearing on their screen, a workaround I could think of is have a setting (e.g. enable/disable notifications) that identifies if you should/shouldn't display a notification every time the user receives one.
For example, user installs the app. Initially, the setting defaults to enabled. Push notifications are displayed normally. If user disables it, when the device receives the message, you do not create a notification display.
For this to work, I'm thinking the checking should be done inside the method where you create the notification (e.g. sendNotification).
So the scenario now is that the device is still technically receiving the notification, it's just that you're not showing/displaying it to the user.
Note: I haven't tried to go with this scenario myself, so I'm not sure if this is breaking any best practices. I would still go with the unsubscribing if it were me though. It's easier.
Problem
Due to the haphazard creation and management of watch requests to certain calendar id's, the resource_ids for these watch notifications have been lost. In order to cancel the requests, the resource_id must be included in the request.
Question(s)
Is there any way to poll Google (using the channel_id or through other means) for the missing resource_id?
Is there a way cancel the push request programmatically through other means?
Is there a way to collectively cancel all active watch requests through the Google developer console?
Context
This is being written in node.js but the question really applies to any platform.
No, unfortunately push notification channels cannot be list or cancelled without the resource ID returned when they were created. Luckily they have a relatively short lifespan, so the problem should go away naturally.
All,
I have completed the basic GAE "Guestbook" example which uses Google Cloud Endpoints and Google Cloud Messaging. I can successfully add a note to the guestbook and have it appear on all registered devices.
I've also used the super simple Server Sent Event (SSE) mechanism to have a web page initiate an event source and then update itself as events are received. But separate web pages appear to create their own distinct event sources (even if using the same URI to the event source) and thus get their own events at their own times.
The objective here is to create a bit of collaboration such that user actions can come from an android device or a web page and the effects the received action are then pushed to all connected users/devices/web pages.
I have assumed I will need a background module and that both Endpoints and 'normal' web pages / queries would channel the received user action to that background module. I believe I can get that far. Next, I need the background module to trigger a push notification to all interested parties.
I believe I can trigger a Google Could Messaging event to registered Android devices from that background module.
But it isn't clear to me how a background module can be the source of an SSE, or how the background module can best communicate with a foreground module that already is the source of an SSE.
I've looked at the Google Queue API, but I have a feeling I'm making something quite easy much more difficult than it needs to be. If you were not going to 'poll' for changes from a web page... and you wanted to receive notifications from an SSE source when changes were made by other users, possibly using Android devices rather than a typical web page, and the deployed application is running on the Google Application Engine, what would you recommend?
Many thanks,
Randy
You are on the right track, not really sure why you are using the background module but from what i understood you need to:
Your front end module receives an update
You retrieve a list of all devices receiving that update
Use the Queue service to send the update via GCM to every single device
Why use queues? because front end instances have a 1 min time limit per request and you'll need to queue work in order to go beyond that time to serve you (potentially) thousands of users.
Now, If you already have a backend instance (which does not have the 1min limit) you could just iterate over the list and send all messages on one request. I believe you have a 24 hr request limit so you should be OK. But in this scenario you don't have need for the front end module, you can just hit this server straight up.
I'm evaluating Urban Airship as a push solution and I was wondering if it's possible to export my device tokens should I decide to stop using their service?
I've noticed they have an API endpoint to download device data (http://docs.urbanairship.com/reference/api/v3/device_information.html#device-token-list-api) but I was wondering if anyone actually went through the process of switching their push solution from UA to an internal solution (i.e. run my own push server and ping old users).
Thank you!
I'm not sure if there is an API call for it, but you could go to Audience->device tokens, and make a script to fetch all of them.
In the company I work, we decided on a different approach.
All communication with Urban Airships goes through our own backend, where we at the same time store the devicetokens sent from the device. That way we can shift to another way of sending push notifications without modifying our apps. It is of course a bit more time consuming to do the initial development. On the other hand, if you go for the solution you are currently considering, the switch to you own implementation (or another push provider) will properly require several migrations, or at least maintaining two different ways of sending push notification for a considerable time.
BTW:we have been using UA for almost 3 years, and have been very happy with their service.