Перейти к содержанию
Fire Monkey от А до Я

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


Morgerion

Рекомендуемые сообщения

Добрый день всем.
У меня много вопросов, но надеюсь что собрать ответы в одном месте это хорошая идея, так как вопросы довольно типичные и ответы могут пригодиться многим.
Я делаю прототип приложения для 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
Ссылка на комментарий
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 - ничего не хранит, все что нужно запрашивает у программиста

Ссылка на комментарий

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

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

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