UIViewКонтроллеры, Делегаты

Question

Является ли хорошей практикой выделять сложные задачи, которые управляют или определяют информацию, отображаемую в представлении UIViewController, и на самом деле не имеют отношения к загрузке подпредставлений и их макета в «делегат UIViewController», как это было?

[Возможно, примером могут быть игровой делегат и полноэкранный контроллер игрового представления (вид которого создается программно, скажем).Делегат приложения может знать о делегате игры, который знает о контроллере вида игры.]

Answer 1

То, что вы описываете, по сути встроено в шаблон проектирования MVC, который уже активно используется в iOS.

Рассмотрим приложение, которое визуализирует сетевой трафик.Вы можете иметь представление, которое отображает постоянно обновляемый график, один раз каждые N миллисекунд.Основные вычисления, определяющие график графика, могут быть сложными и выполняться сотни раз в секунду, тогда как вам может потребоваться обновлять пользовательский интерфейс только 30 раз в секунду.

Учитывая это гипотетическое приложение, вы можете поместить всекода, который отслеживает необработанный сетевой трафик и выполняет вычисления в классе Model.Затем, в зависимости от того, какой вариант MVC вы используете, у вас будет либо View, наблюдающий за изменениями модели напрямую (возможно, с помощью KVO), либо ваш контроллер будет наблюдать за моделью и затем непосредственно запускать обновление для View.с новым состоянием.