Оцените решение (CollectionView - add/delete)

Добрый день!
Решаю такую, вроде как очень распространенную задачу:
Есть CollectionView, в который при прокрутке, если закончились данные, динамически подгружаются новые. Бесконечно добавлять в память данные нельзя, поэтому я для себя определил буфер в x-элементов, которые одновременно могут находиться в памяти. Если при добавлении мы превышаем это допустимое кол-во - с обратной стороны (где начало скролла) элементы "отваливаются" и выгружаются из памяти.

Столкнулся с некрасивой штукой: когда я удаляю n-элементов в начале и добавляю n-элементов в конце, делая после этого , то, понятное дело, автоматически смещаюсь в конец добавленных данных, на последний элемент.
Захотелось от этого избавиться - чтобы данные добавлялись/удалялись "молча", и пользователь находился в том же месте скролла, где он был до выполнения этой операции.

Пока родился вариант (работающий), который мне очень не нравится, т.к. отдает жестоким говнокодом:
Короче, высчитываю, сколько добавлено ячеек, какой их суммарный визуальный размер + расстояния между ячейками, и смещаюсь на эту величину. В итоге скролл, как мне и надо, стоит на одном месте.

Но что мне подсказывает, что есть нормальная реализация такого механизма.. Прочитал много разных источников - но не могу ничего такого интересного найти..
Буду благодарен рекомендациям!

0

А зачем уменьшать значение collectionView:numberOfItemsInSection:?
Поясню. К примеру, есть массив, из которого берутся данные. Предположим их там X. Грузим след. страницу - еще Y элементов. Выкашиваем из масива первые Z. Тут возможны варианты. Я бы заменял их на [NSNULL null]. Вы, по всей видимости, их просто выносите из массива. В любом случае numberOfItemsInSection должно возвращать X+Y. Только в вашем случае очередной элемент массива для настройки очередного села должени искаться по формуле X-Z.
Надеюсь, более или менее понятно изложил

Только мне сама постановка задачи не нравится. При правильной организации данных - это такие копейки...

1

Спасибо, попробую сделать так!

Постановка задачи вызвана необходимостью допилить проект предыдущего разработчика, в котором выполняется загрузка новостей при скроллинге . Просмотрев Instruments'ом, что там происходит с выделением памяти - увидел, что при таком скроллинге с подгрузкой она забивается страшными темпами (проект огромный и без единого комментария).
Выбрал для решения проблемы описанный в моем посте метод, как самый простой.

Добавлено через 45 минут
mobidevelop, вдвойне вам спасибо: посмотрел на выделение памяти с использованием вашей рекомендации, потом с использованием моей на реальном проекте - выигрыш мизерный. Так что память течет где-то совершенно в другом месте..

0

Проверьте какие объекты больше всего памяти съедают. Подозреваю, что это картинки.

0

Именно))
А конкретно - это категория с меткой "VM: ImageIO_JPEG_Data".
Походив по проекту, вижу, что все кладется и берется из БД, так что, вроде как, на первый взгляд, в оперативку много мусора не должно ложиться..
Буду сейчас поглубже копать..

0