Круть. Еще бы пальцы отбить дизайнерам интерфейсов, которые так не делают. С 2009 года борюсь с кальками на айфон с глобальными табами, функциями кнопки back и т.п.
Зачем вам новый дизайн? Просто сделайте как на айфоне!
Боже, как увидел GENERATE_SETTER, так аж в глазах помутнело, давление подскочило и чуть не вытошнило. Да и вообще код так себе, видно что плюсовик-теоретик писал, никак не опытный Obj-C программист.
Хороший вопрос. Когда я был менеджером, я тратил еще часа 2 в день на митинги с заказчиками (вел несколько проектов), занимался пресейлом, код ревью джуниоров и преподавал в лабе. Но это на относительно большой конторе, ок. 250 человек.
Видимо, не обошлось без кумовства. Обычно как раз такие люди, приближенные, занимают самые бесполезные должности, или занимаются ерундой на полезных пока всю реальную работу тянет один человек.
Рискну предположить, что в системах управления проектами зачастую все написано по-английски. И когда ты каждый день видишь надписи Use case, User story, Task — так и начинаешь говорить. А когда говоришь часто с иностранцами — сия вредная практика только закрепляется.
По поводу мажоритарности трех датчиков — как раз смотрел про этот случай по Discovery, по-моему даже в гражданской авиации было а не в военной. Точно не помню, но вроде ошибка была даже программной, а не аппаратной.
frame можно вывести в консоль через po [NSValue valueWithCGRect:view.frame].
С констрэйнтами есть такая беда — они очень плохо работают в иерархии вьюх, в которых то используется, то не используется автолэйаут. Мой совет — все же переделать ячейку без autolayout.
Т.е. вы подписываетесь на изменение contentInset-a и рисуете хэдер сами? Был бы очень признателен, если бы вы рассказали про свой способ поподробнее, т.к. очень уж много времени убил на эти хэдэры…
Также спасибо за ссылку на DTCollectionViewManager, не сомневаюсь что очень полезная вещь. Но есть один существенный недостаток — любой ваш контроллер должен наследоваться от DTCollectionViewController. А т.к. в objective-c нет множественного наследования, наследоваться от чего-то другого невозможно.
А так конечно да, если данное требование не критично — модель шикарна. Так уже надоело менять Data Source, потом искать index path нужной ячейки и т.п!
Ох, и больную же вы тему подняли! Давно хотел написать подобную статью, все руки не доходили. Сколько ж я с ней намучался за последние полтора года, а как красиво все начиналось… поначалу я был в восторге и от API, и от возможностей. Глубоко уверен, что Apple стоит больше покрывать код юнит-тестами. Из того, что первым вспомнилось без мака под рукой:
1) UICollectionView плохо обрабатывает очень высокие ячейки. Если высота ячейки — около 5-10 экранов (в зависимости от устройства), она при скроле начинает сначала «снежить», а потом просто пропадает. При этом в Open Source-реализации PSTCollectionView такого бага не было обнаружено.
2) Знает тот, кто пробовал имитировать стандартное для UITableView «залипание» хэдеров секции. После очередного, довольно рандомного Y в contentOffset UICollectionView она перестает махом спрашивать NSLayoutAttributes для, в моем случае, первых пяти секций, и хоть ты убейся. Пиксель назад спрашивает, пиксель вперед — начинает с шестой.
Ну и все или почти все ваши случаи, конечно, встречал. Особенно асинхронность, которой не должно быть, или которая должна быть хотя бы управляемой, и проблемы с синхронизацией анимаций — сущий ад. Добавлю один пункт:
3) Попробуйте запустить какую-либо анимацию в ячейке, и одновременно после этого вызвать reloadData. Крэш обеспечен.
Эпплу по рукам за нефикс багов функционала, который вышел полтора года назад, и юнит-тесты и еще раз юнит-тесты. И функциональные тесты. Библиотеку пишете, а не RSS reader! Зато живые иконки часов сделать — это пожалуйста, это всем очень нужно…
Не понимаю вашего комментария. То, что reloadData работает асинхронно, я тоже узнал из личного опыта, и это, поверьте, было совсем не хорошей новостью — легко это проверить или сложно. А вдруг вам надо сначала перезагрузить данные, а потом сразу же вызвать какую-либо анимацию layout-а?
У руководителя и не должно быть какого-то особенного авторитета, он обычно такой же наемный работник как и непосредственный исполнитель. Опять же, как правильно заметили сверху, речь идет об отношении «работник-работник» и если возник такой конфликт — нужно не увольнять а копать.
Работать-то оно будет, но глючно. Ну к примеру есть у вас RESTful API, к процедурному ж вообще модель реляционную не привяжешь. Вы, скажем, удалили какую-то сущность, и кор дата пытается подчистить и обнулить все связи, которые указывали на эту сущность. Но это давно уже сделала серверная база данных! Получается, нужно писать хардкод — и код IS от таких хардкодов становится ужасно нечитаемым.
Хотите еще? Кор дата однопоточна, поэтому при запросе к серверу вам нужно создать синхронное NSUrlConnection-соединение. А если нужна авторизация NTLM и обработка Challenge-a? Создавайте семафоры, покрывайте код критическими секциями и т.п., но кровь из носа все должно отработать в одном потоке.
Во всех абсолютно случаях это избыточно и не нужно, любой самописный «фрэймворк» с сериализацией в объекты из JSON сработает куда лучше.
Зачем вам новый дизайн? Просто сделайте как на айфоне!
С констрэйнтами есть такая беда — они очень плохо работают в иерархии вьюх, в которых то используется, то не используется автолэйаут. Мой совет — все же переделать ячейку без autolayout.
Смените, пожалуйста, тон. Я подозреваю, что у вас не зря карма в минусе и вы со всеми так разговариваете.
А так конечно да, если данное требование не критично — модель шикарна. Так уже надоело менять Data Source, потом искать index path нужной ячейки и т.п!
1) UICollectionView плохо обрабатывает очень высокие ячейки. Если высота ячейки — около 5-10 экранов (в зависимости от устройства), она при скроле начинает сначала «снежить», а потом просто пропадает. При этом в Open Source-реализации PSTCollectionView такого бага не было обнаружено.
2) Знает тот, кто пробовал имитировать стандартное для UITableView «залипание» хэдеров секции. После очередного, довольно рандомного Y в contentOffset UICollectionView она перестает махом спрашивать NSLayoutAttributes для, в моем случае, первых пяти секций, и хоть ты убейся. Пиксель назад спрашивает, пиксель вперед — начинает с шестой.
Ну и все или почти все ваши случаи, конечно, встречал. Особенно асинхронность, которой не должно быть, или которая должна быть хотя бы управляемой, и проблемы с синхронизацией анимаций — сущий ад. Добавлю один пункт:
3) Попробуйте запустить какую-либо анимацию в ячейке, и одновременно после этого вызвать reloadData. Крэш обеспечен.
Эпплу по рукам за нефикс багов функционала, который вышел полтора года назад, и юнит-тесты и еще раз юнит-тесты. И функциональные тесты. Библиотеку пишете, а не RSS reader! Зато живые иконки часов сделать — это пожалуйста, это всем очень нужно…
Хотите еще? Кор дата однопоточна, поэтому при запросе к серверу вам нужно создать синхронное NSUrlConnection-соединение. А если нужна авторизация NTLM и обработка Challenge-a? Создавайте семафоры, покрывайте код критическими секциями и т.п., но кровь из носа все должно отработать в одном потоке.
Во всех абсолютно случаях это избыточно и не нужно, любой самописный «фрэймворк» с сериализацией в объекты из JSON сработает куда лучше.