I have setup WSo2 EMM correctly. Noticed that device information and Get All Applications Notifications go pending and are never delivered to the devices. The status of these notifications in the database table is also P.
The only way to deliver these messages are by pushing the Camera Enable/Disable Operation or some other notifications, then the older pending notifications get delivered.
Seems they are stuck. This also happens to policy enforcement notifications. I have to manually push camera disable/enable to make these works.
Why does this happen? The notifications should be delivered instantly, like they do in Camera Enable/Disable case.
I am connected in Production Mode. Any pointers to sort this out?
I was using Java 1.6 earlier. Once I switched the JDK to 1.7, it appears to so far work well.
Related
Our app uses Expo push notification to deliver push messages. It works just fine for most clients, but I am trying to debug one client where he is not receiving the push messages. Here is what I am seeing:
Using Expo push notification tool as well as my own client code, I
can send messages to his Expo push token. Expo server responds with
ok status. I checked the status given the receipt id and the status
also says ok.
But the client never receives the messages. I ensure
that the app is not already opened on his iOS device and that
notification is enabled for the app.
My question is: how do I debug this further? I understand that Apple server might decide to send or not to send messages based on various factors. How do I find out what Apple server did with the messages?
I have googled quite a bit but I couldn’t find much info on how to proceed. I hope that someone has experienced the same, and can help with some leads.
Thanks for your help,
Huey
I built a VoIP calling app which maintains a persistent connection with the server to listen to any incoming calls. I implemented a background service to do this.
But since Oreo, this running code is now broken because of the introduction of Background Execution Limits
After looking into forums, I found that some people are suggesting
Convert Service to JobService and let android schedule it
Doing so, my app won't be able to receive calls when it is stopped
Run your operations in foreground services
It is annoying for some users to see a constant notification in the notification bar. So these above-mentioned options aren't working for me to fix my code for Oreo.
How does WhatsApp get the incoming (VOIP) call in Android (Oreo onwards) working around the Background Execution Limits?
(Sticky) foreground services are not affected by the restrictions. So you could use one those as replacement for background services on Oreo.
But foreground services have two disadvantages: They are less likely killed by the system in order to reclaim resources compared to background services, and hence affects the Android system's self-healing capability. And they require you to display a permanent notification. But Users are able to suppress the notification, somewhat mitigating this disadvantage.
I am assuming that you are using SIP to establish the connection and initiate calls. Without a service constantly re-sending REGISTERs, the app doesn't receive INVITEs when the server sends them.
A workaround for this problem is what is called the "push notification strategy". It works as follows, when the server sends a INVITE, it also sends an FCM notification to your app, This wakes up your app which then sends a REGISTER to your server, which in return forks the call to your app. Here is a video that better explains this strategy
There are two options:
use platform push services (APNS or FCM)
maintain persistent socket connection and exclude application from battery optimisations.
When I send multiple notifications to Apple or Android devices through MFP, Apple devices will receive all the notifications on the other hand Android will only receive the last notification. We are using Unicast Notification to send messages to user devices using this REST API.
Android devices will also receive all the push notifications sent by the MFP server. The notification shade ( center) will however display only the last received. This does not mean the earlier ones are lost. They are all still available, just not visible in the notification shade.
You have not mentioned the complete build version of your MFP. To see all the notifications in the shade-
install the latest ifix from FixCentral, rebuild your application. Edit your wlclient.properties and add the following property-
showAllNotificationsInTray=true
I am developing chat application using XMPP protocol.
My development target is iOS 7.0
Every think is working fine user can able to communicate only when they are online.
But I want to notify user message has come when they are offline.
I have tried iphone XMPP App run background
But it doesn’t work for me.
First think it is possible or not?
Using what VIOP, background fetch or some other way?
If yes please let me know. how?.
The thread you are referring mention declaring that your app is a VoIP app to be allowed to constantly run in background.
It is technically possible but has two drawbacks:
If your application does not do voip, Apple will reject it (as misleading).
Battery consumption will be excessive as you will stay connected.
The state of the art is to fallback to Apple push notification service when the TCP connection between the client and the server is not established. This is battery efficient and provide a very good way to notify the user of new messages.
I'm developing an app which relies on C2DM to be notified of some new data to be fetched from a REST service. I have successfully implemented the C2DM android feature, but the behavior over Wifi is different from the connection over 3G. The messages are received instantly over 3G, but I have to manually turn Wifi off and on to have a "grace period" of ~1 min in which I receive them instantly.
My question is: Is there any way I can programmatically restart the connection, or trigger the notification fetch?
EDIT:
I've implemented an AsyncTask that periodically "reassociates" the connection to the access point (using WifiManager.reassociate()) every minute and a half. Not so sure about the correctness of this solution, though.
I've seen similar issues. It seems that under some circumstances C2DM messages are not delivered over wifi connections, when they are over 3G. On a related note I've also seen Android devices "drop" the push connection, so messages are not delivered (in my case the solution can be to put the device in airplane mode and then turn the network back on).
This reinforces the fact that all applications that use C2DM should be built so that even if push messaging fails, the app still works (even if messages/updates are slower because there's occasional polling to the server)
I wouldn't personally want to mess with the wifi connection as that's something that may cause problems for the user.