Size: a a a

Android Developers

2020 December 04

S

Silent829 in Android Developers
К Б
привет, вот такая задачка. есть класс, отвечающий за поставку данных из хранилища, и обычный адаптер для списка. нужно в списке показывать данные, отобранные по определенным критериям. и вот тут возникает непонятка. с одной стороны варианты отбора могут быть разными, и вешать это на поставщика данных не кажется разумным. с другой стороны, иначе адаптеру придется знать и уметь работать со специфическими методами составления запросов, зависящими и от модели данных и от  типа хранилища (например room, realm, retrofit и т.д.). делать у поставщика данных отдельный билдер запросов, это городить монстра, поддерживающего сложный огород вложенных условий, для пары-тройки адаптеров тоже не хочется. может есть какие-то готовые шаблоны, или советы?:)

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

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

S

Silent829 in Android Developers
К Б
смущает, что интерактор обычно используют в схеме репо->интерактор->презентер
что именно?
источник

КБ

К Б in Android Developers
а тут вроде как ??? ->репо->презентер
источник

СК

Сергей Коротчик... in Android Developers
К Б
а тут вроде как ??? ->репо->презентер
Но тебе же надо преобразовать данные?
источник

S

Silent829 in Android Developers
view -> viewmodel / presenter -> usecase -> repository -> local / remote datasource interface -> impl (room / realm / *sqlite* / retrofit / ...)
источник

КБ

К Б in Android Developers
вот не совсем, надо указать какие данные они ведь могут быть композитными
источник

S

Silent829 in Android Developers
К Б
привет, вот такая задачка. есть класс, отвечающий за поставку данных из хранилища, и обычный адаптер для списка. нужно в списке показывать данные, отобранные по определенным критериям. и вот тут возникает непонятка. с одной стороны варианты отбора могут быть разными, и вешать это на поставщика данных не кажется разумным. с другой стороны, иначе адаптеру придется знать и уметь работать со специфическими методами составления запросов, зависящими и от модели данных и от  типа хранилища (например room, realm, retrofit и т.д.). делать у поставщика данных отдельный билдер запросов, это городить монстра, поддерживающего сложный огород вложенных условий, для пары-тройки адаптеров тоже не хочется. может есть какие-то готовые шаблоны, или советы?:)

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

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

КБ

К Б in Android Developers
ок
источник

КБ

К Б in Android Developers
звучит хорошо:)
источник

S

Silent829 in Android Developers
К Б
вот не совсем, надо указать какие данные они ведь могут быть композитными
ну ты через вью собираешь фильтры (галочки там, результаты поиска, еще что-нибудь), передаешь во вьюмодель а она говорит юзкейсу, репа просто принимает параметры и отдает данные
источник

КБ

К Б in Android Developers
да, типа того
источник

DE

Denis Egorov in Android Developers
К Б
привет, вот такая задачка. есть класс, отвечающий за поставку данных из хранилища, и обычный адаптер для списка. нужно в списке показывать данные, отобранные по определенным критериям. и вот тут возникает непонятка. с одной стороны варианты отбора могут быть разными, и вешать это на поставщика данных не кажется разумным. с другой стороны, иначе адаптеру придется знать и уметь работать со специфическими методами составления запросов, зависящими и от модели данных и от  типа хранилища (например room, realm, retrofit и т.д.). делать у поставщика данных отдельный билдер запросов, это городить монстра, поддерживающего сложный огород вложенных условий, для пары-тройки адаптеров тоже не хочется. может есть какие-то готовые шаблоны, или советы?:)

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

проблема только, что пока хрен знает, сколько таких вариантов может быть, и любое незначительное отклонение потребует нового метода. та и имена замучаешься методам давать:)
Это задача в том числе и поставщика данных. Если у тебя бд, то будешь использовать механизмы бд для фильтрации и т.д
источник

DE

Denis Egorov in Android Developers
Весь маппинг может уйти в базу данных таким образом
источник

ℕo ℕame in Android Developers
Ернур
ребята, можно ли в приложении запретить на андроиде смену на темный фон? Точнее когда меняешь фон на темный на телефоне, что бы твое приложение не менялось на темный фон?
Эммм, это как и в каких устройствах так?
источник

DE

Denis Egorov in Android Developers
и все в итоге решается в пару функций
источник

КБ

К Б in Android Developers
Denis Egorov
и все в итоге решается в пару функций
например?
источник

DE

Denis Egorov in Android Developers
Не надо из мощных инструментов делать Storage.getData()
источник

DE

Denis Egorov in Android Developers
К Б
например?
Ну вместо создания хелперов и интеракоров ты просто получишь функции с параметрами
источник

DE

Denis Egorov in Android Developers
И вся сложная работа будет в бд (она это умеет)
источник

DE

Denis Egorov in Android Developers
зачем выносить фильтрации, выборки и т.д в интеракторы. Они этого не умеют
источник