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?
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 have an issue regarding Twilio Javascript SDK and stuck in a
situation where the issue directly involve IOS and RTC support. Right
now, i cannot connect the twilio device after device is ready. There
is no error or anything to track/debug.
Constantly, running the connection.status() return back connecting always. I think the signaling system works when there is an incoming call but again, connection.accept() and status remain connecting like forever.
Application Overview
Cordova/Phonegap app
https://media.twiliocdn.com/sdk/js/client/releases/1.6.9/twilio.min.js
shim:https://webrtc.github.io/adapter/adapter-1.0.2.js
https://github.com/BasqueVoIPMafia/cordova-plugin-iosrtc
Possible reasons: Can this be directly CSP issue? or I have you setup configuration using STUN/TURN?
Let me know if you need any information. It's not going to resolve because there is no error just "connecting" status.
I'm newbie in iOS App world so pardon me if my questions are simple and banals
I have this scenario:
my server side generates MQTT messages on a well known topic
my app can connect to the MQTT Topic and can receive messages
All works pretty good; what I would like to do now is the following (if possible)
When the user stops the app (by deleting it from the task manager) I'd like to have a kind of service able in being connected (or remaining connected) to the MQTT Topic; in this way also when the app is no more running I can receive MQTT messages
Basically I'd love to have something similar to Facebook messenger that is able in receiving messages also when the app is not running
NOTE: i can't use remote notification mechanism provide by Apple
Remote notifications would be perfect for this, shame that it's not an option for you.
There are a few other situations where apps can run periodically on the background, they are described here:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
BUT, from that page: "In most cases, the system does not relaunch apps after they are force quit by the user."
So in general an app will run in background only if the user exits it normally, not if he forces it to quit in the task manager.
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?
I have an application that handles applicationWillResignActive and applicationDidBecomeActive notifications by doing stuff like pausing/unpausing BG music, etc.
I am experiencing a weird bug, in which in every 3-4 times becoming inactive and returning (e.g. locking/unlocking the device), the app seems to be completely stuck for a few minutes - meaning, I see the view I'm supposed to see, but I can't touch anything, and music isn't playing.
I debugged it, and it seems that the applicationDidBecomeActive notification is not getting called what so ever.
I looked at the log of my app and literally didn't see anything there for the entire time the app seemed stuck.
The only interesting thing is that in the device's console I could see this line appearing about 10 seconds after I unlock the device and noticing the stuck application.
Mar 20 11:51:13 unknown MobileStorageMounter[4882] <Notice>: (0x3f4d948c) idle_timer_callback: Exiting after idle timeout
Not sure if it's related.
Anyone had a similar problem?
It could be that a call to TestFlight is timing out, and prior to the timeout the app locks the main thread, which freezes the interface, until the request is processed or times out. This could happen if the request failed to complete before the system pushed the app into an inactive state, meaning that when it returns to an active state it would still be trying to listen for a response to the request that it will never receive, hence the timeout. The same can occur with Flurry Analytics (at least older versions of the SDK that I have used), and they happen to me as well when calling my own homemade API's and API responses are delayed by a second or two.
Turns out it was a bug in the TestFlight SDK, upgraded from 0.8.2 to 0.8.3 and problem was solved