Morgerion Опубликовано 24 декабря, 2018 Поделиться Опубликовано 24 декабря, 2018 (изменено) Добрый день всем. У меня много вопросов, но надеюсь что собрать ответы в одном месте это хорошая идея, так как вопросы довольно типичные и ответы могут пригодиться многим. Я делаю прототип приложения для iOS/Android. В приложении подразумевается что пользователь может делать фото, отсылать на сервер, разрешать его просматривать другим пользователям. Картинки, которые могут использоваться в приложении в большом количестве - фото и аватары пользователей. Вопросы: Как реализовать список из сложных фреймов, если их будет очень много? (картинка вот) Я пока думаю использовать TFrame внутри TFramedVertScrollBox, но есть неясность - что делать если таких записей может быть очень много? Чисто в теории например 10000?Где-то был совет сделать небольшое число фреймов и при пролистывании гонять их по кругу, заполняя их новыми данными, получая их с сервера. Как это можно вообще сделать? Как менеджментить аватары пользователей? Допустим, пользователь просматривает список других людей в приложении, соответственно там рисуются их аватары и имена. И их может быть 100 или 1000. Как оптимальнее управлять этими данными? В смысле, придется же получать картинки аватаров сотнями - а где их хранить в этот момент так что б всё не упало? можно ли где-то оформить самодельный файловый кэш на iOS/Android? Есть ли типичное решение для обработки подгрузки списка? Как уже видно, маячит ситуация, когда в приложении будут большие списки (да еще и с картинками), поэтому сразу их грузить целиком будет нереально и придется делать догрузку при пролистывании. Есть ли какой-то типичный хороший метод (или пример) как сделать это? Какую клиент-сервер технологию выбрать, если у меня сервер на windows? Подразумеваются редкие однократные запросы от пользователей. Грубо говоря, кто-то отправил фото, кто-то обновил свою ленту и получил с сервера новые фото.Серверную часть аппы я собираюсь написать сам. Я уже подсмотрел в соседней теме, что можно взять готовый бэкенд http://scorocode.github.io/scorocode-docs/httpapi/appapi/ а для запроса использовать THttpClient. Как менять формы на FMX (и принято ли их менять)? В здешних темах прочитал что лучше не создавать несколько форм, а использовать Tab Control без отображения вкладок. Это действительно так? Заранее благодарю за ответы! Изменено 24 декабря, 2018 пользователем Morgerion Цитата Ссылка на комментарий
sinuke Опубликовано 24 декабря, 2018 Поделиться Опубликовано 24 декабря, 2018 5 часов назад, Morgerion сказал: Как реализовать список из сложных фреймов, если их будет очень много? Использовать ЛистВью. Для подобного списка, как на картинке, в реализации ничего сложного По подгрузке данных "на лету", по асинхронной загрузке картинок есть пример у Равиля в репозитории ModernListView Цитата Ссылка на комментарий
krapotkin Опубликовано 24 декабря, 2018 Поделиться Опубликовано 24 декабря, 2018 если 8-10 можно и в листбоксе я уже предлагал вариант сделать фрейм и создавать экземпляры для каждого ListBoxItem если ListView вижу единственное препятствие - реализацию гиперссылки "подробнее" как на картинке с другой стороны, так обычно не делают в мобильных интерфейсах, и подойдет обычное Цитата Ссылка на комментарий
Morgerion Опубликовано 24 декабря, 2018 Автор Поделиться Опубликовано 24 декабря, 2018 sinuke, krapotkin - огромное спасибо за отклик! Поясните пожалуйста про ListView - это что ж фреймы (TFrame) в него пихать? т.е. я сначала делаю фрейм с темплейтом, а потом его размножаю внутри ListView? И как циркулировать итэмы если их 8-10? ведь что бы адекватно работала прокрутка ListView должен будет как бы думать что в нем, например, 1000 этих итэмов. Про гиперссылку на итэме - это что бы открыть другой экран с более подробной информацией. Стрелочка тоже подойдет, вообще любой кликабельный элемент подойдет. Цитата Ссылка на комментарий
sinuke Опубликовано 25 декабря, 2018 Поделиться Опубликовано 25 декабря, 2018 (изменено) 8 часов назад, krapotkin сказал: если ListView вижу единственное препятствие - реализацию гиперссылки "подробнее" как на картинке я делал. просто чутка кода нужно, но все делается Демо проектик: [Tokyo] LV_URL_Demo.zip 7 часов назад, Morgerion сказал: Поясните пожалуйста про ListView - это что ж фреймы (TFrame) в него пихать Нет. Не фреймы. ЛистВью - компонент, который рисует себя сам. Он не является контейнером для любых TControl. Поэтому придется самому все рисовать. Лично я "рисую" все кодом. Долговато в реализации, в начале не понятно как делать, но если разобраться, то сразу будет видна разница в скорости работы. ЛистВью очень шустрый компонент. Единственное, я не реализовывал поджинацию, но знаю что ее не так уж и сложно сделать на основе ЛистВью Изменено 25 декабря, 2018 пользователем sinuke Ingalime 1 Цитата Ссылка на комментарий
Morgerion Опубликовано 25 декабря, 2018 Автор Поделиться Опубликовано 25 декабря, 2018 sinuke - огромное спасибо! я нашел в соседних темах про ListView твой пример, где создаются сложные итэмы - вообще супер тема! по динамической загрузке - посмотрел и протестировал пример Равиля, там тоже все просто. по менеджменту форм - пока разместил восемь штук внутри TabControl (без отображения панели вкладок) - работает отлично. остается вопрос по менеджменту картинок: допустим, пользователь просматривает профили и картинки других пользователей, по хорошему эти картинки надо как-то кэшировать что бы не подгружать постоянно в каждом новом сеансе. обсуждались ли тут какие-то решения на эту тему? Цитата Ссылка на комментарий
haword Опубликовано 26 декабря, 2018 Поделиться Опубликовано 26 декабря, 2018 (изменено) 12 часов назад, Morgerion сказал: остается вопрос по менеджменту картинок: допустим, пользователь просматривает профили и картинки других пользователей, по хорошему эти картинки надо как-то кэшировать что бы не подгружать постоянно в каждом новом сеансе. обсуждались ли тут какие-то решения на эту тему? свой класс на дженерике с ключом и картинкой, с проверкой занимаемой памяти и освобождением старых при превышении определенной границы. НО!! Все это будет все равно тормозить на больших объемах. Ибо все в листвью через попу. Что бы определить видим или нет итем, листвью пробегается по всем итемам, и вычисляет их высоту и зная позицию скрола вычисляет видим или нет итем. чем больше полей, тем больше вычилений при каждом движении. Изменено 26 декабря, 2018 пользователем haword Цитата Ссылка на комментарий
krapotkin Опубликовано 26 декабря, 2018 Поделиться Опубликовано 26 декабря, 2018 Ну, другого способа вроде и нет, кроме как кэшить жту инфу. Но бесконечные списки должны сами удалять себе голову и добавлять хвост. Чтобы оставаться в пределах разумного размера Цитата Ссылка на комментарий
Morgerion Опубликовано 26 декабря, 2018 Автор Поделиться Опубликовано 26 декабря, 2018 12 часов назад, haword сказал: Что бы определить видим или нет итем, листвью пробегается по всем итемам, и вычисляет их высоту и зная позицию скрола вычисляет видим или нет итем. чем больше полей, тем больше вычилений при каждом движении Я думаю что на первых порах этим можно пренебречь, например проверить координаты даже 10 000 прямоугольников это не проблема. А вот 10 тысяч картинок точно хранить не стоит. Цитата Ссылка на комментарий
haword Опубликовано 27 декабря, 2018 Поделиться Опубликовано 27 декабря, 2018 (изменено) 15 часов назад, Morgerion сказал: Я думаю что на первых порах этим можно пренебречь, например проверить координаты даже 10 000 прямоугольников это не проблема. А вот 10 тысяч картинок точно хранить не стоит. лист на 3000 позиций в делфи и такой же в андроиде, по плавности скрола небо и земля. на среднестатистическом телефоне конечно не на топовом. проблема в том что при скролинге тебе надо проверить кэш, если нет то закачть новую картинку, почистить в кеше старые данные которые не показывались, и это делать при каждом движении ибо появляются новые и исчезают старые итемы. Изменено 27 декабря, 2018 пользователем haword Цитата Ссылка на комментарий
krapotkin Опубликовано 27 декабря, 2018 Поделиться Опубликовано 27 декабря, 2018 3000 ? 3000 * 50 кб по моим подсчетам на 150 мб потянет для мобилки не перебор? Цитата Ссылка на комментарий
Morgerion Опубликовано 27 декабря, 2018 Автор Поделиться Опубликовано 27 декабря, 2018 5 часов назад, krapotkin сказал: 3000 ? 3000 * 50 кб по моим подсчетам на 150 мб потянет для мобилки не перебор? 1. интересно откуда взялись именно 3000 ? 2. откуда взялись именно 50кб ? 3. 150 мб для мобилки - да вроде не перебор. недавно я принимал участие в разработке игры для мобилок (фермы), так там филлрейт 200..300 мб на каждый кадр! и ничо, работает даже на средних смартфонах. Цитата Ссылка на комментарий
haword Опубликовано 28 декабря, 2018 Поделиться Опубликовано 28 декабря, 2018 (изменено) В 27.12.2018 в 16:56, krapotkin сказал: 3000 ? 3000 * 50 кб по моим подсчетам на 150 мб потянет для мобилки не перебор? 3000 это то что было у меня. но причем тут 50 кб? 3000 это чисто текстовые позиции, картинки через кеш и подгрузку были. поэтому мне и нравится подход к этому делу андроидного грида, он каждый раз при появлении нового итема грида делает запрос на заполнение данными. как итем пропал с экрана то он удаляется из памяти. ну как я понял его работу. Изменено 28 декабря, 2018 пользователем haword Цитата Ссылка на комментарий
krapotkin Опубликовано 29 декабря, 2018 Поделиться Опубликовано 29 декабря, 2018 ну, так и работают все "бесконечные" списки новостей - при прокрутке удаляем уже прокрученное и в фоне зачитываем предстоящие позиции. а в андроиде чуваки даже семинар специальный делали, рассказывали как они пытались ускорить списки, и описывали подход с адаптерами в обычном VCL примерно так же работает Virtual Tree View - ничего не хранит, все что нужно запрашивает у программиста Цитата Ссылка на комментарий
Рекомендуемые сообщения
Присоединяйтесь к обсуждению
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.