Если просто- activity, которые есть в backstack, android может выгружать из памяти при ее нехватке, оставляя в памяти только ту, на которою Вы смотрите
Не может. Я об этом специально написал дальше в статье.
Только процесс может быть выгружен из памяти при нехватке ресурсов.
Пока это просто неподкрепленное фактами утверждение. Пример: приложение Uber с 1700+ градл модулями в проде написано целиком в одном Activity. Как вы считаете это тоже "типичное «конвейерное приложение»"?
Приведите пример, который на нескольких Activity решается бесспорно лучше, и мы детально обсудим)
вызывает не меньше сложностей в сравнении с multiple activity.
сложность это вопрос образованности и опыта, а я попытался доказать, что в "классическом" подходе есть фатальные проблемы, которые не решить сколь угодно сложным кодом
Потому что статья не об этом, но там специально выделено: Всем изучать WindowInsets!
Когда появляется клавиатура, то система сообщает ее размер через применение WindowInsets к Activity, именно так и можно узнать ее высоту.
Ничего сверх нового в подходе нет, но есть особенности принятые конкретно у нас.
Я планирую когда-нибудь описать, как мы у себя готовим такие приложения.
Точно, спасибо за наводку! Не заметил, что можно в провайдер добавлять свои реализации.
Там какраз в навигатор приходит экшн со всеми параметрами.
Так что может и получится прикрутить кондуктор навигацию.
Я правда ее не использую)
Как показывает практика: апи библиотек гугла обычно негибкие и мало поддаются кастомизации.
Прямого пути для решения подобной задачи я не вижу, но мы же сами вызываем из кода переход с конретным ID, поэтому теоретически можно вместо вызова перехода на NavController'е, вызывать его на собственной навигации, предварительно узнав параметры перехода, заданные в xml графе.
Но все это ради UI графа с не очень богатым фукционалом?
Может быть тогда проще написать свой плагин для Андроид Студии, который будет отображать xml с настройкой переходов в виде UI-графа, а потом позволять использовать эти параметры как угодно? А это идея!
А написание приложение было просто для себя? Или есть реальное приложение? Было бы интересно посмотреть (не встречал ещё заказов на разработку под часы)
По вашим словам — это вы так себе тестировщик, и работаете по бумажке, а не для конечного пользователя. И в вашем подходе, вы всегда будете скидывать вину на начальника, без личной ответственности за проект.
По вашим словам поди и JavaScript (и любой не статически типизированный язык) лучше Java (любой статик), тем что в динамичном приложении нам не надо париться о конкретных типах, и мы можем на лету трактовать типы как удобнее. Ну-ну.
А про устойчивость и надежность вы думали? Статические анализаторы не просто так придумали.
Потоки событий подойдут в распределенных системах, потому что там иначе никак. Но не в мобильных приложениях, где надежность, скорость и простота отладки гораздо важнее чем написание абстрактных коней в вакууме, которые шлют события абы куда и принимаю абы откуда
Вы очень много пишите и уходите от темы в аналогии. Евентбас — зло для андроид приложений, так как он совершенно неконтролируем. Если проект маленький и его пилит один человек, который умудряется все держать в голове, то еще прокатит. Для серьезной разработки — это недопустимо.
Я думаю стоит завершить этот спор. Есди я вас не переубедил — это ваше дело. Но воздержитесь рекомендовать Евентбас кому-то еще.
Минус данного подхода, что вы отправляете сообщение в "комос", а кто его получит — неизвестно. Это влечет за собой проблемы отладки и связывает слушателей и источники событий. А кто эти источники и кто у них слушатели можно определить только глобальным поиском по проекту.
Это все равно что во всех интерфейсах передавать объекты типа Object и по мере их использования кастовать к нужным типам. А после этого заменить все интерфейсы на один:
interface Listener { fun doAction(obj: Object) }
Я отлично представляю, где может понадобится рассылка сообщений компонентами. Но это не для общения между диалогом и активити. А именно в данном контексте я и не рекомендую слушать ваш совет.
Из-за использования инструментов в неправильных местах потом и получаются монстры, которых невозможно поддерживать и отлаживать.
Если я встречу подобный подход в чьих-то исходниках, то сразу поставлю диагноз: "архитектура головного мозга". Без обид.
С точки зрения оторванной от реальности теории — может и не очень хорошо, что диалог ищет своего слушателя, но если вспомнить, что после восстановления система (андроид) сама создает компоненты, то это вполне нормально. Надо просто помнить, что активити/фрагменты/диалоги — независимые сущности, которые должны сами о себе позаботиться.
Это худшее, что можно было посоветовать! Евентбас неявно связывает все компоненты между собой. Все компоненты в приложении могут слушать всех. А дебажить это дело…
Закопайте его и не вспоминайте
Создание адаптера через билдер — очень ограниченный вариант, потому что часто требуется реализовать пагинацию, а тут ни куда без наследования. А так, конечно, Дорфмановские делегаты очень помогают!
Не может. Я об этом специально написал дальше в статье.
Только процесс может быть выгружен из памяти при нехватке ресурсов.
Наверное, вы правы, очень давно не делал так, потому и ошибся)
Пока это просто неподкрепленное фактами утверждение. Пример: приложение Uber с 1700+ градл модулями в проде написано целиком в одном Activity. Как вы считаете это тоже "типичное «конвейерное приложение»"?
Приведите пример, который на нескольких Activity решается бесспорно лучше, и мы детально обсудим)
сложность это вопрос образованности и опыта, а я попытался доказать, что в "классическом" подходе есть фатальные проблемы, которые не решить сколь угодно сложным кодом
Потому что статья не об этом, но там специально выделено: Всем изучать WindowInsets!
Когда появляется клавиатура, то система сообщает ее размер через применение WindowInsets к Activity, именно так и можно узнать ее высоту.
Ничего сверх нового в подходе нет, но есть особенности принятые конкретно у нас.
Я планирую когда-нибудь описать, как мы у себя готовим такие приложения.
Точно, спасибо за наводку! Не заметил, что можно в провайдер добавлять свои реализации.
Там какраз в навигатор приходит экшн со всеми параметрами.
Так что может и получится прикрутить кондуктор навигацию.
Я правда ее не использую)
Как показывает практика: апи библиотек гугла обычно негибкие и мало поддаются кастомизации.
Прямого пути для решения подобной задачи я не вижу, но мы же сами вызываем из кода переход с конретным ID, поэтому теоретически можно вместо вызова перехода на NavController'е, вызывать его на собственной навигации, предварительно узнав параметры перехода, заданные в xml графе.
Но все это ради UI графа с не очень богатым фукционалом?
Может быть тогда проще написать свой плагин для Андроид Студии, который будет отображать xml с настройкой переходов в виде UI-графа, а потом позволять использовать эти параметры как угодно? А это идея!
Я тоже считаю, что это не DI фреймворк. Зависимости явно достаются из сервис локатора.
Да и Jake Wharton иного мнения: https://www.reddit.com/r/androiddev/comments/75g2fm/opinions_on_kodein/do61qrq/
По вашим словам поди и JavaScript (и любой не статически типизированный язык) лучше Java (любой статик), тем что в динамичном приложении нам не надо париться о конкретных типах, и мы можем на лету трактовать типы как удобнее. Ну-ну.
А про устойчивость и надежность вы думали? Статические анализаторы не просто так придумали.
Потоки событий подойдут в распределенных системах, потому что там иначе никак. Но не в мобильных приложениях, где надежность, скорость и простота отладки гораздо важнее чем написание абстрактных коней в вакууме, которые шлют события абы куда и принимаю абы откуда
Вы очень много пишите и уходите от темы в аналогии. Евентбас — зло для андроид приложений, так как он совершенно неконтролируем. Если проект маленький и его пилит один человек, который умудряется все держать в голове, то еще прокатит. Для серьезной разработки — это недопустимо.
Я думаю стоит завершить этот спор. Есди я вас не переубедил — это ваше дело. Но воздержитесь рекомендовать Евентбас кому-то еще.
Минус данного подхода, что вы отправляете сообщение в "комос", а кто его получит — неизвестно. Это влечет за собой проблемы отладки и связывает слушателей и источники событий. А кто эти источники и кто у них слушатели можно определить только глобальным поиском по проекту.
Это все равно что во всех интерфейсах передавать объекты типа Object и по мере их использования кастовать к нужным типам. А после этого заменить все интерфейсы на один:
interface Listener { fun doAction(obj: Object) }
Я отлично представляю, где может понадобится рассылка сообщений компонентами. Но это не для общения между диалогом и активити. А именно в данном контексте я и не рекомендую слушать ваш совет.
Из-за использования инструментов в неправильных местах потом и получаются монстры, которых невозможно поддерживать и отлаживать.
Если я встречу подобный подход в чьих-то исходниках, то сразу поставлю диагноз: "архитектура головного мозга". Без обид.
С точки зрения оторванной от реальности теории — может и не очень хорошо, что диалог ищет своего слушателя, но если вспомнить, что после восстановления система (андроид) сама создает компоненты, то это вполне нормально. Надо просто помнить, что активити/фрагменты/диалоги — независимые сущности, которые должны сами о себе позаботиться.
Это худшее, что можно было посоветовать! Евентбас неявно связывает все компоненты между собой. Все компоненты в приложении могут слушать всех. А дебажить это дело…
Закопайте его и не вспоминайте
Я не о том. Пройти квест — само по себе здорово, и я благодарен его организаторам, но и выбор лидеров — не менее интересный момент.
Мда… это конечно фейл. То есть тем, кто постоянно не мониторит новости на хабре (особенно в рабочее время), можно было даже и не пытаться.
ну ок