Делегирование в NSThreaded Design? (IPhone)

Question

Я использую большое количество очень маленьких веб-сервисов в своем приложении, и я преодолел пару дорог, которые не масштабируются или работают не так, как хотелось бы.

Подход к дизайну Я думаю о: Задача для viewController состоит в том, чтобы запросить набор данных из общего webServicesClass, эта задача запускается в новом NSThread -> это создаст экземпляр объекта, который только извлекает xml и возвращает его в webServicesClass -> webServicesClass теперь создает экземпляры объект, который может только анализировать некоторые XML, поступающие от этого конкретного веб-сервиса. Затем Parser возвращает хороший объект Entity в webServiceClass. Теперь WebserviceClass должен сообщить viewController об этих данных.

viewController реализует webServiceClassDelegate и некоторые методы делегата, чтобы увидеть, прошел ли запрос веб-службы, как планировалось. например - (void) aWebserviceFailed и - (void) aWebserviceSuccess.

0.5 Поскольку WebserviceClass - это другой NSThread, возникнет ли проблема при вызове методов делегата для основного NSThread в родительском объекте?

1.0 Я думаю, что этот дизайн является надежным, поскольку он полностью инкапсулирует поиск, анализ и возврат сущности в разных классах. Но мне придется писать методы делегирования и реализовывать протоколы делегирования на каждом этапе пути для каждого отдельного веб-сервиса. то есть начиная с самого низа, WebserviceClass должен реализовывать методы делегирования как для объекта, который извлекает XML (начало, сбой, успех), так и для объекта, который анализирует XML (начало, сбой, успех), и WebserviceClass должен иметь возможность делегируйте каждый из этих ответов в viewController, который снова должен реализовать методы делегирования из WebserviceClass (запуск, сбой, успех). Есть ли гораздо более простой способ сделать это?

У меня есть некоторый опыт проектирования шаблонов, но не от языков, которые используют делегирование столь же последовательно, как Objective C. В AS3 или Java у меня были бы события, которые могли всплывать сквозь объекты и информировать любого, кто слушал об изменениях. Во всем коде примера Objective, который я прочитал, я видел только NSNotifications (который был бы эквивалентен «событию» AS3 или Java), используемому в 0,1% случаев.

Описанный мною дизайн даст мне что-то, что отлично масштабируется для многих веб-сервисов и даст мне полный контроль над тем, где происходит потенциальная ошибка / исключение, но, похоже, много кода для получения этой слабой связи.

1.1 Или я должен полностью принять подход делегирования и приступить к работе:)

Спасибо за любые указатели или помощь, оказанную. Я не спрашиваю об исходном коде или подобных вещах, более того «это считается наилучшей практикой в ​​Цели C в повседневной ситуации, которую вы только что описали»

Answer 1

Я бы рекомендовал взглянуть на ASIHttpRequest (доступно здесь ) и NSOperation + NSOperationQueue (документы здесь ). Я не думаю, что вам следует запускать долгоживущий поток, чтобы постоянно общаться с вашим веб-сервисом, если только вам абсолютно не нужно постоянное соединение.

В основном ASIHttpRequest и NSOperation оба инкапсулируют все сетевое и многопоточное содержимое. Операции делают многопоточность на iPhone действительно приятной. По сути, вы создаете операцию (с помощью фабрики или чего-то еще для простоты использования), помещаете ее в очередь и что-то делаете с результатом.

Что касается того, что вы делаете с результатом (это относится и к вашему исходному сценарию, и 0.5 и 1.1 ), что обычно происходит, когда ваша операция / поток затем вызовет метод didSucceedAtGettingWhatever или didFailWithError:(NSError*) , Делегирование - в значительной степени дефактный способ делать запросы по телефону. Если есть несколько делегатов, вы можете просто использовать объект-наблюдатель, как в Java.

Что касается 1,0 , в конечном итоге нет. Как правило, у нас есть OperationDelegate и OperationTypes. На основании того, какой OperationType был успешным или завершенным, у нас другая логика. Это не самый лучший способ, и существует множество способов сделать это, но вам придется иметь отдельную логику для отдельных событий независимо от того, что вы делаете. Независимо от того, является ли это одним или несколькими методами, решать только вам.