Подгонка анимации какао в паттерны MVC / OOP - PullRequest
Новая
       26

Подгонка анимации какао в паттерны MVC / OOP

1 голос
/ 15 июля 2009

Шаблоны проектирования MVC / OOP говорят, что вы не устанавливаете свойство само по себе, вы просите объект установить его свойство. Точно так же в Какао вы не говорите объекту, когда рисовать себя. Код вашего объекта содержит подробную информацию о том, КАК он будет отрисовываться, поэтому мы доверяем фреймворкам принять решение , когда (по большей части) он должен рисовать.

Но когда дело доходит до анимации в Какао (в частности, Cocoa-Touch), кажется, что теперь мы должны взять под контроль , когда объект рисует себя из контроллера представления объектов. Я не могу отправить сообщение подклассу UIView с просьбой изменить какое-либо значение, а затем оставить его в покое, зная, что оно будет медленно (длительность = X) анимировать на новую позицию, альфа, вращение и т. Д. в зависимости от изменения собственности. Или я могу?

По сути, я ищу способ установить свойство и затем уйти. Вместо этого, мне кажется, мне нужно обернуть код, вызывающий объект, с просьбой изменить его свойство, с помощью анимационного блока своего рода "[UIView beginAnimations: nil context: NULL]; ... [UIView commitAnimations];"

Я получаю множество блоков анимации в моих контроллерах представления и ни одного в моих объектах просмотра ... Я думаю, я просто ищу кого-то, кто мог бы убедиться, что так все и сделано не пропуская что-то. Я не продвинулся намного дальше, чем анимация UIView в Cocoa-Touch, так что, может быть, это моя проблема, и пришло время копать глубже?!?

1 Ответ

0 голосов
/ 15 июля 2009

Вы правы, что UIView не анимирует изменения своих свойств по умолчанию, как это делает CALayer, но я не думаю, что это указывает на разрыв в MVC. Для Контроллера целесообразно указать View, как он должен трансформироваться. Это роль класса Controller настолько точно, насколько уместно для Controller знать правильный фрейм для просмотра и даже управлять макетом. Я согласен, что немного странно, что вы вызываете -beginAnimations:context: в классе UIView, а не в экземпляре, но на практике это действительно работает намного лучше, так как вы, возможно, захотите анимировать множество представлений вместе.

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

Я использую здесь «MVC» в типичном смысле какао. Вы правы, что это может не подходить для программы SmallTalk, но тогда SmallTalk Controllers играют гораздо более ограниченную роль (управление событиями пользовательского ввода). Какао значительно расширяет роль контроллеров в MVC, и я думаю, что это улучшение, даже если это означает, что теперь есть некоторые функции, которые могут входить либо в контроллер, либо в представление (и это одна из них).

...