Перечитайте еще раз мои ответы. Только внимательно.
Я сказал, что если программное изменение состояния вью, генерирует эвент, это может породить вполне конкретные проблемы.
Также я сказал, что любой случай когда подобного рода эвенты кажутся необходимыми, это не так, и правильно организованное MVC такую проблему устраняет.
Про какую некорректность идет речь?
Еще раз, внимание: если вью порождает одни и те же нотификации как от пользовательских действий, так и от программного изменения состояния, могут появиться труднообходимые проблемы, которые, в общем-то решаются, но костыльными методами, типа установки локальных флагов (о чем упоминал jeen ниже); когда же view сообщает только о пользовательских действиях, в правильно организованном коде, необходимые нотификации о программных изменениях будут получены от моделей.
Вы, как я вижу, с циклическим порождением нотификаций еще не сталкивались. В кастомных компонентах подобного рода ошибок проектирования много. Ну что ж, значит еще предстоит. Вспомните этот топик :)
Вы же описали точно ту же ситуацию, что и автор поста. Только у вас два поля, а в оригинальном топике (условно) панель, отображающая несколько вьюх, и свич контрол.
Решается, очевидно, аналогично.
Вот долго думал стоит отвечать вам или нет.
Давайте не будем заниматься диалектикой. Вы пропустили vital point моих аргументов, и пытаетесь интерпретировать мои слова на свой вкус.
Я не мастер разговорного жанра. Если хотите по-существу, давайте так, вы приводите пример, где считаете подобные нотификации необходимыми. Я пытаюсь это опровергнуть через корректно реализованное MVC.
Другой формат спора я не приемлю.
Не должны.
Да, некоторые вью могут предоставлять некий набор оповещений, причем отличный от user actions.
Но общий принцип эвентов у view — сообщить о пользовательских действиях.
К тому же, такие методы, во-первых, как я уже говорил, размывают границу между моделью и представлением, а во-вторых, в правильно организованном приложении, часто окажутся просто избыточными и невостребованными, т.к. вьюконтроллер все-равно получит оповещение от модели.
Да и вообще, скорее всего, вы по крайней мере часть действий, которые должны происходить в обработчике нотификаций от модели делаете в обработчике (IBAction'е в данном случае) сообщений от вью. Тоесть смешиваете ответственность модели и представления. Отсюда и проблемы.
Есть вполне четкий гаидлайн для UI компонентов: генерировать события должны пользовательские действия; программные изменения свойств не должны генерировать этих событий.
Это выполняется и для UITabBar (изменение активного таба), и для UITableView (-selectRowAtIndexPath:...), и, в общем-то, должно выполняться для всех остальных вьюх.
Иначе неизбежно появляются проблемы в задачах где пользовательские действия должны обрабатываться несколько иначе чем внешние события (таймер или сеть, как пример). А иногда возникает циклическое порождение событий, если в обработчике нужно изменить свойства сэндера.
Так что этот код:
[self setSelectedSegmentIndex:ind];
if (SYSTEM_VERSION >= 5.0)
[self sendActionsForControlEvents: UIControlEventValueChanged];
можно считать плохим стилем или даже антипаттерном.
Простите конечно, но BlocksKit не «упрощает работу с блоками».
BlocksKit — это набор категорий над Foundation и UIKit классами, добавляющих методы, использущие блоки. Для итерации по коллекциям, для обработки эвентов и т.п.
Уж извините, но в статье огромное количество недопонимания и неточностей.
Самое основное, что в глаза бросается, и поломает ваш парсер на один чих:
1.
Во многих pdf'ах xref table, как и trailer вообще отсутствуют. Вместо них используется xref streams.
2.
Вторая группа и символ сообщают: существует ли объект на самом деле. 65535 f – объект не существует…
Это не так. Второе число — это generation. Если pdf обновлялся, он может быть отличен от 0, а 65535 — это зарезервированное значение для 0го объекта. Более того, в коде парсера xref table присутствует ошибка, из-за которой в таблице окажутся удаленные объекты (для некоторых pdf'ов).
3.
stream может быть сжат не только flate'ом, но и lzw и еще парой специфичных кодировок контроллируемых ключем /Filter в stream dictionary. И они, особенно lzw, на самом деле встречаются очень часто.
В общем, это пока даже не парсер, а так, proof of concept.
Вызовы методов — это не очень интересно.
Я вот так и не понял, можно ли, и если можно, то как сделать наследование, например, от какого-нибудь view controller'а, реализовать протокол и сделать этот класс делегатом чего-нибудь?
Таким комментарием обычно сопровождают описание Го.
Что, простите?
Я думал, что после хоткея 'T' в репозитории уже все видел :)
Я сказал, что если программное изменение состояния вью, генерирует эвент, это может породить вполне конкретные проблемы.
Также я сказал, что любой случай когда подобного рода эвенты кажутся необходимыми, это не так, и правильно организованное MVC такую проблему устраняет.
Про какую некорректность идет речь?
Еще раз, внимание: если вью порождает одни и те же нотификации как от пользовательских действий, так и от программного изменения состояния, могут появиться труднообходимые проблемы, которые, в общем-то решаются, но костыльными методами, типа установки локальных флагов (о чем упоминал jeen ниже); когда же view сообщает только о пользовательских действиях, в правильно организованном коде, необходимые нотификации о программных изменениях будут получены от моделей.
Вы, как я вижу, с циклическим порождением нотификаций еще не сталкивались. В кастомных компонентах подобного рода ошибок проектирования много. Ну что ж, значит еще предстоит. Вспомните этот топик :)
Решается, очевидно, аналогично.
Давайте не будем заниматься диалектикой. Вы пропустили vital point моих аргументов, и пытаетесь интерпретировать мои слова на свой вкус.
Я не мастер разговорного жанра. Если хотите по-существу, давайте так, вы приводите пример, где считаете подобные нотификации необходимыми. Я пытаюсь это опровергнуть через корректно реализованное MVC.
Другой формат спора я не приемлю.
Да, некоторые вью могут предоставлять некий набор оповещений, причем отличный от user actions.
Но общий принцип эвентов у view — сообщить о пользовательских действиях.
К тому же, такие методы, во-первых, как я уже говорил, размывают границу между моделью и представлением, а во-вторых, в правильно организованном приложении, часто окажутся просто избыточными и невостребованными, т.к. вьюконтроллер все-равно получит оповещение от модели.
Есть вполне четкий гаидлайн для UI компонентов: генерировать события должны пользовательские действия; программные изменения свойств не должны генерировать этих событий.
Это выполняется и для UITabBar (изменение активного таба), и для UITableView (-selectRowAtIndexPath:...), и, в общем-то, должно выполняться для всех остальных вьюх.
Иначе неизбежно появляются проблемы в задачах где пользовательские действия должны обрабатываться несколько иначе чем внешние события (таймер или сеть, как пример). А иногда возникает циклическое порождение событий, если в обработчике нужно изменить свойства сэндера.
Так что этот код:
[self setSelectedSegmentIndex:ind]; if (SYSTEM_VERSION >= 5.0) [self sendActionsForControlEvents: UIControlEventValueChanged];Осталось дождаться когда доклады с WWDC опубликуют и будет щасте!
Никого не защищаю, но, простите, где связь между содержанием ЕГЭ и теми кто делал и поддерживает этот сайт?
BlocksKit — это набор категорий над Foundation и UIKit классами, добавляющих методы, использущие блоки. Для итерации по коллекциям, для обработки эвентов и т.п.
Это оно и есть.
Извиняюсь, не обратил внимания.
Самое основное, что в глаза бросается, и поломает ваш парсер на один чих:
1.
Во многих pdf'ах xref table, как и trailer вообще отсутствуют. Вместо них используется xref streams.
2.
Это не так. Второе число — это generation. Если pdf обновлялся, он может быть отличен от 0, а 65535 — это зарезервированное значение для 0го объекта. Более того, в коде парсера xref table присутствует ошибка, из-за которой в таблице окажутся удаленные объекты (для некоторых pdf'ов).
3.
stream может быть сжат не только flate'ом, но и lzw и еще парой специфичных кодировок контроллируемых ключем /Filter в stream dictionary. И они, особенно lzw, на самом деле встречаются очень часто.
В общем, это пока даже не парсер, а так, proof of concept.
Я вот так и не понял, можно ли, и если можно, то как сделать наследование, например, от какого-нибудь view controller'а, реализовать протокол и сделать этот класс делегатом чего-нибудь?