I have a broadcast receiver watching the wifi state and sending an http request to me server when it becomes enabled. The problem that I have is that when I run the code under debugger it works just fine, but when I run the same code without a debugger, it throws an exception.
The exception indicates that the failure is actually the DNS resolution failure - it fails to resolve the DNS name.
I decided that even though the system fired the 'enabled' event, the DNS resolver is not fully initialized yet and added a 10sec delay before the attempt to send my request and this resolved the issue, but I am really uncomfortable with this solution. Even though in my case it does not really matter, 10 sec seems too long. A bigger question will 10 sec be enough on all platforms?
Another solution would be to intercept this particular exception and try again. The question is - how many retries?
My question is - what's the best way to wait until the DNS resolver is fully initialized? Is there an event or a notification I can subscribe to?
Related
I'm developing an app recording with a background service your position and sending it to a server, every second. As many other users, we have to deal with battery saver to make sure the background service works properly. And we have to thanks daily dontkillmyapp.co/ for their outstanding work.
However, I got a issue reported with Crashlytics countless time
KotlinExtensions.kt line 53 retrofit2.KotlinExtensions$await$2$2.onResponse
This error is reported as non fatal, but usually it match with the exact time the background service is being killed by the system, silently.
Our app is being generally used with poor network conditions. Still, is it normal to have such reports? Or definitively this error should not be triggered by Crashlytics if the app was handling well his network latencies or reliability?
Thanks
I'm using QBluetoothDeviceDiscoveryAgent to search BLE devices on an Android phone.
I request device search to be started by calling QBluetoothDeviceDiscoveryAgent::start(). After a few seconds, QBluetoothDeviceDiscoveryAgent::finished() is emitted, but I did not call QBluetoothDeviceDiscoveryAgent::stop().
At this point, my BLE device was not found yet (it's slow...I know), and it won't as the system decided on its own to stop the search....so I need to restart the search manually.
Why is the system stopping the search? Qt doc says about QBluetoothDeviceDiscoveryAgent::finished():
This signal is emitted when Bluetooth device discovery completes.
What does that mean? How could anyone decide that discovery completes? Does it come from BLE standard? As a end user, I'm the only one who knows when it's completed, i.e. when the device I'm looking for was found....
As commented by Frank Osterfeld, the android implementation of QBluetoothDeviceDiscoveryAgent (see line 273) silently creates a 10 seconds timeout that stops the search automatically.
It's a pain for users who want to search for longer than 10sec...
Filled a bug report here: https://bugreports.qt.io/browse/QTBUG-53012
I downloaded IBM MobileFirst project from https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-6-3/advanced-topics/location-services-hybrid-applications/.
I've ran it in the Android Emulator.
I've noticed that the method WL.Device.Geo.acquirePosition, works as expected.
But with WL.Device.startAcquisition, after the success callback has been invoked, the failure callback invoked as well.
Why is the failure callback being triggered?
Please see my above requests in the comment for additional information (as well as Idan's request).
Without that, though, my guess is that you're passing in a timeout on the Geo policy. When you're running in the emulator it's quite likely that you wind up not setting a value quickly enough (after the initial one you set), and thus soon after you're getting a timeout failure.
As well, please note that the Android emulator has a known bug that Geo positions are set starting from midnight on the current date.
When a network connection is unavailable, the drive sdk takes a very long time to timeout -- it takes 15 mins according to this answer.
I access Drive in an AsynchTask which blocks my application. So, if there is no network connection, the application shows a ProgressDialog for 15 mins, until the time out. Possibly I could implement my own timer which kills the AsynchTask after a reasonable duration. However, it might be difficult to differentiate between a timeout and a lenghty process (like downlaoding a large file on a slow connection) and I would be concenred that there could be issues with the token access not cleaning up properly. Any suggestions for how to work around this?
A check if there is a network connection before performing the AsyncTask would help eliminate a lot of the cases, see Detect whether there is an Internet connection available on Android
I'm writing software which requires cell location updates to be received or checked constantly. The problem I'm having is that when the screen is off: a) notifications stop (using PhonestateListener); b) when a timer is used to check the cell info of the current cell, old cell info is returned.
I've spent a lot of time searching the reason for this and found a couple of posts on this subject. However I never found an answer or a workaround to the problem, accept for having the phone turn the screen on constantly to get a new cell location.
I've check the android RIL source code and it seems as soon as the screen is turned off, a broadcast receiver in the RIL sets the screen state to off and stops URC messages from the modem. I decided to try and call these internal functions to, say, reset the screen state (bad solution!), but I kept getting permission errors due to system intents being created as a result of my actions (I even tried by getting su permission).
Finally, I tried to communicate directly with the modem to send a +CSQ command (using 'invokeOemRilRequestStrings' function in the RIL). However, that part failed as I kept getting errors about object type not being same as expected class type...
So... I would like to know if anyone can point me to a solution to get this thing done. Or is it an impossible thing to do on android without modifying the ROM?
Thanks in advance for your help.
Did you try registering for location updates in a separate Android service having FOREGROUND priority?