Не совсем уверен, что я правильно понял вопрос - пример кода поможет.
Вы можете попробовать использовать библиотеку pandas ... импортировать массив в серию Pandas, а затем использовать функцию интерполяции для заполнения пропущенных значений: https://pandas.pydata.org/pandas-docs/stable /reference/api/pandas.Series.interpolate.html
Это не дает прямого ответа на ваш вопрос, но вы можете рассмотреть библиотеку Бена Копси ASIHTTPRequest
, которая охватывает классы CFNetwork
и включает в себя асинхронный многопоточный код запроса, который требует много работы для правильного выполнения.
Начальная мысль - правильно ли сохраняется объект, у которого весь этот код? Может быть, оно освобождается и, таким образом, освобождает соединение ...
В противном случае вы должны хотя бы увидеть ответ.
Ничего явно плохого там нет. У меня есть код, который по существу такой же и работает нормально. Единственные различия, которые я вижу:
Я использую NSURLRequestUseProtocolCachePolicy вместо NSURLRequestReloadIgnoringLocalCacheData
Я использую connection = [[NSURLConnection alloc] initWithRequest: делегатRequest: self]; вместо указания startImmediately: YES (поскольку это значение по умолчанию)
Было бы полезно узнать, какие из ваших методов-делегатов, если таковые имеются, вызывают. По крайней мере, вы должны получить хотя бы один или другой из вызываемых connectionDidFinishLoading или connectionDidFail. Если нет, то, возможно, что-то не так с настройкой вашего делегата - вы АБСОЛЮТНО уверены, что сигнатуры метода делегата верны и что вы передаете правильный элемент в качестве делегата?
Трудно сосредоточиться на чем-либо, поскольку из вашего вопроса непонятно, какой из операторов NSLog выполняется. Пожалуйста, будьте немного более ясны в отношении результатов, которые вы получаете.
На первый взгляд единственная вещь, которая выглядит как потенциальная проблема, это то, что у вас есть состояние гонки, когда вы устанавливаете соединение. Если сеть работает особенно быстро, существует небольшая, но ненулевая вероятность того, что -connection: didReceiveData: будет вызвано до того, как будет выделен self.urlData. Я бы предложил распределить urlData либо перед установлением соединения, либо в -connection: didReceiveResponse: чтобы предотвратить это.
Если это не исправит, вам потребуется дополнительная информация.
Вы говорите, что этот код работает нормально, используя асинхронный метод? Тестируя этот URL, он перенаправляет на другой, так что, если вы реализуете методы делегирования перенаправления? Что если вы попробуете несколько разных URL?
Отзывчиво ли приложение? Runloop работает? Что делает приложение после запуска запроса - возвращается ли оно из своего обработчика событий обратно в цикл выполнения? (Если нет, вы никогда не получите ни одного из ваших обратных вызовов, потому что они доставляются через runloop.)
Несколько предложений:
В вашем первом фрагменте вместо theConnection
попробуйте назначить to self.theConnection
, чтобы убедиться, что вызываются методы доступа к свойствам. В разных местах вы также меняете местами self.urlData
и urlData
. Возможно, вы захотите сделать их все согласованными, пройдя через self
.
Вы можете также сделать dataRequest
свойством и пройти через self
, чтобы сделать убедитесь, что он будет сохранен.
self.urlData = [[NSMutableData data] keep];
- вы не должны ' Мне не нужна эта дополнительная задержка. Прохождение себя
сделает это за вас. Дополнительное удержание сделает так, что объект останется и протечет, даже когда все будет сделано.
Кстати, в ваших журналах NSLogs убедитесь, что вы распечатали счетчик удержания для каждого объекта. Кроме того, вы можете захотеть иметь общую процедуру очистки, чтобы освободить эти структуры (или установить self.foo = nil
), поэтому в любой момент, если он выйдет из строя, вы можете вызвать процедуру для очистки вещей
Получите копию Charles или WireShark (или запустите tcpdump в консоли) и наблюдайте за сетевым трафиком. Это поможет точно определить, на какой стадии в потоке произошел сбой.
NSURLConnection is designed to work with any type of protocol, not just HTTP. This means that connection:didFail:withError is called for connection errors, but not for protocol errors. You're not checking for protocol errors -- you have to catch them in connection:didReceiveResponse:. The trick is that the response object that is passed in is actually a NSHTTPURLResponse object. If you check the response's statusCode, I'll bet you're getting an HTTP error such as 404 or server 500.
Проблема заключалась в том, что я продолжал выполнение программы и не останавливался, чтобы позволить соединению завершить загрузку. Спасибо за все предложения.