Annual Open Tech Conference - ISsoft Insights 2021. June 19. Learn more.
×Закрыть

Android — фрагменты

Здравствуйте.
На активити есть поле для ввода и фрагмент.
Считается что плохо, когда активити заполняет поля на фрагменте.
А если наоборот — фрагмент заполнит поле(TextView) на активити?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Обновлять поля во вьюхах должны не другие вьюхи, а их собственные вьюмоделы, или презентеры.
Откуда они должны узнавать о необходимости обновить данные?
По событию в бизнес-модели, на которое они должны быть подписаны.
Что должно послужить причиной этого события?
В твоём случае — обращение от вьюмоделов/презентеров другого активити/фрагмента.
Инициированное нажатием кнопки на них, например.

Получается, что собираю данные с фрагмента и активити и записываю в БД.
Это делается во фрагменте.

Могу поле ввода из активити перенести во фрагмент,
собрать данные через фрагмент и записать в БД.
Какой вариант лучше?
Как сделать это правильно/надёжно?

записывать данные в БД НЕ во фрагменте и НЕ в активити будет правильней всего.

Почитайте про clean architecture. Про MVP, MVVM.

Если человек только начинает, ему эти ваши архитектуры только навредят.

ага, пущай говнокодит....потом переучится...

Все мы писали код, за который потом было стыдно, это нормальный процесс. Но! Можно подумать, что если перейти на клин, то магическим образом говнокод исчезнет.
Пока Java SE и Android SDK не освоил, рыпаться к клину нет смысла, имхо. Потому что там сразу надо грамотно di настроить, асинхронщину организовать, по слоям обязанности разложить и т.д. И говнокод просто перейдет на новый уровень. Без понимания «зачем вот это все и какую боль оно решает», клин вреден.

Единственное что, наверное, на MVP стоит стразу смотреть, здесь порог вхождения минимален. Только опять таки, лучше без чудо-фреймворков, а как-то так: github.com/...​ndroidboilerplate/ui/base

Потому что там сразу надо грамотно di настроить, асинхронщину организовать, по слоям обязанности разложить и т.д.

Не поверишь, ни в одном проекте не юзаю эту ересь, di.
Оно нафиг не нужно. Просто позволяет писать плохой код, которым всё ещё можно пользоваться и не более.
В остальном — без асинхронщины он ничего не напишет априори. Работа с базами уже оную подразумевает.
Распределение обязанностей по слоям — это первое, чему должен научиться программист. Задавать себе вопрос, место ли этому коду в этом классе. Всегда.

эту ересь, di.
Оно нафиг не нужно

га га га. Сколько классов в проектах? До 20 нужно без ди, до 50 можно без ди, до 100 еще сжимая жопу можно без ди, если все пиздец простое. После 100 — без ди это полный лол.

Более 100 классов, не считая зависимостей?
Видел такие проекты, даже работал на них.
Никому этого не пожелаю. Билдится по 20 минут. Делают его 15 разработчиков. Поменять 2 активити местами в стеке занимает 2 дня. Мерджить пулл-реквест можно 3 недели, это в порядке вещей.
Это единственный проект, на котором я видел даггер.
Добровольно на такие проекты лучше не идти.

Это сейчас ирония или серьезно? 100 классов это все еще очень маленький проект, неужели кто-то на таких всю карьеру сидит?

Никогда не считал эти классы.
Сейчас решил ради прикола посчитать классы в прошлогоднем среднем по размерам проекте.
Не считая сгенерированных, чисто котлиновских классов 124 штуки.
Никакого di в этом проекте нет, и не нужно. Делал его сам с нуля.
После того, как ушел, оставил его на джуна. Клиент всем доволен.
И да, я хочу на такого масштаба проектах всю карьеру сидеть))

Лол.
Я вообще в эту тему из блади интерпрайзы заглянул, а андроид я только в телефоне вижу.

Так вот, этот пост вызывает у меня тока улыбку. 100 классов в проекте это очень маленький проект. Нано-проектик такой.

Билдится по 20 минут.

А почему у меня проект на 1,5к классов билдится 1 минуту?

Поменять 2 активити местами в стеке занимает 2 дня.

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

Делают его 15 разработчиков.

Бред. Такое количество девов нужно на проект в десятки тысяч классов. Или у вас 15 интернов пальцем в носу ковыряются и работают по полчаса а весь день пьют смузи.

Мерджить пулл-реквест можно 3 недели

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

Это единственный проект, на котором я видел даггер.

Отсюда и такие суждения.

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

Правильно, что с этого начал))

А почему у меня проект на 1,5к классов билдится 1 минуту?

Я ж не знаю, сколько там у тебя кодогенерации, какие внешние зависимости.
И не на билдсервере ли ты его билдишь.
20 минут у меня занимал полный клин-билд на офисном тоненьком ноуте.

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

Нет, из упомянутых 15 человек пятеро имело полномочия архитекторов разных частей этого проекта. И к любому пулл-реквесту они начинали докапываться в стиле «я вижу это иначе, переделай по-другому, будет красивее». Причем часто видение было у каждого своё. Они обожали запихнуть в любую задачу рефакторинг того модуля, в котором она делалась под предлогом «мы уже решили этот модуль рефакторить, смысл писать в нём новый код по-старому?».
Потом они на лету начинают корректировать этот рефакторинг в рамках основной задачи, причем все вместе.

Отсюда и такие суждения

В остальных проектах и без него всё прекрасно работало. И 100+ классов тоже.

Какой-то сферический конь в вакууме. Что надо то в конечном итоге?

Подписаться на комментарии