We released our phonegap application about a week back and everything was tested and working fine. Fast forward a few days and suddenly people start to report that they aren't receiving any push notifications. I go back to my test devices and fail to reproduce the error for a time but all of a sudden my device just stops receiving them.
I've gone on a debugging spree to try and identify the issue. I stepped through the server side code to ensure that the PushSharp code is being used correctly. I've checked the database to ensure that the user has an up-to-date device token and now I'm going though the steps listed here:
https://developer.apple.com/library/ios/technotes/tn2265/_index.html
When I enabled logging and sent a push notification a log was created with the appropriate timestamp so I know that SOMETHING happened. However, I'm still not receiving a pop-up on the interface and I can't see anything in the log that suggests it's gone awry.
Here is a pastebin of the log I extracted.
http://pastebin.com/KiCJEsDs
If this doesn't help is there anything else I can do to help identify the issue?
Related
I have a very simple PHP test script that initially works, using the following server config:
$domain = "gateway.sandbox.push.apple.com";
$url = 'ssl://' . $domain . ':2195';
I'm receiving PushKit notifications every time I expect them including when the phone is locked. However testing it over and over while trying to implement the server side and convert it to HTTP/2, it just stops working reliably and only seems to trigger when I'm inside the application.
Inside the application: always works
Outside of the application including just backgrounded the app: works in the beginning, then stops working
It's very hard to get it to work if I don't know if even the most basic form of sending the message (through the PHP test script works). Also it worries me that my production application might suffer from the same kind of throttling if a user is sending too many messages (i.e. mom trying to call from the hospital 10x in a row).
I do always trigger CallKit in my PushKit code path every time so I think I'm good regarding to the changes in VoIP pushes in iOS 13.
What could be the cause of this different over time? How (if possible) can I prevent it? How can I detect it?
For that one person that upvoted my question but didn’t find a response:
Killing the app makes the OS think depriotitize it and it leads to the OS not forwarding the VoIP push anymore. To mitigate this problem as a developer you need to start the debugger without launching the app, so when you open the app from the push it can attach. Then kill the app only through the stop button in Xcode.
Testers need to be instructed about this problem. If you’re sure the code works for you and it stops working for the tester, they need to uninstall the app, restart the phone and install it again. If possible never kill the app manually. This sucks, I know it.
I'm using the Wink API to control lights and thermostats etc. In the API you can subscribe to device topics to receive events such as when a light is turned on or off. This is handled through PubNub. I have this all working except that the events stop being sent if I leave the system overnight.
If I try to "manually" toggle a light by tapping the physical switch then normally an event is fired and received by my application via PubNub. Restarting my application and thus reconnecting to PubNub does NOT resolve the issue. The only way I've found to resolve the issue is to open the Wink app itself. Nothing else needs to be done but to open the Wink app. Then if I manually toggle the switch the event will show up and be received by my application. This solution works even if I don't restart my application.
There appears to be some sort of wake or keep-alive going on. Although I don't see anything in the Wink API docs that state such. There is also nothing sent from PubNub during this downtime. I have logging being sent out for the status(), message(), and presence() callbacks and nothing is logged from these overnight. Therefore taking all the above into account I believe the issue resides on the Wink side of things.
Unfortunately, Wink does not provide developer support. The Wink app is obviously doing something but because the transactions are encrypted it is unknown what it is doing. Also my test cycle is 8 hours long currently so it is difficult to debug this by trial and error. I'm working to see if this "timeout" is shorter than the overnight 8 hours I've experienced so far. i've also tried power cycling my Wink Hub yesterday but that did not resolve the issue.
Anyone else run into this issue? How do you keep subscriptions alive so that they are always sent?
So, I have an app in the store, I have downloaded it on my phone and obtained push token for that device. I tested silent push notification sending and indeed, it works, my device received it.
I wanted to check what is the time after push token will become invalid. First thing I did was simply uninstalled an app and was paying attention after which time I will start getting {"reason":"Unregistered","timestamp:1234567890} to my curl request which looks like this:
curl -d '{"aps":{"content-available":"1"}}' --cert "/Users/uerceg/Desktop/ProductionCertForMyAppsPush.pem":"password" -H "apns-topic:com.my.app" --http2 https://api.push.apple.com/3/device/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Once I have uninstalled an app from my device, it generally varies from case to case (I guess Feedback Service has some kind of tokens refresh logic I am not really aware of, nor I found some documentation about it, anyway), but it takes from 3-12 minutes to start receiving information that my app is uninstalled. Lovely.
After that, I wanted to test one more case - selecting Erase All Content and Settings and completely wiping out everything from my iPhone without restoring any backup afterwards.
Once I did that, app is removed as well. But curl request is always returning status 200. I waited for 5 days and after 5 days, it is still returning 200 as if app is installed, but my guess is that it shouldn't. Once erasing everything, I have newly installed my app, got new push token which I use to successfully send silent push notifications again.
Sure, if I have mechanism to identify that this particular device newly installed an app, I can update the token on the backend side not to send notification to that device anymore, but my question still remains: Why is Apple not invalidating the token in case where I have deleted my app by erasing and resetting my iPhone?
Maybe this is expected behaviour and my question doesn't make sense, but if it is expected behaviour, can you please point me to some documentation which is explaining this?
Thanks in advance.
Likely for the same reason that if you make a backup of your phone, and restore from backup, existing push keys still work. Invalidating the key on a device that is getting wiped would take out the potential that same key could be used from a backup.
We are developing application which rely on new IOS7 functionality - remote-notification background updates.
According to docs system can "skip" calls to didReceiveRemoteNotification:fetchCompletionHandler: if it finds that background processing power-consuming and lengthy, etc and we see this in practice - user can get push notification on the screen, but calls to didReceiveRemoteNotification:fetchCompletionHandler: are simply not happening at all
The question is - how we can check what happeping in ios with push? is there some ways to see internal system logs with real information from ios services? We need this for debug purposes of course, not in released application. just to double-check and fine tune our background processing. There is should be the way for developer to see what is really happening on device.
I found application "appswitcher" that shows similar stuff, but on ios7 it shows only active application logs (appswitcher itself), not system-wide. so it is useless for us...
To be clear: push notifications are working correctly, they are always received by the program in Debug mode for example. But in release/adhoc build we see that some notifications are sent to applications (waking it from background) and some are not. Documentation stating that fetch callback is used to calculate cpu/data usage and ios reserve right to "skip" notifications when it feels to do so, we just want to find the way to see is this is the case
Any help is welcome
I've never tried it but I saw this a while back. By looking at it, it seems like it will help your case but unfortunately, you gotta give it a try to find out if its worth it or not.
https://developer.apple.com/downloads/index.action
Go to that website, and login using your developer account.
Go to page 2 (or find Oct 4, 2013 post Bug Reporter Logging Profiles (iOS)).
In the description, Apple has a link that tells you how to use these profiles. As the title of that post suggest that it is used for bug reporting, hopefully it gives you some details so you could fix your bugs.
Try it and see if it works and let other people know if it's useful or not. Since it says 'Logging', my guess is that it will output detail info on the console about push messages and not secretly log and sends the log to apple.
Firstable you need to check if your push notification working correctly. What i would do is temporary disable background fetching, and simply check if i get push.
If everything is ok i will turn background fetch back in Capabilities and try to send one in Debug. Even app is in background you can still have a breakpoints. If method is not called try look at the console.
I think you have a problem with push notification other than backgroundFetching.
If you are willing to try what happen when application is not in background mode but wass 9-killed you should put NSLogs in method. If you see NSLog in console then (Xcode -> ⌘⇧2 -> your device (connected) -> Console) you're good to go.
The production console is in background fetching useless to you unless you put NSLogs in your methods. But then you can only check if you successfully enter method and log a parameters.
I have signed with RIM for BlackBerry Push Service Evaluation Credentials so that i can test my push notifications implementation.
I used the low level sample as my server to send the push and i build the client side.
Everything worked well till now. Suddenly my application stopped showing the received push messages. Instead every time i send a push i can see in the right up corner an arrow loading (like something is being processed) but no push notification is shown.
Is really strange , cause i didnt do any change on my code.. Any ideas?
EDIT
Actually i found out that when i deploy the app in the device , the push doesnt work as i described. When i restart the phone though , the push works fine. I think maybe is because , i call the background process for listening for push , when the phone gets restarted. Have a look on my code: http://codepad.org/ddJvyOox
When i launch the app , i register to BIS for push but i think i dont listen for them. I do that every time the phone restarts.. Do you think this might be the problem?
Curious are you behind a firewall by any chance?
To consider adding firewall exceptions to have access for the eval/prod PPG then need to add the IP addresses below:
Eval:
68.171.224.57
68.171.224.59
Production:
74.82.67.65
74.82.67.66
74.82.67.70
74.82.71.70
Another high level check before diving deeper; are you able to login into the EVAL CP Portal URL Your credentials might have been reset/expired, if so contacting blackberrypushservices#rim.com to help with access to the portal.
On the application level, the app needs to connect to the InvokeManager signal at the beginning.
onInvoked() function would first check to see the bb::network::PushService instance exists and the appID is stored.
connect(m_invokeManager, SIGNAL(invoked(const bb::system::InvokeRequest&)),
SLOT(onInvoked(const bb::system::InvokeRequest&)));
The application will extract the push message from the invoke request by passing the invoke request into the PushPayload constructor if the action property of InvokeRequest matches the string constant BB_PUSH_INVOCATION_ACTION from the onInvoked() function.
Do any of these suggestions work? Otherwise please explain more in depth which client/server code you have implemented and the bar-descriptor file's properties.
Curious to know where are you located as there might be the likelihood of Push Service outage if Push Notifications suddenly stopped working.