Комментарии 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'е в данном случае) сообщений от вью. Тоесть смешиваете ответственность модели и представления. Отсюда и проблемы.
НЛО прилетело и опубликовало эту надпись здесь
Не должны.
Да, некоторые вью могут предоставлять некий набор оповещений, причем отличный от user actions.
Но общий принцип эвентов у view — сообщить о пользовательских действиях.
К тому же, такие методы, во-первых, как я уже говорил, размывают границу между моделью и представлением, а во-вторых, в правильно организованном приложении, часто окажутся просто избыточными и невостребованными, т.к. вьюконтроллер все-равно получит оповещение от модели.
Да, некоторые вью могут предоставлять некий набор оповещений, причем отличный от user actions.
Но общий принцип эвентов у view — сообщить о пользовательских действиях.
К тому же, такие методы, во-первых, как я уже говорил, размывают границу между моделью и представлением, а во-вторых, в правильно организованном приложении, часто окажутся просто избыточными и невостребованными, т.к. вьюконтроллер все-равно получит оповещение от модели.
НЛО прилетело и опубликовало эту надпись здесь
Вот долго думал стоит отвечать вам или нет.
Давайте не будем заниматься диалектикой. Вы пропустили vital point моих аргументов, и пытаетесь интерпретировать мои слова на свой вкус.
Я не мастер разговорного жанра. Если хотите по-существу, давайте так, вы приводите пример, где считаете подобные нотификации необходимыми. Я пытаюсь это опровергнуть через корректно реализованное MVC.
Другой формат спора я не приемлю.
Давайте не будем заниматься диалектикой. Вы пропустили vital point моих аргументов, и пытаетесь интерпретировать мои слова на свой вкус.
Я не мастер разговорного жанра. Если хотите по-существу, давайте так, вы приводите пример, где считаете подобные нотификации необходимыми. Я пытаюсь это опровергнуть через корректно реализованное MVC.
Другой формат спора я не приемлю.
НЛО прилетело и опубликовало эту надпись здесь
Вы же описали точно ту же ситуацию, что и автор поста. Только у вас два поля, а в оригинальном топике (условно) панель, отображающая несколько вьюх, и свич контрол.
Решается, очевидно, аналогично.
Решается, очевидно, аналогично.
НЛО прилетело и опубликовало эту надпись здесь
Перечитайте еще раз мои ответы. Только внимательно.
Я сказал, что если программное изменение состояния вью, генерирует эвент, это может породить вполне конкретные проблемы.
Также я сказал, что любой случай когда подобного рода эвенты кажутся необходимыми, это не так, и правильно организованное 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.: За статью спасибо большое, она навела на интересные мысли :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Начинающим разработчикам: история одного бага, или За что можно не любить новые версии iOS