Спасибо за дополнение.
Однако, это всего лишь ответ на вопрос «почему это происходит». Ответа на вопрос «как это вообще допустили» он, к сожалению, не даёт.
Самый главный момент, от которого у меня бомбит, — это бесполезность флага UI_APPEARANCE_SELECTOR, который по сути — не более, чем просто пометка, что с помеченным свойством можно спокойно использовать Appearance, а с не помеченным — тоже можно, но никто ничего не гарантирует.
Но в отличие от тех же force unwrap в Swift, которые тоже можно использовать на свой страх и риск, неправильное использование свойства через Appearance, легко может поломать не только твой код, но и код в компонентах, которыми ты не владеешь. Без регистрации, смс и свизлинга.
Пункт #1 — готовые платные решения.
Последним способом тоже спокойно, запуская ресайз четырежды и более раз. При желании, можно допилить функционал, чтобы можно было добавлять неограниченное количество масок.
А вы на Андроид под OS X программируете?
Спасибо и вам на добром слове.
Кстати, я тут немного всем наврал по незнанию: в prepareLayout необязательно сразу весь contenSize высчитывать, потому что лэйаут всякий раз при скролле уточняет collectionViewContentSize. Так что можно просчитать на n-ное количество экранов вперед, а потом по мере надобности досчитывать дальше. Так что тут бооольшое пространство для оптимизации приведенной мной реализации.
Спасибо за ссылки. Глянул видеопрезентацию pngexpress. К сожалению, магию он творит только при условии, что дизайнер передал psd в просто идеально структурированном порядке, а это совсем нереальный вариант развития событий. Тем более для каждого элемента скорее всего все равно придется выставлять какие-то настройки. Я при таких условиях и вручную по полминуты на элемент потрачу. Единственный плюс — то, что приложение, если требуется, автоматически нарезает картинки для нескольких разрешений. Если надо больше чем изображения для iPhone и iPhone Retina, это преимущество будет ощутимым.
По поводу «переговорить с дизайнером» — это здорово, но есть маленький нюанс, который я описал в ответе к комментарию чуть выше
А вот автоматизационными решениями вы меня заинтриговали. Можно какие-нибудь ссылки? Если я пребывал до этого в лимбе, нарезая ресурсы вручную, а что-то стоящее действительно есть, я назову в вашу честь сына. Мне на ум из автоматизации процесса приходит разве что утилита, которая автоматически уменьшает в 2 раза картинки для ретины и сохраняет их.
P.S. Простите, про сына я преувеличил, без обид, но имя Кирилл мне совсем не нравится :)
Я бы с радостью работал с таким дизайнером как вы :)
Но проблема в том, что часто конспираторы-заказчики стараются не давать разработчику никаких выходов на дизайнера. Поэтому запрос на какие-то доработки идет через несколько кругов ада в лице всяческих менеджеров, и ответ тем же путем. Эффективность взаимодействия стремится сами понимаете куда.
Как мне кажется, 90 % причин всех багов в UICollectionView можно разделить на две категории:
1) множественные анимированные действия без performBatchUpdates блока;
2) наличие нескольких секций, хедеров (supplementary view) и футеров (decoration view).
Первое вроде как не тревожит, если все множественные вставки/удаления делать корректно и по науке (читай в performBatchUpdates) блоке.
По поводу второго, мне кажется, есть неплохой вариант, который даже вроде бы и не костыль вовсе. Суть в том, чтобы использовать только односекционные коллекции без футеров и хедеров. А уже эти коллекции использовать как ячейки UITableView, который и будет ответственным за возню со всеми этими хедерами и футерами (а он с этим неплохо справляется).
При секциях, предполагающих большое количество ячеек, конечно, таким грешить не стоит.
2) Знает тот, кто пробовал имитировать стандартное для UITableView «залипание» хэдеров секции.
А в вашем случае можно было использовать такой подход: обернуть коллекцию в таблицу, то есть каждая секция в вашей коллекции — ячейка в таблице, у которой на contentView лежит коллекция? В таблице же количество секций = количеству ячеек.
Та ж фигня. Стоит только добавить в теге img ссылку, которая встречается в тексте как ссылка (и просто текстом), после сохранения изменений исчезают все.
После десятка попыток отредактировать пост, я решил обойтись без нее. Картинку можно найти по ссылке Или вот тут, которая дважды встречается в тексте.
Интересный баг — если добавлять картинку, ссылка на которую уже есть в тексте, после публикации исчезают все ссылки на нее. Вернее, не интересный, а раздражающий.
Однако, это всего лишь ответ на вопрос «почему это происходит». Ответа на вопрос «как это вообще допустили» он, к сожалению, не даёт.
Самый главный момент, от которого у меня бомбит, — это бесполезность флага UI_APPEARANCE_SELECTOR, который по сути — не более, чем просто пометка, что с помеченным свойством можно спокойно использовать Appearance, а с не помеченным — тоже можно, но никто ничего не гарантирует.
Но в отличие от тех же force unwrap в Swift, которые тоже можно использовать на свой страх и риск, неправильное использование свойства через Appearance, легко может поломать не только твой код, но и код в компонентах, которыми ты не владеешь. Без регистрации, смс и свизлинга.
Последним способом тоже спокойно, запуская ресайз четырежды и более раз. При желании, можно допилить функционал, чтобы можно было добавлять неограниченное количество масок.
А вы на Андроид под OS X программируете?
Кстати, я тут немного всем наврал по незнанию: в prepareLayout необязательно сразу весь contenSize высчитывать, потому что лэйаут всякий раз при скролле уточняет collectionViewContentSize. Так что можно просчитать на n-ное количество экранов вперед, а потом по мере надобности досчитывать дальше. Так что тут бооольшое пространство для оптимизации приведенной мной реализации.
А вот автоматизационными решениями вы меня заинтриговали. Можно какие-нибудь ссылки? Если я пребывал до этого в лимбе, нарезая ресурсы вручную, а что-то стоящее действительно есть, я назову в вашу честь сына. Мне на ум из автоматизации процесса приходит разве что утилита, которая автоматически уменьшает в 2 раза картинки для ретины и сохраняет их.
P.S. Простите, про сына я преувеличил, без обид, но имя Кирилл мне совсем не нравится :)
Но проблема в том, что часто конспираторы-заказчики стараются не давать разработчику никаких выходов на дизайнера. Поэтому запрос на какие-то доработки идет через несколько кругов ада в лице всяческих менеджеров, и ответ тем же путем. Эффективность взаимодействия стремится сами понимаете куда.
1) множественные анимированные действия без performBatchUpdates блока;
2) наличие нескольких секций, хедеров (supplementary view) и футеров (decoration view).
Первое вроде как не тревожит, если все множественные вставки/удаления делать корректно и по науке (читай в performBatchUpdates) блоке.
По поводу второго, мне кажется, есть неплохой вариант, который даже вроде бы и не костыль вовсе. Суть в том, чтобы использовать только односекционные коллекции без футеров и хедеров. А уже эти коллекции использовать как ячейки UITableView, который и будет ответственным за возню со всеми этими хедерами и футерами (а он с этим неплохо справляется).
При секциях, предполагающих большое количество ячеек, конечно, таким грешить не стоит.
А в вашем случае можно было использовать такой подход: обернуть коллекцию в таблицу, то есть каждая секция в вашей коллекции — ячейка в таблице, у которой на contentView лежит коллекция? В таблице же количество секций = количеству ячеек.
Интересный баг — если добавлять картинку, ссылка на которую уже есть в тексте, после публикации исчезают все ссылки на нее. Вернее, не интересный, а раздражающий.