2014-01-03 3 views
2

Один из моих коллег предложил использовать NSNotificationCenter как своего рода центральный маршрутизатор/диспетчер в нашем приложении iOS. Поэтому, если мы хотим перейти от одного контроллера представления к другому, мы можем сделать это, просто отправив уведомление (необязательно с некоторой пользовательской информацией, чтобы инициализировать контроллер представления назначения), который класс одноточечного диспетчера действий поймает и выполнит переходную работу (в основном, навигация контроллер нажимает). В нашем приложении есть несколько мест, из которых вы можете перейти к одному и тому же контроллеру представления (с подробным представлением объекта). При таком подходе мы могли бы иметь это в одном месте и легко запускать его.Использование NSNotificationCenter в качестве центрального роутера/диспетчера действий

Это хорошая идея? Можете ли вы придумать какие-либо недостатки, может быть, даже серьезные проблемы в будущем?

+2

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

+0

Диспетчер действий делает больше, чем просто нажатие на навигационный стек. Он также загружает объект из REST API, который должен отображаться контроллером представления назначения, в комплекте с индикатором загрузки и тому подобным, и мы не хотим копировать этот код. –

+0

Я не знаю вашего полного приложения, поэтому лучшим выбором будет выбор 1.Scalability 2.ease of change 3.Memory и скорость. Обычно у меня есть класс serverbuddy, у которого есть все веб-службы, и через его метод я взаимодействую с REST api с моего целевого контроллера представления. – amar

ответ

0

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

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

Недостатком может быть то, что связь между различными частями может смущать программистов, начиная с этого кода. Зависит, конечно, от уровня знания этого человека.

Смежные вопросы