Блог

—ОБНОВЛЕНИЕ: я решил попробовать AFNetworking. Несмотря на то, что RestKit обладает действительно хорошей функциональностью отображения объектов, то, как были разработаны сетевые вызовы, усложнило для нас некоторые вещи.

Я надеюсь на несколько советов о том, как организовать мой проект, использующий RestKit.

У меня есть несколько вызовов REST из класса репозитория, и его результаты передаются контроллерам. Например, у меня есть метод getProfile в классе репозитория, который вызывается из нашего контроллера просмотра просмотра. Контроллер представления устанавливается в качестве делегата для вызовов get profile, в то время как класс репозитория устанавливается в качестве делегата для вызовов restkit.

Проблема в том, что если контроллер просмотра выполняет несколько запросов get profile, трудно определить, какой результат должен перейти к какой функции делегирования, поскольку все вызовы restkit используют один и тот же метод делегирования objectLoaderDidFinishLoading . Затем у меня есть 4 делегата, которым я должен сопоставить результаты 4 асинхронных запросов restkit.

Есть ли какой-либо способ, которым я могу использовать блоки, чтобы я мог передать функцию для выполнения, когда возвращается конечный результат, чтобы я мог назначить надлежащего делегата? Поддержка блоков, которую я видел, позволяла использовать блок до отправки запроса в rest kit, но я заинтересован в его использовании, когда возвращается асинхронный результат.

Альтернатива проверке результатов или настройке пользовательских данных и отслеживанию того, какой делегат идет с какими асинхронными результатами, кажется ненадежной и громоздкой.

Вы можете решить свои проблемы с устранением неоднозначности между запросами вашего профиля, используя непрозрачный указатель userData на RKObjectLoader. Это позволит вам привязать к запросу любой объект, который вы хотите, который затем можно использовать, чтобы помочь различать запросы нескольких профилей. Кроме того, если эти запросы профиля отправляются на разные пути к ресурсам, вы можете просто использовать метод wasSentToResourcePath: в RKObjectLoader, чтобы различать их.

Я просто наткнулся на этот вопрос, пытаясь решить эту проблему для моего собственного интерфейса REST. Я рад, что сделал, я, вероятно, буду использовать RestKit сейчас.

Я отвлекся, возвращаясь к вашему вопросу. Как вы заметили, не похоже, что аргумент block в RKObjectManager предназначен для использования таким образом. Вместо этого, как насчет написания класса, который реализует RKObjectLoaderDelegate , принимает блок и вызывает этот блок при любом из вызовов делегата.

Может быть, что-то вроде этого?

 @interface MyObjectLoaderDelegate : NSObject <RKObjectLoaderDelegate>

@property (nonatomic, copy) void (^callback)(RKObjectLoader *loader, NSDictionary *objectDictionary, NSError *error)

- (id)initWithCallback:(void (^)(RKObjectLoader*, NSDictionary*, NSError*)aCallaback;

@end
 

И в любом реализованном методе делегирования вы можете выполнить блок. Поскольку блоки сохраняют переменные области видимости, вы можете запускать код против вызывающего делегата.

Что думаешь?

Я не уверен, что использование блоков — правильный способ решить вашу проблему.

Как насчет наличия класса getProfile, который реализует RKObjectLoaderDelegate. Итак, вы вызываете запрос изнутри здесь и устанавливаете себя в качестве делегата. Тогда у вас есть ObjectLoader для каждого запроса.

Итак, в вашем контроллере представления каждый раз, когда вы задаете getProfile, вы создаете экземпляр. И затем, когда этот экземпляр отправляет ваш контроллер обратно (через делегатов?) вы знаете, что это такое.

Я тоже только что столкнулся с этой проблемой, поэтому очень хочу услышать отзывы.

Кажется, что переход на AFNetworking — это правильный путь … это была гораздо более простая реализация того, что мне было нужно.