I am implementing the real time notifications for my app. I see that in the developer documentation: https://developer.android.com/google/play/billing/realtime_developer_notifications they have asked to test by using Send Test Message from the Pub/Sub topic. Is there a way to do that by testing subscription purchase through my test staging app or while testing?
You can send a test message while testing, or at any time, manually from the Developer Console.
In your console select your application and then pick the "Services & APIs" item from the "Development Tools" item on the menu and in the "Real-time developer notifications" section there's a "Send Test Message" button.
Each app has it's own setup for Real time notifications in Monetization setup. So if you have test app submited, you can setup different pubsub topic for it, and not the one for prod. If that's the question.
Related
Azure notification hubs have a feature that allow for subscribing to various topics in a many to many relationship. (many devices to many declared topic strings)
Suppose I take these steps:
I send an iOS device a notification, "test 1".
The device goes offline.
I send "test 2"
I send "test 3".
The device comes back online.
APNS only sends "test 3". Test 2 was dropped
Not to mention that APNS will only notify the most recent event "Test 3", it can also drop additional alerts in iOS 11 if I exceed the 30 maximum per day.
One of the things I like about Azure Hub service, is that I can manage that subscription "state" in an external storage. Now however, it seems I have to track the subscriptions myself, rebuilding part of the Azure HUB architecture... archiving out the subscriptions, topics, etc so the device can query the server for all missing events.
Question
How do I reconcile the features of Azure Hub and topic subscription with the issue of dropped APNS pushes?
You're correct that there's nothing ANH (or you as a developer) could do about the dropped notifications because that's the way ANPS is designed. Which means that the solution to your problem would really depend on what kind of application you're building, the architecture and user scenarios you're targeting.
A couple of ideas I have in mind which may or may not works for you depending on what you're trying to do are:
Send a silent push to the topic once in a while that would trigger the app to query the server on whether something has been missed
If the nature of the app is such that people open it often anyway, then you could do a background check at the time they open the app
Of course, in both of these scenarios, you'll have to build some additional infrastructure on your end to keep track of which device received or missed certain notifications. One thing that might help you not to have to rebuild parts of the NH that are already there is using Pet Message Telemetry (PMT). I haven't experimented with dropped notifications, but hopefully, there's a way to tell a dropped vs delivered message apart using PMT (looks like Dropped value of the PnsErrorDetailsUri field is something similar to what you need). And having that might help you simplify and reduce the amount of data you need to keep on your end to be able to tell whether someone had missed a notification or not.
I'm sure this must have been answered but i cant find it.
What are the techniques used to test a server side application that generates apple push notifications?
We have a host based service that waits on an event, and then generates an APN, and our IOS application will receives this notification.
So, I'd like to write a test that simulates the event being received and sends the APN and then determine if it was delivered. From what i understand, apple will does not support this?
Only think i can think of is to write an IOS application, that simulates the event has occurred and tells our host to send back a Push notification to the testing device. Then the IOS application could detect that it was received or not. We could put it on an IPOD touch that is always running in our server rack. I dont really like that approach but dont know what else to do.
If we used Urban Airship would that make it easier?
You can send push notification using below url :
http://pushwatch.com/apns/
You'll just need three thing as below :
1)Pem file
2)Device token(s)
3)Message
We are a large group of developers, working on a project. We recently switched to TeamCity for managing the build process. I would like every developer to get a notification of the build success or failure. Since most of the developers are unfamiliar with TeamCity, and are super busy anyway, I'm concerned that asking them to subscribe to the build result may take a long time.
My Question: Is there a way to subscribe on the behalf of others to get build notifications via email?
Create a group (Administration - User Management - Groups), assign users to the group and create a new notification rule (email, IDE notififications, Windows Tray - whatever you want) for the group (Group detail - Notification rules).
I have created a Push Notification service for my IOS app using the code from the link below.
http://woutercx.com/2013/05/09/sending-push-notifications-iphone-with-pushsharp-csharp-monotouch-client-server-side/
I have coded every thing and set up the certificates correctly for push notification in my IOS app.
The question is how do I schedule the push notification to be sent to the registered IOS devices periodically. Lets say I want my users to be notified every hour? In short i do i make use of the methods of Pushsharp to schedule a Remote notification at a specified intervals.
Since pushsharp is a library, not a service, it has no ability to send notifications periodically or delay them. The library is only able to communicate to APNS (apple push notification service). APNS does not provide the ability to delay/repeat notifications, so neither does the library.
If you need to send notifications basing on time (say, hourly), you have to set up your own service that will wake up hourly and post a notification to devices that need it. I'm afraid there is no other way to do it without external services.
I have a client company with a simple web app that users can interact with via a desktop/mobile website. Recently they asked to implement a notification functionality. The users, if they wish to, can sign up to real time notifications from the web app.
The really interesting requirements though is that the notificaitons should:
Be delivered in real time (60+ seconds delay is a failure);
Have guaranteed delivery, i.e. my client wants to be sure that each user gets all his/her notifications.
Be able to somehow notify the user from background, i.e. a typical user would not wait for a notification with a browser window open on his/her Android, for example. The preferred way is to make the phone ring and/or vibrate and put some messages into the notification area so that a user can notice a notification even if the phone lies in her pocket or a bag.
Notes:
a typical notification message is rather short, here is an example: "Hello! You have a meeting with $John today at $5pm";
all the users have smartphones (iPhone/Android) with 3G connection enabled.
Since the requirement 3 can not be met with the current state of modern mobile browsers, the only two ways to fully achieve the spec is to:
A. Make an app for iOS/Android and use the native APIs to make the
phone ring and vibrate upon notification receipt;
B. Use an IVR like
Asterisk to call the user via SIP, play a sound with notification and
ask him/her to press 1 to confirm the receipt of the notification
(the sound can be something like "You have a meeting with John today
at 5pm. Please press 1 to confirm").
But when I started to test those A and B options, I found that (1) and (2) can not be satisfied via a regular 3G connection (the company is in Europe and the connection is quite okay). For example, a Jabber client on an Android device can get some messages with a long delay (a few minutes) and even loose some messages.
So, the only option left to meet the requirements 1, 2 and 3 is to use B (automated IVR - Asterisk).
Is my reasoning correct? Are any other mechanisms to deliver short notifications to smartphone-enabled users in real time, with 100% guarantee and make the smartphones ring and/or vibrate upon notification? Should I try to use anything else instead of the automated IVR calls?
P.S. I do not consider the SMS technology in my research, since to my knowledge there is no guaranteed delivery of messages.
If all your users have smartphones, your choices are IVR, SMS, or push notifications. If the mobile phone network is unavailable, all bets are off for IVR and SMS, but iOS and Android users may receive push notifications over wifi. If the phone network is present but weak (as in, no 3G or LTE), IVR and SMS are about just as good - SMS may be slightly better, because a bad phone connection can turn your message into "Hello, you have an appointment with KRRRZZZZT today at [call drops]".