Morgerion

Вопросы о огромных списках со сложными элементами и картинками

В теме 14 сообщений

Добрый день всем.
У меня много вопросов, но надеюсь что собрать ответы в одном месте это хорошая идея, так как вопросы довольно типичные и ответы могут пригодиться многим.
Я делаю прототип приложения для iOS/Android. В приложении подразумевается что пользователь может делать фото, отсылать на сервер, разрешать его просматривать другим пользователям. Картинки, которые могут использоваться в приложении в большом количестве - фото и аватары пользователей.

Вопросы:

  • Как реализовать список из сложных фреймов, если их будет очень много? (картинка вот)
    test.png
    Я пока думаю использовать TFrame внутри TFramedVertScrollBox, но есть неясность - что делать если таких записей может быть очень много? Чисто в теории например 10000?
    Где-то был совет сделать небольшое число фреймов и при пролистывании гонять их по кругу, заполняя их новыми данными, получая их с сервера. Как это можно вообще сделать?
     
  • Как менеджментить аватары пользователей?
    Допустим, пользователь просматривает список других людей в приложении, соответственно там рисуются их аватары и имена. И их может быть 100 или 1000. Как оптимальнее управлять этими данными?
    В смысле, придется же получать картинки аватаров сотнями - а где их хранить в этот момент так что б всё не упало? можно ли где-то оформить самодельный файловый кэш на iOS/Android?
     
  • Есть ли типичное решение для обработки подгрузки списка?
    Как уже видно, маячит ситуация, когда в приложении будут большие списки (да еще и с картинками), поэтому сразу их грузить целиком будет нереально и придется делать догрузку при пролистывании.
    Есть ли какой-то типичный хороший метод (или пример) как сделать это?
     
  • Какую клиент-сервер технологию выбрать, если у меня сервер на windows?
    Подразумеваются редкие однократные запросы от пользователей.
    Грубо говоря, кто-то отправил фото, кто-то обновил свою ленту и получил с сервера новые фото.
    Серверную часть аппы я собираюсь написать сам.
    Я уже подсмотрел в соседней теме, что можно взять готовый бэкенд  http://scorocode.github.io/scorocode-docs/httpapi/appapi/ а для запроса использовать THttpClient.
     
  • Как менять формы на FMX (и принято ли их менять)?
    В здешних темах прочитал что лучше не создавать несколько форм, а использовать Tab Control без отображения вкладок. Это действительно так?

Заранее благодарю за ответы!
 

Изменено пользователем Morgerion

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, Morgerion сказал:

Как реализовать список из сложных фреймов, если их будет очень много?

Использовать ЛистВью. Для подобного списка, как на картинке, в реализации ничего сложного

По подгрузке данных "на лету", по асинхронной загрузке картинок есть пример у Равиля в репозитории ModernListView

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

если 8-10 можно и в листбоксе

я уже предлагал вариант сделать фрейм и создавать экземпляры для каждого ListBoxItem

если ListView вижу единственное препятствие - реализацию гиперссылки "подробнее" как на картинке

с другой стороны, так обычно не делают в мобильных интерфейсах, и подойдет обычное image.png.297ccc37a574c2ad62da118b0010ca36.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

sinuke, krapotkin - огромное спасибо за отклик!

Поясните пожалуйста про ListView - это что ж фреймы (TFrame) в него пихать? т.е. я сначала делаю фрейм с темплейтом, а потом его размножаю внутри ListView?
И как циркулировать итэмы если их 8-10? ведь что бы адекватно работала прокрутка ListView должен будет как бы думать что в нем, например, 1000 этих итэмов.
Про гиперссылку на итэме - это что бы открыть другой экран с более подробной информацией. Стрелочка тоже подойдет, вообще любой кликабельный элемент подойдет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
8 часов назад, krapotkin сказал:

если ListView вижу единственное препятствие - реализацию гиперссылки "подробнее" как на картинке 

я делал. просто чутка кода нужно, но все делается

anim.gif.de11907a98e08c71a1b3d544005fee07.gif

Демо проектик: [Tokyo] LV_URL_Demo.zip

 

7 часов назад, Morgerion сказал:

Поясните пожалуйста про ListView - это что ж фреймы (TFrame) в него пихать

Нет. Не фреймы. ЛистВью - компонент, который рисует себя сам. Он не является контейнером для любых TControl. Поэтому придется самому все рисовать. Лично я "рисую" все кодом. Долговато в реализации, в начале не понятно как делать, но если разобраться, то сразу будет видна разница в скорости работы. ЛистВью очень шустрый компонент. Единственное, я не реализовывал поджинацию, но знаю что ее не так уж и сложно сделать на основе ЛистВью

Изменено пользователем sinuke

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

sinuke - огромное спасибо! я нашел в соседних темах про ListView твой пример, где создаются сложные итэмы - вообще супер тема!

по динамической загрузке - посмотрел и протестировал пример Равиля, там тоже все просто.

по менеджменту форм - пока разместил восемь штук внутри TabControl (без отображения панели вкладок) - работает отлично.

остается вопрос по менеджменту картинок: допустим, пользователь просматривает профили и картинки других пользователей, по хорошему эти картинки надо как-то кэшировать что бы не подгружать постоянно в каждом новом сеансе. обсуждались ли тут какие-то решения на эту тему?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
12 часов назад, Morgerion сказал:

остается вопрос по менеджменту картинок: допустим, пользователь просматривает профили и картинки других пользователей, по хорошему эти картинки надо как-то кэшировать что бы не подгружать постоянно в каждом новом сеансе. обсуждались ли тут какие-то решения на эту тему?

свой класс на дженерике с ключом и картинкой, с проверкой занимаемой памяти и освобождением старых при превышении определенной границы.

НО!! Все это будет все равно тормозить на больших объемах. Ибо все в листвью через попу. Что бы определить видим или нет итем, листвью пробегается по всем итемам, и вычисляет их высоту и зная позицию скрола вычисляет видим или нет итем. чем больше полей, тем больше вычилений при каждом движении. 

Изменено пользователем haword

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, другого способа вроде и нет, кроме как кэшить жту инфу. Но бесконечные списки должны сами удалять себе голову и добавлять хвост. Чтобы оставаться в пределах разумного размера

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
12 часов назад, haword сказал:

Что бы определить видим или нет итем, листвью пробегается по всем итемам, и вычисляет их высоту и зная позицию скрола вычисляет видим или нет итем. чем больше полей, тем больше вычилений при каждом движении

Я думаю что на первых порах этим можно пренебречь, например проверить координаты даже 10 000 прямоугольников это не проблема. А вот 10 тысяч картинок точно хранить не стоит. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
15 часов назад, Morgerion сказал:

Я думаю что на первых порах этим можно пренебречь, например проверить координаты даже 10 000 прямоугольников это не проблема. А вот 10 тысяч картинок точно хранить не стоит. :)

лист на 3000 позиций в делфи и такой же в андроиде, по плавности скрола небо и земля. на среднестатистическом телефоне конечно не на топовом.  

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

Изменено пользователем haword

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3000 ?

3000 * 50 кб по моим подсчетам на 150 мб потянет

для мобилки не перебор?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, krapotkin сказал:

3000 ?

3000 * 50 кб по моим подсчетам на 150 мб потянет

для мобилки не перебор?

1. интересно откуда взялись именно 3000 ?
2. откуда взялись именно 50кб ?
3. 150 мб для мобилки - да вроде не перебор. недавно я принимал участие в разработке игры для мобилок (фермы), так там филлрейт 200..300 мб на каждый кадр! и ничо, работает даже на средних смартфонах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 27.12.2018 в 16:56, krapotkin сказал:

3000 ?

3000 * 50 кб по моим подсчетам на 150 мб потянет

для мобилки не перебор?

3000 это то что было у меня. но причем тут 50 кб? 3000 это чисто текстовые позиции, картинки через кеш и подгрузку были. 

поэтому мне и нравится подход к этому делу андроидного грида, он каждый раз при появлении нового итема грида делает запрос на заполнение данными. как итем пропал с экрана то он удаляется из памяти. ну как я понял его работу. 

Изменено пользователем haword

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну, так и работают все "бесконечные" списки новостей - при прокрутке удаляем уже прокрученное и в фоне зачитываем предстоящие позиции.

а в андроиде чуваки даже семинар специальный делали, рассказывали как они пытались ускорить списки, и описывали подход с адаптерами

в обычном VCL примерно так же работает Virtual Tree View - ничего не хранит, все что нужно запрашивает у программиста

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу