I'm currently developing an application which uses Google Nearby Connections API. I'm curious whether there is a method to change the timeout for onEndpointLost (method of the EndpointDiscoveryCallback class) and onFailure (method of the OnFailureListener interface).
In my understanding these methods (callbacks) are called when a predefined time is up, and we get these failure calls. I would like to lower this delay, because after a discovered endpoint dissapears, the onEndpointLost method is called too late to my taste. Same applies when a device tries to establish a connection to an endpoint which no longer advertises, resulting in the onFailure callback.
(I would be exxxtra happy if you, Xlythe could spare some time to help me (: )
Thanks in advance!
There's no way to manually adjust these timeouts, and we don't plan to expose a way either. This is because we're combining different scans (eg. BT + BLE + WiFi) and each scan has its own advertising/scanning interval. There isn't a one-size-fits-all number that would work for everything, and we don't control the timeout ourself for every medium (although we do for some).
As for some good news, we are optimizing the onEndpointLost timeout to be shorter for BLE. That's currently our largest timeout (at 15sec) and we're exploring lowering it (to 3sec). This won't lower the overall timeout to 3sec, but it should make it significantly lower.
For the onFailure event, I'd need to know which one you're referring to. If it's a connection request, you can interrupt the request by calling disconnectFromEndpoint. With that, you can have your own timeout of whichever value you want.
I'm using Retrofit and OkHttpClient to build a Rest API on Android.
Some time ago, i had noticed the very first request made by the api always take way longer to process than all others... At begining i didn't care because it was an acceptable time.
But suddenly the request time jumped to 60 SECONDS
All this time is waste client side, since monitoring the server i see that the processing time takes less than 1 seconds...
I was wondering what change I made that could cause such high impact, then I realized that i changed the connection timeout of OkHttp.
I had changed the value from 10 seconds to 60 seconds just for testings...
I made some experiments setting the connectTimeout to many others values and ALWAYS the first request takes the time sighly above the timeout
Does anyone know what may cause this weird behavior? how to solve it?
PS. I needed to test the api on a desktop and this problem didnt occur, i mean it is only happening on android devices [i tried several] what is the cause?
https://medium.com/inloopx/okhttp-is-quietly-retrying-requests-is-your-api-ready-19489ef35ace
It is likely failing on the first few requests and timing out. OkHTTP is automatically retrying.
builder.retryOnConnectionFailure(false);
Try turning off the auto retry and see what happens.
https://www.reddit.com/r/gfycat/comments/5y2dkm/psa_for_android_devs_how_to_work_around_ipv6/
It is likely an ipv4 vs ipv6 problem. This code prioritizes ipv4 addressses.
You could configure an EventListener in your OkHttpClient and use that to see how the time is spent.
I am using http://loopj.com/android-async-http/ to get simple JSON data from Reddit (just a constant) feed of links from a popular subreddit r/news I was wondering what is a reasonable request timeout in milliseconds for Android apps talking to JSON backend endpoints.
A reasonable timeout will be in seconds, not milliseconds. How long depends entirely on the expected service time of the server. You might want to consider the mean service time plus two or three standard deviations, but you will need to assemble the statistics on that first.
I just integrated Volley from my project and the requests are painfully slow and most of them even fail with TimeoutError. All the requests are https://
But the same request via Postman client finishes about 7 seconds.
I have tried the following, one by one, but NONE of them have worked:
Set initialTimeoutMs to 0
Increased initialTimeoutMs to 60000
Set retry count to 0
Increased number of threads assigned for request pool.
Could someone please help me with this?
Thanks.
I have implemented a queue service in Android that will change states based on queue and wifi/data connectivity events.
I queue transactions to be posted to a remote url. If the device has a data or wifi connection, it will iterate the queue and post data to the url until the queue is empty, or there is a disconnect event.
I can login to my app, enable airplane mode, generate data, turn airplane mode off, and the transaction are posted. No slow down, even with thousands of transactions. (I was trying to pish it a bit)
Enter: low reception!
My app slows down enormously when the 3G reception is low. (Yes, all uploading happens off the ui thread.) It seems that the cause of this slow down has to do with the post to the server taking a very long time to happen and sometimes just failing.
My question is, how can I solve this? Check for signal quality? Poll a known address? How do other apps, such as Gmail solve this? This must be a common scenario!
Well if you could potentially have thousands of tasks that all need to be executed, then surely they should be managed. Have you thought about implementing your own ThreadPoolExecutor? The documentation is very good and the class is easy to understand, but if you need examples try these sites:
http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml
http://javabeanz.wordpress.com/2010/02/19/threadpoolexecutor-basics/
The benefit of this is that you can limit the maximum number of threads you are spawning, so you shouldn't get a system-wide slow down if you limit your thread count to a reasonable number (For Android I'd recommend no more than 20).
May be do some fine-tuning of socket and conenction timeout? Thus, if your connection is slow and stalled, timeout will occur and transmission will fail.
After connection/sending is failed you can retry transmission later or do something else.
To adjust timeouts you can use the following code:
HttpParams httpParameters = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(httpParameters, 30 * 1000);
HttpConnectionParams.setSoTimeout(httpParameters, 15 * 1000);
HttpClient client = DefaultHttpClient(httpParameters);
// use client...
We have similar situation for our application. We have considered signal issues to be a reality and one that can happen any time. One of the point that we follow is not to remove any content from device unless we get a functional confirmation from server and just base on http status code.As in the slow network or the cases where we can lose signal suddenly, while we may have posted our content, there were many cases where data was received only partially. And so we decided to let server know device by some manner [result through some http get based request calls made by device] that content has been received.
More than performance or checking the network, the question that you asked, we needed such behavior for our application robustness.
You should check out using HTTP Range headers, for example like here.
The server should write payload to disk while reading, and handle disconnects. The client cannot know how many bytes payload actually reached the server, so it needs to sync up with the server every time there has been a network error. Dont forget to handle battery and user issues too ;-)
If you want to wait for a better signal, perhaps the SignalStrength class, with its getCdmaDbm, getEvdoDbm, and getGsmSignalStrength methods, is what you are looking for.
Check out this:
http://www.youtube.com/watch?v=PwC1OlJo5VM#!
advanced coding tips and tricks, bandwidth-saving techniques, implementation patterns, exposure to some of the lesser-known API features, and insight into how to minimize battery drain by ensuring your app is a good citizen on the carrier network.