Comments 28
К конечному выводу: по сути эволюция вами расматривается только как рост, но эволюция это и отсекание рудиментарных частей, т.е. все всегда отлично когда первое архитектурное решение оказалось верным в пристреле на будущее, но все допускают ошибки в том числе и разработчики, что связанно со сложностями видеть наперет на нескольок шагов эволюции продукта и архитектуры. Отсюда складывается, что одни считают, что огрехи в старых версиях менее приоритетны, чем обратная совместимость (плюсы в краткосросной первспективе = думаем о старом и не тревожим разработчиков). И другой пусть, с другим приоритетом, где часть хлапот ложится на разработчиков, но с прицелом на будущее правильное поведение системы. Каждая компания выбирает приоритет. В случае с эплом, у них меньшая инертность, возможно из-за руководителя и меньшей боязни вносить изменения не на первом этапе, что судя по книге о Джобсе в эпл имеет место достаточно часто.
И после всех нововведений Windows 8, вы называете Apple революционерами?
ps: А также напомню про Windows Mobile, ни чего похожего не имеющую с Windows Phone 7.
По сравнению с Windows, Эпл просто допиливает свою систему.
ps: А также напомню про Windows Mobile, ни чего похожего не имеющую с Windows Phone 7.
По сравнению с Windows, Эпл просто допиливает свою систему.
Если смотреть на изменения в системе/контролах/т.д. то Apple скорее «перепиливает» систему, причем с 0
Чел, ты кажется статьи попутал :)
И после всех нововведений Windows 8, вы называете Apple революционерами?
Какие нововведения? Border-radius убрали? Так это можно было ещё в IE6 увидеть.
В Windows 8 есть нововведения? o_O
Все-таки это старое поведение было багом.
Есть вполне четкий гаидлайн для UI компонентов: генерировать события должны пользовательские действия; программные изменения свойств не должны генерировать этих событий.
Это выполняется и для UITabBar (изменение активного таба), и для UITableView (-selectRowAtIndexPath:...), и, в общем-то, должно выполняться для всех остальных вьюх.
Иначе неизбежно появляются проблемы в задачах где пользовательские действия должны обрабатываться несколько иначе чем внешние события (таймер или сеть, как пример). А иногда возникает циклическое порождение событий, если в обработчике нужно изменить свойства сэндера.
Так что этот код:
Есть вполне четкий гаидлайн для UI компонентов: генерировать события должны пользовательские действия; программные изменения свойств не должны генерировать этих событий.
Это выполняется и для UITabBar (изменение активного таба), и для UITableView (-selectRowAtIndexPath:...), и, в общем-то, должно выполняться для всех остальных вьюх.
Иначе неизбежно появляются проблемы в задачах где пользовательские действия должны обрабатываться несколько иначе чем внешние события (таймер или сеть, как пример). А иногда возникает циклическое порождение событий, если в обработчике нужно изменить свойства сэндера.
Так что этот код:
[self setSelectedSegmentIndex:ind];
if (SYSTEM_VERSION >= 5.0)
[self sendActionsForControlEvents: UIControlEventValueChanged];
Да и вообще, скорее всего, вы по крайней мере часть действий, которые должны происходить в обработчике нотификаций от модели делаете в обработчике (IBAction'е в данном случае) сообщений от вью. Тоесть смешиваете ответственность модели и представления. Отсюда и проблемы.
UFO just landed and posted this here
Не должны.
Да, некоторые вью могут предоставлять некий набор оповещений, причем отличный от user actions.
Но общий принцип эвентов у view — сообщить о пользовательских действиях.
К тому же, такие методы, во-первых, как я уже говорил, размывают границу между моделью и представлением, а во-вторых, в правильно организованном приложении, часто окажутся просто избыточными и невостребованными, т.к. вьюконтроллер все-равно получит оповещение от модели.
Да, некоторые вью могут предоставлять некий набор оповещений, причем отличный от user actions.
Но общий принцип эвентов у view — сообщить о пользовательских действиях.
К тому же, такие методы, во-первых, как я уже говорил, размывают границу между моделью и представлением, а во-вторых, в правильно организованном приложении, часто окажутся просто избыточными и невостребованными, т.к. вьюконтроллер все-равно получит оповещение от модели.
UFO just landed and posted this here
Вот долго думал стоит отвечать вам или нет.
Давайте не будем заниматься диалектикой. Вы пропустили vital point моих аргументов, и пытаетесь интерпретировать мои слова на свой вкус.
Я не мастер разговорного жанра. Если хотите по-существу, давайте так, вы приводите пример, где считаете подобные нотификации необходимыми. Я пытаюсь это опровергнуть через корректно реализованное MVC.
Другой формат спора я не приемлю.
Давайте не будем заниматься диалектикой. Вы пропустили vital point моих аргументов, и пытаетесь интерпретировать мои слова на свой вкус.
Я не мастер разговорного жанра. Если хотите по-существу, давайте так, вы приводите пример, где считаете подобные нотификации необходимыми. Я пытаюсь это опровергнуть через корректно реализованное MVC.
Другой формат спора я не приемлю.
UFO just landed and posted this here
Вы же описали точно ту же ситуацию, что и автор поста. Только у вас два поля, а в оригинальном топике (условно) панель, отображающая несколько вьюх, и свич контрол.
Решается, очевидно, аналогично.
Решается, очевидно, аналогично.
UFO just landed and posted this here
Перечитайте еще раз мои ответы. Только внимательно.
Я сказал, что если программное изменение состояния вью, генерирует эвент, это может породить вполне конкретные проблемы.
Также я сказал, что любой случай когда подобного рода эвенты кажутся необходимыми, это не так, и правильно организованное MVC такую проблему устраняет.
Про какую некорректность идет речь?
Еще раз, внимание: если вью порождает одни и те же нотификации как от пользовательских действий, так и от программного изменения состояния, могут появиться труднообходимые проблемы, которые, в общем-то решаются, но костыльными методами, типа установки локальных флагов (о чем упоминал jeen ниже); когда же view сообщает только о пользовательских действиях, в правильно организованном коде, необходимые нотификации о программных изменениях будут получены от моделей.
Вы, как я вижу, с циклическим порождением нотификаций еще не сталкивались. В кастомных компонентах подобного рода ошибок проектирования много. Ну что ж, значит еще предстоит. Вспомните этот топик :)
Я сказал, что если программное изменение состояния вью, генерирует эвент, это может породить вполне конкретные проблемы.
Также я сказал, что любой случай когда подобного рода эвенты кажутся необходимыми, это не так, и правильно организованное MVC такую проблему устраняет.
Про какую некорректность идет речь?
Еще раз, внимание: если вью порождает одни и те же нотификации как от пользовательских действий, так и от программного изменения состояния, могут появиться труднообходимые проблемы, которые, в общем-то решаются, но костыльными методами, типа установки локальных флагов (о чем упоминал jeen ниже); когда же view сообщает только о пользовательских действиях, в правильно организованном коде, необходимые нотификации о программных изменениях будут получены от моделей.
Вы, как я вижу, с циклическим порождением нотификаций еще не сталкивались. В кастомных компонентах подобного рода ошибок проектирования много. Ну что ж, значит еще предстоит. Вспомните этот топик :)
Тот код — это быстрый фикс ситуации, которая была порождена изначальным плохим дизайном компонента UISegmentedControl.
Глобально, я согласна, что генерировать события должны только пользовательские действия.
Глобально, я согласна, что генерировать события должны только пользовательские действия.
Это уже давно известное исправление бага в поведении UISegmentedControl. Раньше наоборот боролись, что-бы этих уведомлений небыло, когда из кода меняешь значение. Флажками там всякими. Если следовать гайдам, то все работатет как надо.
Согласна с тем, что новое поведение UISegmentedControl более правильно и соответствует guidelines.
Хотелось на этом примере отметить в статье, что приложение собранное на iOS 4 работает на iOS 5 старым образом, а собранное с новым SDK работает по-другому.
Хотелось на этом примере отметить в статье, что приложение собранное на iOS 4 работает на iOS 5 старым образом, а собранное с новым SDK работает по-другому.
Интересно узнать мнение автора — если бы вы разрабатывали ОС, как бы вы поступали? Я вижу 2 пути:
1) Всеми силами держаться за обратную совместимость. Приложения, написанные 10 лет назад, должны без проблем, или без особых проблем идти на новой системе. Но в угоду совместимости мы не можем зафиксить старые баги, щели, сделать более удобную SDK. Получим MS Windows.
2) Делать как Apple — выпилить GC из 10.7, Carbon из 10.6. Или вот класть на совместимости в мобильных ОС. Но SDK остаётся относительно чистым и красивым.
Есть ли золотая середина? Если честно, я испытываю далеко не радость, читая про новый апдейт iOS, скорее «блин, ещё геморроя прибыло!»
Но и помню то время, когда программировал на MFC.
P.S. Приятно было увидеть ссылку на мою статью в Вашей, спасибо :)
1) Всеми силами держаться за обратную совместимость. Приложения, написанные 10 лет назад, должны без проблем, или без особых проблем идти на новой системе. Но в угоду совместимости мы не можем зафиксить старые баги, щели, сделать более удобную SDK. Получим MS Windows.
2) Делать как Apple — выпилить GC из 10.7, Carbon из 10.6. Или вот класть на совместимости в мобильных ОС. Но SDK остаётся относительно чистым и красивым.
Есть ли золотая середина? Если честно, я испытываю далеко не радость, читая про новый апдейт iOS, скорее «блин, ещё геморроя прибыло!»
Но и помню то время, когда программировал на MFC.
P.S. Приятно было увидеть ссылку на мою статью в Вашей, спасибо :)
Для развития платформы второй вариант безусловно предпочтительней.
Золотая середина, на мой взгляд в том, чтобы сделать переходы максимально безболезненными: например, в данном случае, можно было бы создать новый UISegmentedControl с правильным поведением, а прошлый задепрекейтить в следующей версии iOS.
Тогда проблема бы возникла, как warning при компиляции, и форсила бы переход на новый контрол.
При переходе на что-то новое вполне логично узнать об отличиях от старого.
P.S.: За статью спасибо большое, она навела на интересные мысли :)
Золотая середина, на мой взгляд в том, чтобы сделать переходы максимально безболезненными: например, в данном случае, можно было бы создать новый UISegmentedControl с правильным поведением, а прошлый задепрекейтить в следующей версии iOS.
Тогда проблема бы возникла, как warning при компиляции, и форсила бы переход на новый контрол.
При переходе на что-то новое вполне логично узнать об отличиях от старого.
P.S.: За статью спасибо большое, она навела на интересные мысли :)
Sign up to leave a comment.
Начинающим разработчикам: история одного бага, или За что можно не любить новые версии iOS