Objective-C - Передача объектов модели в рабочий класс из контроллера

Question

Я полный новичок, работающий над моим первым проектом для iPhone. Я был разработчиком .NET в течение 4 лет, чтобы дать вам представление о том, откуда я. Я пытаюсь следовать шаблону MVC и делать все правильно в моем первом проекте. Я не хочу взламывать вещи, чтобы заставить их работать.

Вот моя ситуация: Я пытаюсь разобрать канал XML, который будет содержать только 1 объект. У меня есть объект модели, который представляет объект, который я получу при разборе фида XML. Я создал подкласс NSXMLParser и могу успешно проанализировать XML-фид и получить значения обратно (используя NSLog для проверки значений). Здесь происходит мое отключение. При переходе от моего контроллера к подклассу, как лучше всего вызвать XMLParser, заполнить объект модели и вернуть его в контроллер?

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

Answer 1

Если вы заставите ваш контроллер представления реализовывать протокол NSXMLParserDelegate и установите свойство делегата экземпляра NSXMLParser для вашего контроллера представления, ваш контроллер представления будет знать, когда синтаксический анализатор анализирует вещи и заканчивают свою работу . Другими словами, контроллер представления может использовать заполненную модель данных, как только подкласс анализатора сообщает делегату, что это сделано.

Кроме того, делегирование - это один из немногих шаблонов проектирования, которые приложения OS X (и особенно Apple API) интенсивно используют. По мере разработки iPhone вы, вероятно, будете находить и использовать делегатов повсюду.

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

Answer 2

Я бы поместил операцию разбора в NSOperation, внутри очереди операций. Затем он может выполняться в фоновом потоке (обратите внимание, что вам нужно проделать дополнительную работу, чтобы это произошло для асинхронных операций в NSOperation).

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

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

Answer 3

вы можете создать одноэлементный класс, который будет управлять всеми вашими общими действиями. Вы можете найти краткое руководство по созданию одноэлементных объектов здесь