#android #retrofit2 #okhttp
#Android #retrofit2 #okhttp
Вопрос:
В моем сценарии наш серверный сервер хочет получить уникальный идентификатор с любым запросом, но я прочитал, что «OkHttp потенциально будет повторять ваши запросы при медленном / ненадежном соединении «агрессивно», пока оно не завершится успешно». отсюда и некоторые проблемы с OkHttp. Я знаю, что могу отключить механизм повторных retryOnConnectionFailure(false)
попыток, но я хочу включить его для решения проблем с подключением. Именно то, что я хочу, это изменить запрос перед повторной попыткой. Могу ли я перехватить перед отправкой молчаливого запроса?
Ответ №1:
Если вы добавите NetworkInterceptor, то у вас должно быть примерно 1: 1 с вызовами, выполняемыми на вашем сервере. Обычный перехватчик может не включать фактический запрос, если вы получаете попадание в кэш, и он не увидит все попытки. Поэтому добавьте NetworkInterceptor, который будет вызываться для каждого выбранного маршрута.
Множественные попытки исходят как из альтернативных маршрутов (несколько результатов DNS), так и из безопасных повторных попыток некоторых вызовов на основе HTTP-запроса или кода ответа сервера, которые указывают, что это безопасно.
Видишь https://square.github.io/okhttp/interceptors / для получения информации.
Выбор между приложениями и сетевыми перехватчиками
Каждая цепочка перехватчиков имеет свои относительные достоинства.
Перехватчики приложений
Don’t need to worry about intermediate responses like redirects and retries. Are always invoked once, even if the HTTP response is served from the cache. Observe the application’s original intent. Unconcerned with OkHttp-injected headers like If-None-Match. Permitted to short-circuit and not call Chain.proceed(). Permitted to retry and make multiple calls to Chain.proceed(). Can adjust Call timeouts using withConnectTimeout, withReadTimeout, withWriteTimeout.
Сетевые перехватчики
Able to operate on intermediate responses like redirects and retries. Not invoked for cached responses that short-circuit the network. Observe the data just as it will be transmitted over the network. Access to the Connection that carries the request.
Ответ №2:
Я думаю, вы можете решить этот процесс с помощью Interceptor. Когда сервер не может быть подключен, вы можете подключиться к другому серверу.
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
// try the request
Response response = doRequest(chain,request);
int tryCount = 0;
while (response == null amp;amp; tryCount <= RetryCount) {
String url = request.url().toString();
url = switchServer(url);
Request newRequest = request.newBuilder().url(url).build();
tryCount ;
// retry the request
response = doRequest(chain,newRequest);
}
if(response == null){//important ,should throw an exception here
throw new IOException();
}
return response;
}
private Response doRequest(Chain chain,Request request){
Response response = null;
try{
response = chain.proceed(request);
}catch (Exception e){
}
return response;
}
Комментарии:
1. что бы сделал сервер переключения?
2. Я выразил это неправильно. Этот метод можно использовать для изменения запроса. Я начал с вашего ответа. В конце концов, ваша библиотека. Вам лучше знать. 🙂