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.
Related
I've integrated Huawei's Pushkit, push notification service into my Xamarin application, I've tested the notifications while the application is running in the foreground and it works as expected.
However, while the application is closed the application and attempt to send a notification, the OnMessageReceived method in my messaging service is not triggered.
According to the documentation that can be found here :
Regardless of whether your app is running in the foreground or
background, if you override the onMessageReceived method in the
DemoHmsMessageService class, your app can obtain the data message
content as long as you send a data message.
According to me, that means the OnMessageReceived method should be triggered, so long as you're sending a Data Message.
Am I missing something, or did I perhaps misinterpret the above-quoted passage?
Thanks In Advance! 😀
Push kit supports two types of messages - notification messages and data messages.
OnMessageReceived will be triggered for data message to receive message.
For data message, if app is closed, user might not receive message. As per doc :
https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/funtion-description-0000001050148080
The delivery of data messages depends on the resident status of your
app. Push Kit cannot guarantee a high data message delivery rate,
because it may be affected by Android system restrictions and whether
the app is running in the background.
It might be because of battery optimization.
For Notification message, notification can be delivered regardless of app resident status, even if app is not launched.
Do we have any alternative for chatting app becuase iOS silent push notifications are highly highly unreliable, for example
if the app was terminated by the user they are not delivered at all
if the battery power is <= 40%, the OS receives the push but often delays delivering it to the app for a few minutes
if the batter pwer is >= 20, the OS receives the push but decides not to forward it to the app at all
many other criteria affect whether the OS actually delivers the push to the app or not
We tried using Voip push to achieve smooth chatting behavior for apps not suspended state. But the problem is in iOS 13 its must to report incoming call on voip push arrival.
Do we have any other option or way around so that chatting apps like ours can work in background/suspended state (for short time)?
If your server has all the information you need to write the notification text, you can send regular push notifications that won't wake up your app.
There's no other way than using silent push notifications to run your app in background, but one alternative is to use Notification Service app extension. It won't wake up your app, only this app extension, but you'll be able to write code for it to modify the notification text before presenting it to the user
It's possible to share data between your app and this extension - by sharing the database or just some data using app groups or the keychain. Your app extension will only have 30 seconds to run, but that should be enough.
Silent push notifications are unreliable and should not be used to notify about a new message.
VoIP pushes are exclusive for reporting incoming calls.
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 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]".
In a project I'm currently working on, we send some small info across the wire to WP7 device when we send a raw notification.
When the application is in a tombstone state and the user receives the toast message, we can't add the extra baggage in the toast. So we figured we need a way to resend the notification once the user entered the application again.
Anybody has any experience or possible solution for this problem. We are currently looking at a sort of handshaking between client and server. But it all seems a bit drastic for me.
Kind regards,
Tom
I would suggest to stop using rawNotifications and use only toast.
To handle the case when the app has been started using a toast notification, query the server at app startup to check if there's pending data.
For notifications sent while the app is running, you can detect them using the ShellToastNotificationReceived event of your channel. When the event is triggered, query the server to retrieve the payload.