Так а у Вас какая проблема?

Проблема в навигации с BottomNavigationView. Я хочу сдлеать менюшку из 5 кнопок и чтобы они все были дефолтные. Но уже разобался как сделать

Если мне нужно иметь возможность открыть любой фрагмент из любого места — это не жесткое следование флоу (или не жесткое флоу). Следовательно, применение Navigation здесь не имеет смысла, так как он определяет конкретное флоу с конкретными направлениями перехода и если его использовать — это ошибка при выборе инструмента.

Тоесть ты Nav паралельно с FragmentTransaction юзаешь?

А зачем?) если не секрет. Nav для этого и придумали

Можно так, но это уже изобретение извращённого ведосипеда. Если у меня нет жесткого флоу по каждому пункту нижней навигации (когда открываем профиль — и мы можем уйти на флоу новостей, к примеру) — тут или соответствующие роутеры, или вообще написание своего.

Сергей, у вас очень странная Архитектура навигации в проекте была, вот что я понял из нашей беседы

Нет. Я попробую ещё проще объяснить. Пусть мы имеем три вкладки — новости, сообщения, профиль. Кейс 1: из сообщений мы можем перейти в новости в рамках той же вкладки — НЕ NavComponent Кейс 2: из сообщений переходим в новости включая смену флоу (к примеру, передавая аргументы в сторону флоу новостей — нужное действие (к примеру, открытие деталки новости) и идентификатор новости) — автоматом меняем вкладку, переходим на другое флоу (и другой граф), плюсы — сохраняем состояние флоу сообщений. Допустимо использование Navigation Кейс 3: из сообщений нельзя перейти к профилю или новостям — нет смысла юзать что-то кроме Navigation

Значит вы не работали в коммерческих компаниях еще не разу. Нельзя такого слова нет))

Но по кейсу 2 всплывает один интересный момент с навигацией назад (переходить в сообщения или к руту новостей)

4 года стажа, поддержка приложений Юнистрим и Сбербанка, совместные проекты со Сбером, это все на позициях миддла и с принятием архитектурных решений в рамках всего проекта. И то, что я описываю, я вывел для себя сам — путём набивания шишек, когда пытался применить инструмент, который НЕЛЬЗЯ использовать для решения задачи, так как он просто не подходит для подобных задач. Его можно использовать в буквальном смысле — нельзя в этическом. Я не хочу потом +10 часов тратить на написание кучи костылей, я лучше возьму тот инструмент, который сразу способен с минимальными затратами по времени помочь решить задачу.

Сбер дает право решать мидлу, какую архитектуру использовать? ну хватит уже а. Сеньорам то такое не дают сделать, а тут мидл. Да и еще и в сбере, где в команде насчитывается 9 Android разработчиков. Откуда знаю? работал там

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

А работал в самом Сбере, а ты судя по комменту лишь сотрудничали с ними. Тогда какой смысл писать о таких вещях? Это выглядит глупо

В самом сбере внутри команды — и там, не спорю, серьёзные архитектурные решения внутри команды не принимаются. Я про это и не говорю

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

Тогда заказчик будет платить за большее количество часов, пока разработчик изобретает велосипеды

можете пояснить что значит "нельзя нет такого слова"?

В коммерческих нету заказчика, есть продуктологи. Заказчики в Аутстафах. Там решают деньги, и им все равно что вам больно писать и поддерживать код. Мало кто дает время на рефакторинг, а если и дает это время, то только если вся команда на это согласна. А такое возможно не всегда, лишь там где есть 11 друзей оушена или хотя бы 3 мушкетера

Ты забыл упомянуть, что ещё нужно как-то бюджет выдавить из заказчика на рефакторинг без формулировки «мы там наговнокодили чутка»

При том из-за ебнутых сроков. А ещё круче — когда сначала это MVP с дальнейшим рефакторингом по тз, а потом ты поддерживаешь эту стряпню три года, ибо «Работает же»

Ну про это я выше и писал пор 11 друзей оушена. Если ты один поднимешь тему, то врядле кто согласится, потому что это время. А кому хочется возиться в коде просто так. А сплоченность в командах это отдельная тема. Совместно договориться и если что, быть готовым уволиться, такое не каждый захочет делать. Кушать то надо)

Мы проще делали. Я поднял вопрос рефакторинга, ко мне присоединился второй Android dev, следом подтянулся iOSс фразой «мне тоже надо, я тоже хочу!» и я перестал брать задачи, а если брал — оценка приводила всех в ужас

Уволили?)