Блин спасибо тебе большое, очень много пересмотрел видосов с этой навигацией засратой, как её правильно реализовать с single activity и вот наткнулся на твой ролик 21 года, ещё раз спасибо, очень сильно помог, так как пишу диплом) 🤝
Немного сумбурное объяснение работы с модулями получилось, но если потом разобрать проект самому, то все становится ясно. Спасибо за проделанную работу!
Navigation Components, как по мне, ограниченное решение для навигации, которое иногда бьет по рукам, если отклоняешься от идей библиотеки. Для многомодульного проекта её можно использовать, но не так, как вы описываете в видео, объясню почему: Рассмотрим пример приложения, в котором есть 3 экрана: - главный экран с товарами - детали товара и создатель - экран профиля пользователя с списком созданных им товаров Тогда судя по вашей логике, нужно будет сделать след. зависимости: - home -> detail - detail -> profile - profile -> detail 1. Ваши фиче-модули зависят от других фиче модулей и это проблема, если на этом примере все замечательно, то в реальных приложений с этим будут проблемы, т.к. начнется hell из зависимостей между модулями, а скорость сборки увеличится. 2. В видео опять же повторю рассматривается простой пример и если будет необходима циклическая зависимость между экранами, которые находятся в разных модулях, то с графом нужно будет костылять. Первой мыслью будет сделать в detail графе include profile'а, а в profile include detail'ов, в итоге словите эксепшн из-за того, что будет пытаться построится граф навигации прыгая из одного графа, в другой и обратно и так до тех пор, пока не будет переполнение стэка. (хотя возможно в последних версия что-то поменялось, но я сомневаюсь) 3. И последний пункт, ниже кто-то писал, что эта библиотека на самом деле крутая, с чем я тоже не соглашусь. Есть явные проблемы: - работа с диплинками, раз уж о них упоминалось, в больших проектах и особенно модульных с ними могут быть сложности в реализации, например, когда нужно открыть экран в конкретном табе на экране, тут либо костылять, либо страдать) - переопределение поведения Навхоста, например, чтобы фрагменты открывались не через .replace, а через .add - в правильно организованных модульных проектах придется жертвовать каким-то из преимуществ этой либы, например, библиотекой safe-args (т.к. модули не будут знать ничего друг о друге, то и нет смысла в генерации destination'ов) - создание multi-stack навигации, в видео было сказано, что если сделать для каждой отдельный граф, то "сложность резко понизится", с чем я не согласен, скорее всего в какой-то момент просто придете к мысли, что поддержка нескольких графов становится просто болью + ко всему добавляется boilerplate код, не говоря уже о качестве) Это будет связано с тем, что скорее всего понадобится на разных вкладках делать переходы на одни и те же экраны (надеюсь понятно о чем я) Как по мне, библиотека хорошо подходит, если в приложении простой флоу навигации и приложение не многомодульное (речь про реальные многомодульные проекты) Подводя итог, для многомодульного проекта нужно понимать, что при использовании navigation components придется в любом случае чем-то жертвовать. Советую ознакомится с серией статей на хабре - Navigation Component-дзюцу
Спасибо большое за такой развернутый комментарий. Всегда очень нравится, когда комментарии несут пользу :) Теперь по существу. По моей логике так не будет, потому что в видео тестовый проект, в реальных условиях я буду исходить из ситуации. Конкретно в этой ситуации, естественно, учитывая связность деталки и профиля, они у меня будут просто в одном модуле вероятно лежать. Навигацию мы использовали в приложении на 30 модулей (это, конечно, не 200 как у некоторых), но и не 1 и не 3. И все работало прекрасно никаких проблем мы не испытывали и тем более мы не делали никаких циркулярных зависимостей. Так что у нас все норм работало я могу рекомендовать эту навигацию в том числе и для многомодульных приложений. Сейчас перешли на собственное решение, но это связанно с тем что мы ушли в мультиплатформу К сожалению, есть нюанс в делании видео именно в плане создания видео. Я раньше (в истории канала можно посмотреть) использовать готовые сложные проекты, которые показывали реальную ситуацию (скажем кучу модулей или еще что-то), но это приводило как раз к тому, что люди путались и ничего не понимали. Поэтому я отказался от такого и примеры да специально простые. Переопределение методов навхоста это действительно будет очень сложно (если не невозможно), но надо понимать, что эта библиотека она в связке с другими решениями гугла работает, поэтому безусловно они дизайном либы подталкивают к правильному с их точки зрения использованию. Кому нравится окей, кому не нравится тоже окей. Насчет диплинков, кстати, тоже никаких проблем не было, мы как раз всю навигацию сделали в итоге диплинковой и тоже все отлично работало ) Может мы что-то делали не так)
@@MobileDeveloper Очень сомнительное решение вынести экраны профиля и товаров в один модуль, потому что звучит это как костыль, вместо решения проблемы и при этом тогда теряется смысл многомодульности. Посоветовал бы не привязываться к библиотеке только потому, что она от гугла. Также, реализация всей навигации в проекте с помощью диплинков опять звучит как уход от проблемы и решение "по-быстрому". К тому же, если было принято такое решение, значит реализация навигации с Navigation Components в многомодульных проектов все же имеет определенные проблемы + привязанность к библиотеке, о чем я написал выше. Хотя согласен, что это решение может работать 😀 "они дизайном либы подталкивают к правильному с их точки зрения использованию" - нужно понимать, что не проект подстраивается под библиотеку, а наоборот и если на маленьких проектах это работает хорошо, то на больших или сложных это уже может не работать. Кстати, когда я говорил про модульные проекты, это не обязательно 200+ модулей, тут главное какая архитектура и то как он разбивается на модули. Мое мнение, что лучше рассматривать сложные примеры и кейсы (если конечно они написаны хорошо), чем "тестовые", которые наоборот еще больше могут усложнить понимание реализации и последствий.
@@majorikKIK , а что лучше использовать для навигации? Я пока знакомлюсь с разработкой под андроид и пытаюсь найти инструменты, которые лучше всего подходят, чтобы не учить лишнего
Спасибо за обзор. Сейчас все поголовно используют эту навигацию, а мне она не зашла. Вот думал может я не разобрался, но после просмотра видео она всё также мне не нравится. Всё помпезно, красиво, но с тем же cicerone всё проще и удобнее.
Мне кажется это супер удобным. Интеграция с bottomnavview и раздельный бекстек для вкладок из коробки , диплинки , указание до какого фрагмента делать popbackstack, аргументы без всяких newInstance и прочего. Так или иначе чтобы такое сделать пришлось бы писать свои костыли а тут уже все в либе
Спасибо за контент. Недавно мне нужно было сделать анимацию главного меню, как у вьюпейджера(то есть при переключении от первого пункта к третьему - слайд-анимация через второй. Не придумал ничего лучше, чем использовать вьюпейджер, с тремя фрагментами, в который передавал соответствующий навграф. Получилось 4 навконтроллера, один главный (для сплеша, авторизационных экранов, экрана с главным меню и т.д.) и по одному на каждый пункт меню. Таким образом добился нужной анимации, но естественно сломалась навигация по кнопке "назад", пришлось обрабатывать самому. Если мы на фрагменте с меню, то вызывать popup() у навконтроллера текущего пункта меню, а если он не смог, то у главного навконтроллера. Кроме того некоторые переходы должны были быть на экраны без боттомнавбара, приходилось следить, чтобы использовался нужный навконтроллер. Это все конечно решалось довольно просто, буквально парой интерфейсов, но всё же нет ли способа проще?
Для такой кастомной штуки, врядли будет вариант попроще. Ну то есть я могу предложить вариант с анимацией внутри вью, но, имхо, это даже сложнее будет)
Спасибо за видео. Было бы интересно узнать про более сложную навигацию. Например как открыть по диплинку фрагмент внутри графа с bottom navigation если есть тот же логин.
Автору огромное спасибо! Тем не менее по итогу получается что если стоит боковое меню или нижнее меню, то управление бекстеком происходит коряво. То есть бекстек при переходе создается полностью, а очистка только при нажатии кнопок назад. Такая ситуация очень грусная… и если я при переходе хочу в начале очистить стек и только потом перейти, то такой опции видимо вообще не предусмотрено…
очень круто, спасибо, скажи а что если я хочу в каком то n-ом дереве фрагмента спрятать bottomNavigationView. Я могу это провернуть в данной реализации или нужно будет выносить bottomNavigationView в SingleActivity ?
Вдруг понадобиться фрагмент из которого не нужно уходить нажимая на bottomNavigationView. И для это нужно же его спрятать (isVisible=false). А менеджером по управлению фрагментов(корнем) вляется MainFragment
А по компоузу будет подобное видео? Не как его интегрировать в готовом проекте, а так же с нуля, чтобы минимум лишней информации для простоты восприятия
Привет, крутой контент, сразу после просмотра видео понял, как работать с Jetpack Navigation, и решил затащить в проект) Есть вопрос - multibackstack работает лишь если я повторно нажимаю на пункт меню, но не по нажатию onBackPressed? Например, я с пункта меню "Лента" перешел на фрагмент "Detail" и потом нажимаю на пункт меню "Настройки". И дальше, если я нажму на пункт меню Лента, то все ок - я увижу фрагмент "Detail", но если я вместо этого нажму назад, то попаду на пустой пункт меню "Лента"... как сделать так, чтобы "Detail" отображался в обоих случаях?
multibackstack с нижнем меню, работает как то криво, или чего не понимаю. Есть 5 пунктов меню, когда идёт переход между начальные фрагментами в меню, все нормально. Но если зайти в дальше по фрагменту, например в пункте меню C, потом перейти в A. А после нажать на пункт меню C. То фрагмент будет то же, что и должен быть, но пункт меню активные показывает A.
Выглядит красиво, но на практике оказалось увы, что не везде подходит. Особенно если многомодульный проект где доступ к модулям через интерфейс feature api и модулем может быть как один экран, так и отдельный flow.
Можно внутри модуля делать навигацию через jetpack все равно будет удобно. А переходить можно через реализацию интерфейса того же типа launch или navigate
@@MobileDeveloper согласен, но когда получаются фичи, как отдельные переиспользуемые экраны, тут уже не так гладко, а использовать кучу диплинков уже не так красиво, как хотелось бы.
Вот кстати, я сейчас сделал всю навигацию между модулями через дип линки. Пока полёт нормальный, плюс есть возможность из вебвью модулей обращаться к внутренним модулям
оставил коммент, но его нету почему-то )) , а еще нифига не понятно, если выпуск от 8 сентября, каким образом здесь комменты есть, которые неделю назад оставили)
Я видел коммент, но некоторые комменты сразу же удаляет ютуб. Причём именно удаляет, а не на модерацию отравляет. Возможно из-за ссылок Насчёт комментов это потому что видео вначале выходит для спонсоров и там оно может лежать довольно долго ) например сейчас есть два видео, которые доступны на бусти (не считая тех что является эксклюзивом)
@@MobileDeveloper Понятно тогда теперь всё. А то сначала подумал что комментарий и вовсе не отправился. Плохо что нет на ютубе такой опции, посмотреть, что за комменты оставлялись, да и вообще активность пользовательскую расширенную, а не только просмотренные ролики.. =)
Тогда еще такой вопрос небольшой., связанный с навигацией. Использовав ту библиотеку, о которой я писал в заболоченном комментарии была такая проблема, что при переходе по вкладкам в навигации (bottomNavigationView) был какой то неприятный фриз., когда происходит attach/detach фрагментов.. Единственным выходом из ситуации была костыльная проверка, с помощью которой проверялось, если в стеке сейчас лежит главный фрагмент только, то выполнялся "fragmentManager.beginTransaction().hide()" вместо ".detach()". Задержки при переключении между вкладками/стеками происходят из за того что фрагмент "тяжёлый" или как ?
Материал очень полезный, но для кого автор рассказывает, непонятно, видимо для себя любимого. Посыл рваный, несвязный, даже с пересмостром уловить трудно, ну, главное, чтобы ему самому было понятно.
жестяная жесть, конечно, кто в iOS это все делал - посмотрели и вышли нервно покурить, говорить что после такого разработчики какие-то там молодцы язык не поворачивается
От iOS есть много отличий. Во-первых там сториборды это сразу же и верстка, а здесь верстка в отдельном компоненте находится + куча интеграций с диплинками и прочими историями из коробки.
@@MobileDeveloper у меня после просмотра появился вопрос, если при переходе между фрагментами предыдущий фрагмент персоздается заново, как поддерживать нужный мне стек фрагментов (например процесс регистрации) в каком-то стабильном состоянии? При возврате на шаг назад хотелось бы видеть к примеру что форма заполнена данными
Это можно делать в связке с ViewModel, я потом отдельно про это видео сниму, но в рамках видео про Compose. Но в старой верстке точно также будет работать. К слову сам фрагмент не уничтожается, уничтожается только view, так что теоретически ты можешь просто эти данные в поле сложить в классе, а в onCreateView заполнить этими данными и должно работать)
![Что такое корутины? [RU] / Мобильный разработчик](http://i.ytimg.com/vi/yBxaE-qAPdI/mqdefault.jpg)
![[TH] 2024 PMSL SEA Finals D2 | Fall | ต้องรักษาฟอร์ม อย่ายอมให้ใครแซง](http://i.ytimg.com/vi/x38QsGn7A3M/mqdefault.jpg)
Блин спасибо тебе большое, очень много пересмотрел видосов с этой навигацией засратой, как её правильно реализовать с single activity и вот наткнулся на твой ролик 21 года, ещё раз спасибо, очень сильно помог, так как пишу диплом) 🤝
Немного сумбурное объяснение работы с модулями получилось, но если потом разобрать проект самому, то все становится ясно. Спасибо за проделанную работу!
Блин!! как я благодарен автору! Все сразу стало по местам, а то "эти" курсы...
Ждем выпуск про многомодульность
Это большая тема да )
@@MobileDeveloper прям очень актуально будет. Сделай плиз, ты все такие очень очень опытный разработчик
Когда-нибудь мы до этого дойдем
Алекскй ты большой молодец ! Очень помогло твоё видео . Продолжай помогать людям . Удачи тебе во всём !
Спасибо )
Спасибо за видео! Как всегда очень доступно, всё по делу и без "воды".
Спасибо )
Круто! Своевременное видео)) Как раз сейчас pet проект начинаю, хотел попробовать)
Огонь )
Капец демо как мега проект! ))
Сколько вы потратили времени на данное демо всего?
Спасибо!
Navigation Components, как по мне, ограниченное решение для навигации, которое иногда бьет по рукам, если отклоняешься от идей библиотеки.
Для многомодульного проекта её можно использовать, но не так, как вы описываете в видео, объясню почему:
Рассмотрим пример приложения, в котором есть 3 экрана:
- главный экран с товарами
- детали товара и создатель
- экран профиля пользователя с списком созданных им товаров
Тогда судя по вашей логике, нужно будет сделать след. зависимости:
- home -> detail
- detail -> profile
- profile -> detail
1. Ваши фиче-модули зависят от других фиче модулей и это проблема, если на этом примере все замечательно, то в реальных приложений с этим будут проблемы, т.к. начнется hell из зависимостей между модулями, а скорость сборки увеличится.
2. В видео опять же повторю рассматривается простой пример и если будет необходима циклическая зависимость между экранами, которые находятся в разных модулях, то с графом нужно будет костылять.
Первой мыслью будет сделать в detail графе include profile'а, а в profile include detail'ов, в итоге словите эксепшн из-за того, что будет пытаться построится граф навигации прыгая из одного графа, в другой и обратно и так до тех пор, пока не будет переполнение стэка. (хотя возможно в последних версия что-то поменялось, но я сомневаюсь)
3. И последний пункт, ниже кто-то писал, что эта библиотека на самом деле крутая, с чем я тоже не соглашусь. Есть явные проблемы:
- работа с диплинками, раз уж о них упоминалось, в больших проектах и особенно модульных с ними могут быть сложности в реализации, например, когда нужно открыть экран в конкретном табе на экране, тут либо костылять, либо страдать)
- переопределение поведения Навхоста, например, чтобы фрагменты открывались не через .replace, а через .add
- в правильно организованных модульных проектах придется жертвовать каким-то из преимуществ этой либы, например, библиотекой safe-args (т.к. модули не будут знать ничего друг о друге, то и нет смысла в генерации destination'ов)
- создание multi-stack навигации, в видео было сказано, что если сделать для каждой отдельный граф, то "сложность резко понизится", с чем я не согласен, скорее всего в какой-то момент просто придете к мысли, что поддержка нескольких графов становится просто болью + ко всему добавляется boilerplate код, не говоря уже о качестве) Это будет связано с тем, что скорее всего понадобится на разных вкладках делать переходы на одни и те же экраны (надеюсь понятно о чем я)
Как по мне, библиотека хорошо подходит, если в приложении простой флоу навигации и приложение не многомодульное (речь про реальные многомодульные проекты)
Подводя итог, для многомодульного проекта нужно понимать, что при использовании navigation components придется в любом случае чем-то жертвовать.
Советую ознакомится с серией статей на хабре - Navigation Component-дзюцу
Спасибо большое за такой развернутый комментарий. Всегда очень нравится, когда комментарии несут пользу :)
Теперь по существу.
По моей логике так не будет, потому что в видео тестовый проект, в реальных условиях я буду исходить из ситуации. Конкретно в этой ситуации, естественно, учитывая связность деталки и профиля, они у меня будут просто в одном модуле вероятно лежать.
Навигацию мы использовали в приложении на 30 модулей (это, конечно, не 200 как у некоторых), но и не 1 и не 3. И все работало прекрасно никаких проблем мы не испытывали и тем более мы не делали никаких циркулярных зависимостей. Так что у нас все норм работало я могу рекомендовать эту навигацию в том числе и для многомодульных приложений. Сейчас перешли на собственное решение, но это связанно с тем что мы ушли в мультиплатформу
К сожалению, есть нюанс в делании видео именно в плане создания видео. Я раньше (в истории канала можно посмотреть) использовать готовые сложные проекты, которые показывали реальную ситуацию (скажем кучу модулей или еще что-то), но это приводило как раз к тому, что люди путались и ничего не понимали. Поэтому я отказался от такого и примеры да специально простые.
Переопределение методов навхоста это действительно будет очень сложно (если не невозможно), но надо понимать, что эта библиотека она в связке с другими решениями гугла работает, поэтому безусловно они дизайном либы подталкивают к правильному с их точки зрения использованию. Кому нравится окей, кому не нравится тоже окей.
Насчет диплинков, кстати, тоже никаких проблем не было, мы как раз всю навигацию сделали в итоге диплинковой и тоже все отлично работало ) Может мы что-то делали не так)
@@MobileDeveloper Очень сомнительное решение вынести экраны профиля и товаров в один модуль, потому что звучит это как костыль, вместо решения проблемы и при этом тогда теряется смысл многомодульности.
Посоветовал бы не привязываться к библиотеке только потому, что она от гугла. Также, реализация всей навигации в проекте с помощью диплинков опять звучит как уход от проблемы и решение "по-быстрому". К тому же, если было принято такое решение, значит реализация навигации с Navigation Components в многомодульных проектов все же имеет определенные проблемы + привязанность к библиотеке, о чем я написал выше. Хотя согласен, что это решение может работать 😀
"они дизайном либы подталкивают к правильному с их точки зрения использованию" - нужно понимать, что не проект подстраивается под библиотеку, а наоборот и если на маленьких проектах это работает хорошо, то на больших или сложных это уже может не работать.
Кстати, когда я говорил про модульные проекты, это не обязательно 200+ модулей, тут главное какая архитектура и то как он разбивается на модули.
Мое мнение, что лучше рассматривать сложные примеры и кейсы (если конечно они написаны хорошо), чем "тестовые", которые наоборот еще больше могут усложнить понимание реализации и последствий.
@@majorikKIK , а что лучше использовать для навигации? Я пока знакомлюсь с разработкой под андроид и пытаюсь найти инструменты, которые лучше всего подходят, чтобы не учить лишнего
@@mironoff2007 как твоя учёба? выучил андроид? как успехи ?
@@dmitrychernenko-2574 уже работаю полтора года
Алексей спасибо за выпуски, планируется ли выпуск по workmanager, желательно в 2 части, вступление и в проекте)
Когда-нибудь да ) но не факт, что в ближайшее время
Тот момент, когда с первой минуты понимаешь, что контент очень годный!!! Спасибо за твой труд!
Пожалуйста ))
Спасибо за подробные инструкции. Теперь есть шаблон для старта. ✌
Пожалуйста )
Спасибо за обзор. Сейчас все поголовно используют эту навигацию, а мне она не зашла. Вот думал может я не разобрался, но после просмотра видео она всё также мне не нравится. Всё помпезно, красиво, но с тем же cicerone всё проще и удобнее.
Ну, такое может быть :) как говорится на вкус и цвет )
К сожалению jetpack navigation самое неудачное апи из jetpack. На compose они вообще сделали route навигацию по типу веба.
Не соглашусь. В видео разобраны все самые популярные кейсы и они очень легко делаются
Мне кажется это супер удобным. Интеграция с bottomnavview и раздельный бекстек для вкладок из коробки , диплинки , указание до какого фрагмента делать popbackstack, аргументы без всяких newInstance и прочего. Так или иначе чтобы такое сделать пришлось бы писать свои костыли а тут уже все в либе
Алексей спасибо за качественный контент.
Спасибо за контент.
Недавно мне нужно было сделать анимацию главного меню, как у вьюпейджера(то есть при переключении от первого пункта к третьему - слайд-анимация через второй. Не придумал ничего лучше, чем использовать вьюпейджер, с тремя фрагментами, в который передавал соответствующий навграф. Получилось 4 навконтроллера, один главный (для сплеша, авторизационных экранов, экрана с главным меню и т.д.) и по одному на каждый пункт меню. Таким образом добился нужной анимации, но естественно сломалась навигация по кнопке "назад", пришлось обрабатывать самому. Если мы на фрагменте с меню, то вызывать popup() у навконтроллера текущего пункта меню, а если он не смог, то у главного навконтроллера. Кроме того некоторые переходы должны были быть на экраны без боттомнавбара, приходилось следить, чтобы использовался нужный навконтроллер. Это все конечно решалось довольно просто, буквально парой интерфейсов, но всё же нет ли способа проще?
Для такой кастомной штуки, врядли будет вариант попроще. Ну то есть я могу предложить вариант с анимацией внутри вью, но, имхо, это даже сложнее будет)
Огромное спасибо) как раз то, что нужно
Огромное спасибо, видео Огонь!!!!
Thanks, very useful explanation.
Спасибо за видео. Было бы интересно узнать про более сложную навигацию. Например как открыть по диплинку фрагмент внутри графа с bottom navigation если есть тот же логин.
Интересный кейс, но он уже больше к диплинкам относится, нежели к навигации
@@MobileDeveloper есть ли у вас хорошие ссылки на habr, medium про диплинкам.
Автору огромное спасибо!
Тем не менее по итогу получается что если стоит боковое меню или нижнее меню, то управление бекстеком происходит коряво. То есть бекстек при переходе создается полностью, а очистка только при нажатии кнопок назад. Такая ситуация очень грусная… и если я при переходе хочу в начале очистить стек и только потом перейти, то такой опции видимо вообще не предусмотрено…
Годнота :)
Спасибо за видос
очень круто, спасибо, скажи а что если я хочу в каком то n-ом дереве фрагмента спрятать bottomNavigationView. Я могу это провернуть в данной реализации или нужно будет выносить bottomNavigationView в SingleActivity ?
Да нет можно на какой угодно вложенности это делать по сути. У нас так и работает )
@@MobileDeveloper а как мне например с FeedFragment получить доступ к bottomNavigationView в MainFragment?
А зачем?
Вдруг понадобиться фрагмент из которого не нужно уходить нажимая на bottomNavigationView. И для это нужно же его спрятать (isVisible=false). А менеджером по управлению фрагментов(корнем) вляется MainFragment
А по компоузу будет подобное видео? Не как его интегрировать в готовом проекте, а так же с нуля, чтобы минимум лишней информации для простоты восприятия
th-cam.com/video/cX7RVGj19iU/w-d-xo.html
А это видео чем не подходит?)
Дякую за якісний контент. Дуже багато корисної інформації отримав з твоїх відео. Чекаю з нетерпінням нових відео. Бажано для новачків))
Не очень понял, что написано, но спасибо )
Спасибо, крутое видео, то есть теперь мы можем использовать navigation вместо intent?
Пожалуйста :)
Привет, крутой контент, сразу после просмотра видео понял, как работать с Jetpack Navigation, и решил затащить в проект)
Есть вопрос - multibackstack работает лишь если я повторно нажимаю на пункт меню, но не по нажатию onBackPressed? Например, я с пункта меню "Лента" перешел на фрагмент "Detail" и потом нажимаю на пункт меню "Настройки". И дальше, если я нажму на пункт меню Лента, то все ок - я увижу фрагмент "Detail", но если я вместо этого нажму назад, то попаду на пустой пункт меню "Лента"... как сделать так, чтобы "Detail" отображался в обоих случаях?
По идее навигация из коробки умеет работать с backpressed. Тут надо логгировать, смотреть код, так я не понимаю в чем у вас проблема
multibackstack с нижнем меню, работает как то криво, или чего не понимаю. Есть 5 пунктов меню, когда идёт переход между начальные фрагментами в меню, все нормально. Но если зайти в дальше по фрагменту, например в пункте меню C, потом перейти в A. А после нажать на пункт меню C. То фрагмент будет то же, что и должен быть, но пункт меню активные показывает A.
Выглядит красиво, но на практике оказалось увы, что не везде подходит. Особенно если многомодульный проект где доступ к модулям через интерфейс feature api и модулем может быть как один экран, так и отдельный flow.
Можно внутри модуля делать навигацию через jetpack все равно будет удобно. А переходить можно через реализацию интерфейса того же типа launch или navigate
@@MobileDeveloper согласен, но когда получаются фичи, как отдельные переиспользуемые экраны, тут уже не так гладко, а использовать кучу диплинков уже не так красиво, как хотелось бы.
Вот кстати, я сейчас сделал всю навигацию между модулями через дип линки. Пока полёт нормальный, плюс есть возможность из вебвью модулей обращаться к внутренним модулям
Что скажите про навигацию через ViewModel? Мне вообще интересно, какую именно навигацию используют в проектах....
А что значит навигация через ViewModel?
Спасибо за очень качественный контент.
Не указанно возможность safeArg
27:55 Что делать с устаревшим popUpTo? Предлагает popUpToId, но ошибки разные выдаёт
оставил коммент, но его нету почему-то )) , а еще нифига не понятно, если выпуск от 8 сентября, каким образом здесь комменты есть, которые неделю назад оставили)
Я видел коммент, но некоторые комменты сразу же удаляет ютуб. Причём именно удаляет, а не на модерацию отравляет. Возможно из-за ссылок
Насчёт комментов это потому что видео вначале выходит для спонсоров и там оно может лежать довольно долго ) например сейчас есть два видео, которые доступны на бусти (не считая тех что является эксклюзивом)
@@MobileDeveloper Понятно тогда теперь всё. А то сначала подумал что комментарий и вовсе не отправился. Плохо что нет на ютубе такой опции, посмотреть, что за комменты оставлялись, да и вообще активность пользовательскую расширенную, а не только просмотренные ролики.. =)
Тогда еще такой вопрос небольшой., связанный с навигацией. Использовав ту библиотеку, о которой я писал в заболоченном комментарии была такая проблема, что при переходе по вкладкам в навигации (bottomNavigationView) был какой то неприятный фриз., когда происходит attach/detach фрагментов.. Единственным выходом из ситуации была костыльная проверка, с помощью которой проверялось, если в стеке сейчас лежит главный фрагмент только, то выполнялся "fragmentManager.beginTransaction().hide()" вместо ".detach()". Задержки при переключении между вкладками/стеками происходят из за того что фрагмент "тяжёлый" или как ?
Ну просто на это ж время нужно, там ещё поди весь код инициализировался в onCreateView
Есть ли разница в jetpack compose и compose for desktop
По большому счету нет разницы
Спасибо!
А как открыть деталку без нижней навигации?
В примере на гитхабе есть как раз такая реализация)
Материал очень полезный, но для кого автор рассказывает, непонятно, видимо для себя любимого. Посыл рваный, несвязный, даже с пересмостром уловить трудно, ну, главное, чтобы ему самому было понятно.
Что там про продолжение серии видео про сборщики мусора?
Монтируется) я стараюсь снять видео сейчас, чтоб побольше успеть смонтировать за сентябрь ) потом сяду монтировать это видео )
как сделать build gradle в kts файле?
Будет отдельное видео
жестяная жесть, конечно, кто в iOS это все делал - посмотрели и вышли нервно покурить, говорить что после такого разработчики какие-то там молодцы язык не поворачивается
От iOS есть много отличий. Во-первых там сториборды это сразу же и верстка, а здесь верстка в отдельном компоненте находится + куча интеграций с диплинками и прочими историями из коробки.
@@MobileDeveloper у меня после просмотра появился вопрос, если при переходе между фрагментами предыдущий фрагмент персоздается заново, как поддерживать нужный мне стек фрагментов (например процесс регистрации) в каком-то стабильном состоянии? При возврате на шаг назад хотелось бы видеть к примеру что форма заполнена данными
Это можно делать в связке с ViewModel, я потом отдельно про это видео сниму, но в рамках видео про Compose. Но в старой верстке точно также будет работать. К слову сам фрагмент не уничтожается, уничтожается только view, так что теоретически ты можешь просто эти данные в поле сложить в классе, а в onCreateView заполнить этими данными и должно работать)
Спасибо!
Пожалуйста :)
Спасибо!
Спасибо!