Кстати, не хочу разводить холивар, но флеш уже приличное время умеет не «дёргаться» при движении, а у вас при наведении на планету её анимация, не смотря на её скорость, очень дёрганная и мерцающая. Это просто не учтено было при разработке или такая проблема присутствует?
Ну это не первая моя статья, и я их пишу не из расчета выйти в топ, а чтобы она дошла точки назначения — читателя, кому она будет полезна:)
Хотя признаю за собой проблему того, что если не напишу статью «пока горячо», то могу потом её уже никогда не дописать, потому что некоторые вещи забываются, иногда энтузиазм пропадает и всё такое)
Ну на данный момент у статьи рейтинг +7 -7 = 0, и это немного обидно за статью туториал, особенно если её сольют:) А причина, как мне кажется, именно в них, хотя может статья действительно г*вно и а я как обычно слоупок и не знал%)
Видать мне надо заканчивать с юмором в статьях:) либо форсить тег irony;)
Конечно же финальное тестирование мы проводим на девайсах, это даже не обсуждается.
В статье идёт речь про первую фазу тестирования, поверхностного, если хотите.
просто конкретно это приложение — финансовое, где упор сделан на математику и расчеты, и именно их мы и тестируем в симуляторе, но никто на него не расчитывает как на 100% точную проверку приложения.
iOS направление разработки в конкретно этой фирме молодое, устройства будут закуплены в обязательном порядке позднее, само собой:)
Чем мне нравится iOS — в ней много вещей не делаются из расчета «это беда не наша, а слабого юзера\программиста», и я считаю что это львиная доля успеха данной платформы в целом. Поэтому поиск удобных, универсальных и лёгких для вхождения решений, а главное безопасных — всегда будет актуальным, как я считаю.
Вы правы, по работе часто приходилось работать в аутсорсе, и ещё чаще — руководить программистами, следить за их кодом, проводить код ревью, и у меня появилось железное правило, что нельзя им доверять. Нельзя просто доверить реализацию чего-то спорного, чтобы потом сказать «программист был недостаточно сильным», менеджеры этого не оценят, поэтому мне важно быть уверенным в технологиях, которые мы используем. И строковая идентификация, к примеру — крайне частая причина ошибок, которые ещё и не легко дебажить, именно поэтому я зацепился за эту тему и начал искать решение проблемы, что вылилось в итоге в отхождение от темы в сторону Observer-а. А паттерны они на то и паттерны, что вы прийдёте в незнакомый проект, увидите, что там есть некие сигналы, у них вызывают «addObserver\removeObserver» и «notify», и если вы «сильный программист», то вы сразу же узнаете этот паттерн и будете знать, как с ним работать:)
P.S. Не понимаю, кстати, боязни работать с Objective-C++, ведь кроме как смены расширения файла и редкого вкрапления С++ кода в основной код это больше ничего не меняет, но даёт кучу преимуществ мира С++, таких как шаблоны, например:)
А я и не говорил, что его не надо использовать, где Вы такое прочитали?:)
Не существует универсального решения, всегда для каждой задачи решение подбирается индивидуально, и Observer — это одно из решений задачи «локальных» оповещений, где требуется передавать типизированные параметры, иметь возможность легко подписываться и отписываться, а так же строго проверять соответствие подписчиков диспетчерам, вот и всё)
И немного оффтоп:
Вам приходилось работать в больших командах программистов? В outsource? Ничего личного, но просто мне кажется, что у Вас не большой опыт работы, когда нельзя полагаться только на свои навыки и знания, и поэтому Вы так максималистки воспринимаете «Если программист не пишет по Coding Style Guidelines — то он не должен работать в команде»:) гайдлайны — это лишь направляющие правила, но есть фирмы, где внутренние правила могут отличаться от них, а новый программист об этом не будет знать, либо по непривычке забудет.
Вы вообще мои сообщения читаете, или только по диагонали пробегаете?:) Вы сейчас очень эпично вырвали фразу из контекста идентификации события по строке, а не по объекту или указателю! В плюсах, в Java или в любом другом жёстко типизированном языке можно написать библиотеку, которая будет принимать строку и по ней диспатчить события, сути не поменяет. Какие к черту холивары про типизацию?
Если они создадут эти константы в одном проекте, то будет ошибка линковки. Если в разных — то всем пофигу, разве нет? )
Вот вам пример конфликта из-за того, что один из программистов не учел правило написания констант NC, которые везде советуют писать идентично содержанию константы. Это в одном проекте. А что, если Вы подключили либу, в которой используеца NC?
То, что предлагаете Вы — не работает в крупных проектах, где нельзя просто сказать «этот баг мы исправляли 2 недели, а не 2 дня, т.к. у нас в команде из 30ти человек работает не самый сильный программист, который случайно имя константы (sic!) чуть чуть не так написал»
Поймите, я не боюсь строк, а в случае с селекторами у нас ещё и warning об отсутствии такого селектора на объекте. Я боюсь отсутствия какой-либо проверки и хотя бы warning-а когда программист пишет
Разве API NC выглядят хуже, чем плюсовые шаблоны в Objective-C++ коде?
Да, и могу сказать почему:
1) Какие ключи будут у someUserInfoDictionary?
2) Каких типов?
3) Что будет, если программист А создал константу @«MyGlobalSomethingHappened», а потом программист B (который сидит через океан от программиста А) по случайному стечению обстоятельств тоже случайно завёл такую костанту и постит свои события, даже и не зная, что они конфликтуют с программистом А?
NotificationCenter:
1) robnapier.net/blog/thoughts-nsnotifications-42
2) от себя хочу лишь сказать, что, во-первых, меня смущают строковые ID событий (не все программисты знают, что для них надо заводить константы, чтобы не было потом проблем), во-вторых — отсутствие типизированного способа передать параметры в слушатели события (сейчашний вариант лишь передавая object в postNotification, и если нужна жесткая типизация — то приходится создавать по классу на каждый такой тип события). А так же общая проблема с KVO — это crash системы на стадии dealloc объекта, если программист не отписался от событий KVO или NC.
Во флеше я использовал EventDIspatcher, который очень близок к NC по API подписки\отписки, и подводные камни обоих решений выявляются довольно-таки быстро
Я тоже с этого начал:) Я вообще раньше Flash-ом занимался и там это usual way для Observer-а.
Возникающие проблемы:
1) нет проверки аргументов, на больших проектах выливается в критические места кода и копание в нём же
2) для таких вещей я предпочитаю блоки, а не селекторы, по причине того, что селекторы оставляют ссылку на объект, относительно которого их надо вызывать, это чаще приводит к утечкам памяти
3) у меня логика диспатчинга хранится внутри сигнала, он обособлен и это лучше, чем передача по интерфейсу, правда это имхо
4) вытекает из 3: необходимость наследоваться (либо тянуть категорию) логики «в котором хранились подписанты и метод invoke»
Правда, если лично Вам так удобней — то это тоже имеет место быть, но я решил всё же пойти дальше, т.к. статическая типизация аргументов invoke-а, подказка типов параметров для addObserver-а и тому подобное — сильно подкупают:)
А TestFlight я делал свой собственный локальный, так что поверьте я с ним знаком:)
девайсы для тестирования личные, поэтому их даём не постоянно.
Хотя признаю за собой проблему того, что если не напишу статью «пока горячо», то могу потом её уже никогда не дописать, потому что некоторые вещи забываются, иногда энтузиазм пропадает и всё такое)
Конечно же финальное тестирование мы проводим на девайсах, это даже не обсуждается.
В статье идёт речь про первую фазу тестирования, поверхностного, если хотите.
просто конкретно это приложение — финансовое, где упор сделан на математику и расчеты, и именно их мы и тестируем в симуляторе, но никто на него не расчитывает как на 100% точную проверку приложения.
iOS направление разработки в конкретно этой фирме молодое, устройства будут закуплены в обязательном порядке позднее, само собой:)
Вы правы, по работе часто приходилось работать в аутсорсе, и ещё чаще — руководить программистами, следить за их кодом, проводить код ревью, и у меня появилось железное правило, что нельзя им доверять. Нельзя просто доверить реализацию чего-то спорного, чтобы потом сказать «программист был недостаточно сильным», менеджеры этого не оценят, поэтому мне важно быть уверенным в технологиях, которые мы используем. И строковая идентификация, к примеру — крайне частая причина ошибок, которые ещё и не легко дебажить, именно поэтому я зацепился за эту тему и начал искать решение проблемы, что вылилось в итоге в отхождение от темы в сторону Observer-а. А паттерны они на то и паттерны, что вы прийдёте в незнакомый проект, увидите, что там есть некие сигналы, у них вызывают «addObserver\removeObserver» и «notify», и если вы «сильный программист», то вы сразу же узнаете этот паттерн и будете знать, как с ним работать:)
P.S. Не понимаю, кстати, боязни работать с Objective-C++, ведь кроме как смены расширения файла и редкого вкрапления С++ кода в основной код это больше ничего не меняет, но даёт кучу преимуществ мира С++, таких как шаблоны, например:)
Не существует универсального решения, всегда для каждой задачи решение подбирается индивидуально, и Observer — это одно из решений задачи «локальных» оповещений, где требуется передавать типизированные параметры, иметь возможность легко подписываться и отписываться, а так же строго проверять соответствие подписчиков диспетчерам, вот и всё)
И немного оффтоп:
Вам приходилось работать в больших командах программистов? В outsource? Ничего личного, но просто мне кажется, что у Вас не большой опыт работы, когда нельзя полагаться только на свои навыки и знания, и поэтому Вы так максималистки воспринимаете «Если программист не пишет по Coding Style Guidelines — то он не должен работать в команде»:) гайдлайны — это лишь направляющие правила, но есть фирмы, где внутренние правила могут отличаться от них, а новый программист об этом не будет знать, либо по непривычке забудет.
Вы вообще мои сообщения читаете, или только по диагонали пробегаете?:) Вы сейчас очень эпично вырвали фразу из контекста идентификации события по строке, а не по объекту или указателю! В плюсах, в Java или в любом другом жёстко типизированном языке можно написать библиотеку, которая будет принимать строку и по ней диспатчить события, сути не поменяет. Какие к черту холивары про типизацию?
Вот вам пример конфликта из-за того, что один из программистов не учел правило написания констант NC, которые везде советуют писать идентично содержанию константы. Это в одном проекте. А что, если Вы подключили либу, в которой используеца NC?
То, что предлагаете Вы — не работает в крупных проектах, где нельзя просто сказать «этот баг мы исправляли 2 недели, а не 2 дня, т.к. у нас в команде из 30ти человек работает не самый сильный программист, который случайно имя константы (sic!) чуть чуть не так написал»
На него то и останется ссылка.
С теми же блоками можно сделать:
Поймите, я не боюсь строк, а в случае с селекторами у нас ещё и warning об отсутствии такого селектора на объекте. Я боюсь отсутствия какой-либо проверки и хотя бы warning-а когда программист пишет
и API NC это легко позволяет.
а про
Да, и могу сказать почему:
1) Какие ключи будут у someUserInfoDictionary?
2) Каких типов?
3) Что будет, если программист А создал константу @«MyGlobalSomethingHappened», а потом программист B (который сидит через океан от программиста А) по случайному стечению обстоятельств тоже случайно завёл такую костанту и постит свои события, даже и не зная, что они конфликтуют с программистом А?
KVO:
1) www.mikeash.com/pyblog/key-value-observing-done-right.html
2) www.mikeash.com/pyblog/friday-qa-2012-03-02-key-value-observing-done-right-take-2.html
3) от себя добавлю, что KVO — это работа с строковыми keyPath-ами, что так же повышает вероятность ошибки
NotificationCenter:
1) robnapier.net/blog/thoughts-nsnotifications-42
2) от себя хочу лишь сказать, что, во-первых, меня смущают строковые ID событий (не все программисты знают, что для них надо заводить константы, чтобы не было потом проблем), во-вторых — отсутствие типизированного способа передать параметры в слушатели события (сейчашний вариант лишь передавая object в postNotification, и если нужна жесткая типизация — то приходится создавать по классу на каждый такой тип события). А так же общая проблема с KVO — это crash системы на стадии dealloc объекта, если программист не отписался от событий KVO или NC.
Во флеше я использовал EventDIspatcher, который очень близок к NC по API подписки\отписки, и подводные камни обоих решений выявляются довольно-таки быстро
Возникающие проблемы:
1) нет проверки аргументов, на больших проектах выливается в критические места кода и копание в нём же
2) для таких вещей я предпочитаю блоки, а не селекторы, по причине того, что селекторы оставляют ссылку на объект, относительно которого их надо вызывать, это чаще приводит к утечкам памяти
3) у меня логика диспатчинга хранится внутри сигнала, он обособлен и это лучше, чем передача по интерфейсу, правда это имхо
4) вытекает из 3: необходимость наследоваться (либо тянуть категорию) логики «в котором хранились подписанты и метод invoke»
Правда, если лично Вам так удобней — то это тоже имеет место быть, но я решил всё же пойти дальше, т.к. статическая типизация аргументов invoke-а, подказка типов параметров для addObserver-а и тому подобное — сильно подкупают:)