Как стать автором
Обновить

Комментарии 7

спасибо конечно, но все же, чем не устроил UICollectionView?
Писать столько кода это типа нецелесообразно?

По количеству кода это примерно тоже самое, а то и меньше, чем делать используя UICollectionView. Ячейку всё равно бы пришлось писать, реализовывать методы делегата и датасорс. А так же центровку из коробки UICollectionView не предоставляет, соответственно код аналогичный scrollViewWillEndDragging необходимо было бы реализовывать.
Под капотом UICollectionView – очень много функционала, который здесь не нужен.
Разработанный компонент используется и так в нагруженной ленте и почему бы не сэкономить ресурсы пользователя.

НЛО прилетело и опубликовало эту надпись здесь

Задачи сэкономить ресурсы не стоит. Это скорей положительный сайд эффект.
Есть еще множество других способов, можно например на Metal, всё это реализовать.Стоит соблюдать баланс.
Текущая реализация не является универсальной. Я делюсь опытом и возможно кому то такой вариант подойдет на 100%, а кто то узнает как можно центрировать UIView в UIScrollView.
И еще один момент – я хотел показать, что не стоит сразу хватать первое решение, которое приходит в голову или которое можно найти в интернете, всегда можно попробовать свои подходы, которые отлично ложатся на поставленную задачу.

В Андроиде есть RecyclerView, который делает то же самое.
В iOS есть UICollectionView, который делает то же самое. Но его решили не использовать)
Ещё можно было реализацию упростить, сделав класс-наследник UIScrollView и внутри него реализовав реюз «ячеек» по типу той же UITableView (когда есть кэш ячеек, есть prepareToReuse и всё такое).

Тогда бы не было этих весёлых плясок с перемещением ячеек внутри scrollViewDidScroll:, т.к. можно было бы делать лэйаут всего видимого на экране прямо внутри layoutSubviews скролл-вью, как, насколько я понимаю, и подразумевалось писавшими UIKit людьми: определяешь видимый сейчас bounds, определяешь, ячейки с какими индексами должны быть видимы в этих bounds, создаешь / берёшь из кэша вьюхи для ещё не показанных ячеек, лэйаутишь их, а те, которые становятся невидимыми, убираешь с супервью и кладёшь в кэш. Снаружи остаётся только отдавать данные для наполнения этого скролл-вью и правильно реализовать targetContentOffset.

Такой вариант позволил бы не хардкодить количество ячеек на экране, а показывать столько, сколько влезает в ширину экрана (ваша реализация ведь совсем не подходит для iPad, где неплохо бы показать не один центральный и края двух соседних, а, допустим, три целиком и края двух). Ну и в ситуацию с «сломалось центрирование» вы бы так не попали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий