SKProductsRequest - как обрабатывать таймауты/ошибки соединения?

Приветствия,

Мне кажется, что SKProductsRequest никак не обрабатывает тайм-ауты или ошибки подключения. Он либо вызывает -(void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response в своем делетете в случае успеха, либо нет.

Я бы хотел, чтобы мои пользователи показывали какой-то индикатор активности во время загрузки продуктов или, возможно, всплывали оповещения, если приложение не может быть достигнуто. Поскольку (в случае отказа) нет обратной связи от SKProductsRequest, однако, мне интересно, какое событие я должен связать с представлением этой обратной связи - другой, тогда ожидая произвольного количества времени.

Итак, возникает вопрос: существует ли известное количество времени, после которого можно с уверенностью предположить, что запрос не сработал? Или есть ли способ проверить статус ожидающего запроса, который я просто не видел?

Ответы

Ответ 1

Я запускаю это в своем проекте для всякого отказа SKRequest (включая SKProductRequest):

- (void)request:(SKRequest *)request didFailWithError:(NSError *)error
{
     alert = [[UIAlertView alloc] initWithTitle:@"In-App Store unavailable" message:@"The In-App Store is currently unavailable, please try again later." delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];

     [alert show];
}

Работает с удовольствием. Конечно, вы можете поместить что-нибудь внутри скобок, чтобы заменить мое оповещение, но это хорошо работает для пользователя.

Надеюсь, что это вам полезно.

Примечание: Это находится в SKRequestDelegate не в SKProductsRequestDelegate, что немного запутывает. SKRequestDelegate используется для покупки и для запросов продукта. Набор делегатов с использованием request.delegate может реализовать методы для обоих.

Ответ 2

Я не верю, что вы можете делать что угодно, кроме как ждать сколько угодно времени. В некоторых моих приложениях я жду 30 секунд (показывая вид модальной активности), а затем выйду с общим предупреждением об ошибке. Проблема в том, что на самом деле 30 секунд больше внимания большинства пользователей к таким проблемам, но если вы сделаете это достаточно коротким, чтобы быть полезным (скажем, 15 секунд), вы могли бы задержать слишком рано.

Я не думаю, что есть лучший вариант... но я готов учиться иначе!