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.
Related
I've been thinking about how to design a system that supports user created scheduled alerts. My problem is once the alerts are created and inserted into a database, I don't know what the best way to go about scheduling those alerts. Polling the database to see which alerts need to go out next doesn't seem entirely right to me.
What are some ways this could be handled on a scale where say a million users could create their own custom alerts like change baby diaper at 3pm everyday?
This problem is very suitable for cloud platforms. For example, you could use GCP Cloud Scheduler to invoke a cloud function when the alert is supposed to be sent out. The cloud function then calls some API to alert the user.
If cloud platforms are not an option, you could have your application spawn a new thread when an alert is created, and sleep that thread for a certain duration. When it wakes up, it sends the alert. Less elegant and less scalable than the first solution, but it would still work.
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
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]".
Microsoft documentation says that if the battery power of the device is critically low then the app will not receive push notifications. If the battery power is low but not critically low then the app will receive only Raw notifications.
In these two cases an ErrorOccurred event is received, do we have to show an error message to the user explaining the what has happened. Is it fine displaying an error message when the battery level is low?
If you're not receiving messages on the phone, how will the app know to inform the user. Even if it isn't running.
When restarting the app you shoudl always check (and if necessary re-establish) channels.
If it's appropriate to let the user know there was a problem and it has now been fixed. And/or that previous notifications failed then you should do so.
I am about to start building an SMS alerting function in my web application. The aim is to provide two services:
Host pays - e.g. to send an SMS alerting users to the cancellation of an event
User pays - e.g. to alert that an Email has been sent with, say, details of a new event (apparently a requirement from users when they are away from their EMail systems!)
I also figure that there will be other user-pays scenarios such as if they have secondary mobile phones that they want alerting as the Host will only want to pay for a single phone per user.
From my research:
I can use a 3rd party SMS Gateway provider. Cost is about GBP 0.05 per message. I can either send an EMail to 999999999#TheGatewayProvider.com or I can use an HTTP request with suitable parameters in the URL.
I can send an EMail to the user's network provider (I believe this is only available in the USA)
EDIT: There are variations on how the various providers will handle the From/Subject and Message, so presentation of actual message sent may be hard to predict.
I can set up my own Gateway (which I think is way beyond my ability, and may give grief at our data centre!)
It strikes me that:
EMail we send sometimes get delayed in my server's SMTP queue, let alone any downstream queues. Sending an email to the network provider's SMS gateway seems to often be treated as low priority.
Therefore HTTP to a 3rd party SMS Gateway provider should give me shortest latency (important for "This afternoons event is cancelled because of bad weather")
When I send SMS Text from my mobile occasionally they take days to arrive - I presume this is something we just have to live with?
Having said that we will also have low priority informational messages and sending these by cheapest route is attractive! so I am planning to allow users to enter an EMail address for such messages - the intention being that they will use the email address for their mobile phone company's SMS redirect service, or similar (i.e. the email address of a device, not an inbox).
I also wonder whether allowing the users to enter IM, Twitter or other such is likely to be well used and efficient in practice?
From the 3rd party gateways I have looked at it seems:
Some use higher grade networks than others, this may impact performance? (or is it just marketing hogwash?)
Some provide better feedback than others. I need to keep the arguments over billing - and exactly how many "credits" the client has used up - to a minimum; getting an answerback of "OK" / "Phone number does not exist" therefore strikes me as important. One provider I found creates a text log file daily that can be downloaded and which I could reconcile with my outgoing log.
I would appreciate your opinions and experiences on:
Users will enter their mobile numbers as they know them. Do I need to enforce +9912345... so that I get the country code too?
What happens if the mobile is foreign (I'm based in the UK) Does the recipient pay the international part? or does the gateway provider perhaps have local transmission services?
What do I need to do with non alpha characters? The UK Pound sign "£" and CR / LF spring to mind. If these are encoded might that cause a message right on the length limit to exceed it once encoded (such that I need to build this in to the validation of the message creation form). Are new lines CR+LF or will just CR do?
Do any gateways have simulations? such that I could test my application without incurring any actual costs of SMS texts.
I plan to log the mobile numbers of any failed attempts and flag the user's record so that the next time they login I can encourage them to correct the number.
Any other gotchas and suggestions you have would be much appreciated. Thanks.
The one big gotcha, that has happened to me, although this is not a programming question as such, its just an experience of it, that needs to be taken into account.
When someone sends you a message that is of an urgent meaning, and then the sender (owner of the handset) comes over to you and asked you did you get the message, and this is what irks me, a row can arise because you can claim to not have received it, thus making the sender somewhat feeling miffed/cross/angry that you have "ignored them" or "did not respond" when in fact it is down to the provider's network problems.
And funnily enough, after about an hour after having a row, your handset goes beep, and your message from the sender arrived!!!! This has happened to me several times! But what can I do without ever knowing what is happening on the sender's side of things (crisis, urgent query etc)
So be cautious if sending the message across from ethernet (internet) to the handset as ethernet is not exactly 100% stable (routers go down, dns disappearing, server outages etc) so it is worthwhile to keep this in mind. Like the question is how can you guarantee instant delivery of sms? That's a big question and reliability will have to come in, usually requiring extra effort to do so...
Handsets, most of them usually do, have what is known as a delivery report, some are switched on, some are switched off, that is a useful way of knowing if the recipient's handset is switched on or off, if it's on, you will get an instant delivery report indicating that it was delivered, likewise, if it's off, there will be a noticeable time delay in getting the delivery report, that is dependant on your providers' maximum time for delivery.
Sorry if this seems like a rambling...
Hope this gives you some food for thought,
Best regards,
Tom.
SMS is a telco service, not an Internet service. That comes with some different rules.
For starters, many endpoints are billed/billable, and have contracts with a single service provider. This will include all of your use cases.
Secondly, billing is a contract matter both on the sending and the receiving side. You simply cannot state as a sender that "Host pays", unless you restrict yourself to sending SMS to specific countries. USA is the most famous exception. "Receiver pays" is even worse. Due to SMS spam, telco's will usually allow this kind of traffic only when you have a contract with them.
Third-party SMS operators can deal with many of these problems. It's very easy for them to be more service-oriented than the average telco. They might even be able to deliver international SMS for you.
SMS tends to buffer in the network itself, not necessarily the email gateway. In individual cases, the difference is probably invisible to you. But you would still have delays even if you had a direct SS7 link to the telco.
Real telco's have test gateways, but the terms of use for those I can't give you. The idea though is definitely to be able to test you app at lower costs.
SMS uses its own alphabet, a rather nasty multi-septet encoding (7/14/21 bits!) The quoted 160 character limit comes from a 140 byte payload. This could also be coded as 70 UTF-16 characters.