Приветствую, коллеги! Кто сталкивался с кейсом отдельной обработки сворачивания приложения? События ЖЦ не подходят, так как в кейс попадают ненужные события перехода в др. активити
Попробуй обрабатывать евенты не в активити, а в Application классе
Простите, а что значит "отдельная обработка сворачивания приложения" ?)))
Изначально идея была такая, чтобы обрабатывать сворачивание в событии ЖЦ активности, однако такой вариант не подходит - обрабатываются и переходы в другие активности Т.е. события перехода и сворачивания абсолютно идентичны Отдельная - от переходов
Изначально идея была такая, чтобы обрабатывать сворачивание в событии ЖЦ активности, однако такой вариант не подходит - обрабатываются и переходы в другие активности Т.е. события перехода и сворачивания абсолютно идентичны Отдельная - от переходов
Вы что то не то делаете. Как вы отлавливаете событие перехода между двумя активностями?
Почему при отображении snackbar'a FAB не смещается вверх? Вроде в доке написано что всё что для это надо - чтобы fab была прямым наследником координатора.
Почему при отображении snackbar'a FAB не смещается вверх? Вроде в доке написано что всё что для это надо - чтобы fab была прямым наследником координатора.
Вы что то не то делаете. Как вы отлавливаете событие перехода между двумя активностями?
Ситуация вкратце: при переходе в другие активности я должен скрывать один юайный элемент, при сворачивании - не должен Переходов очень много и есть риск, что будут новые, поэтому не хочется прописывать логику скрытия в каждом переходе Как-то так Знакомлюсь со статьёй от @PaladinDev, возможно, она окажется полезной в решении проблемы
Ситуация вкратце: при переходе в другие активности я должен скрывать один юайный элемент, при сворачивании - не должен Переходов очень много и есть риск, что будут новые, поэтому не хочется прописывать логику скрытия в каждом переходе Как-то так Знакомлюсь со статьёй от @PaladinDev, возможно, она окажется полезной в решении проблемы
У вас что то с архитектурой . Можно попробовать как вариант intent put/get как вариант передачи данных между активностями. Или ещё лучше стейт через базу данных сохранять / восстанавливать.
У вас что то с архитектурой . Можно попробовать как вариант intent put/get как вариант передачи данных между активностями. Или ещё лучше стейт через базу данных сохранять / восстанавливать.
Может быть есть вариант отследить, что запустилась новая активность/открылась из бэкстэка?...
Ситуация вкратце: при переходе в другие активности я должен скрывать один юайный элемент, при сворачивании - не должен Переходов очень много и есть риск, что будут новые, поэтому не хочется прописывать логику скрытия в каждом переходе Как-то так Знакомлюсь со статьёй от @PaladinDev, возможно, она окажется полезной в решении проблемы
Не очень понял что нужно, но по идее за всем этим можно следить через лайфсайклы активити, чтоб следить за ними отлично подойдет registerActivityLifecycleCallbacks в апликейшене
Может быть есть вариант отследить, что запустилась новая активность/открылась из бэкстэка?...
Если у вас сложная какая то логика и сложный UI я бы делал через базу данных. Завязываться на инфраструктуру идея не очень хорошая. Скорее всего у вас ситуация, когда уже требуется Clean Architecture 😁
Ситуация вкратце: при переходе в другие активности я должен скрывать один юайный элемент, при сворачивании - не должен Переходов очень много и есть риск, что будут новые, поэтому не хочется прописывать логику скрытия в каждом переходе Как-то так Знакомлюсь со статьёй от @PaladinDev, возможно, она окажется полезной в решении проблемы
Ну можно конечно извращенным способом через слушатели - но решение в лоб очевидное очень простое - при входе в соотв.активность убираем элемент или показываем. Прямо из onCreate
Если неохота в 100500 активностях прописывать бойлерплейт - делаем вызов какого то общего метода а он разбирается нужен элемент или нет. Хоть на базе таблицы/карты со списком активностей и флагом Тогда все это будет в одном месте