Спасибо чувак.

Нашел. Удобно то как.

А то до этого добавляли сами в Developer Drawer свою кнопку чтобы Апп сам уведомлял сервера.

А тут круто все.

Может из-за остальных костылей не хочет работать...

Ок, хорошо, тогда попробуем избавиться от старых костылей. Есть абстрактная активити с боковым меню и аппбаром. От неё экстендишься, в сетконтенте заполняешь фрагмент с основным контентом и такой же пустой фрагмент лежи внутри колапса чтобы туда тоже подсунуть чего

Как это сделать по-человечески

Нашел. Удобно то как.

Нельзя отправлять нотификационные пуши, это неудобно

Плохо, что ты заранее высоту контента внутри CollapsingToolbarLayout'а не знаешь...

А то до этого добавляли сами в Developer Drawer свою кнопку чтобы Апп сам уведомлял сервера.

может кому поможет можно отправлять и без firebase для этого нужно составить post запрос на адрес https://fcm.googleapis.com/fcm/send в headers добавить 1)`Authorization` со значением key=fcmapikey 2)`Content-Type` со значением application/json в body должен быть json вот такой { "notification": { "title": "title1611251514", "icon": "ic_push", "body": "body" }, "to": "dHTtJEx-O8g:APA91bGlh0wYs2z4G9fp8UpcGOrfeUkS9O7SZ8Q1N4XSSmWRnszNvemqpEWpCAxRT1A9aLoqdhBfvHvpVE6H1wu23S8IDa2rfSUNjH-xlegKSAKpY8UgjTgNqqOSM9QMrLTL6xwt-xii" }в параметре to указывается токен конкретного устройства

может кому поможет можно отправлять и без firebase для этого нужно составить post запрос на адрес https://fcm.googleapis.com/fcm/send в headers добавить 1)`Authorization` со значением key=fcmapikey 2)`Content-Type` со значением application/json в body должен быть json вот такой { "notification": { "title": "title1611251514", "icon": "ic_push", "body": "body" }, "to": "dHTtJEx-O8g:APA91bGlh0wYs2z4G9fp8UpcGOrfeUkS9O7SZ8Q1N4XSSmWRnszNvemqpEWpCAxRT1A9aLoqdhBfvHvpVE6H1wu23S8IDa2rfSUNjH-xlegKSAKpY8UgjTgNqqOSM9QMrLTL6xwt-xii" }в параметре to указывается токен конкретного устройства

ну это очевидно, для этого ты файрбейс и заводишь

Плохо, что ты заранее высоту контента внутри CollapsingToolbarLayout'а не знаешь...

Ну а что делать..

ну типа: ViewGroup.LayoutParams lp = mAppBarLayout.getLayoutParams(); lp.height = mToolbar.getHeight();

внезапно, getheight от аппбара, тулбара и коллапс лайаута возвращают 0..

view не инициализировался еще?

Хм

Да

(код на пикче довольно стрёмный, избегайте этого по возможности)

стремный то стремный, но ты "оч круто" объяснил что не так, и человек наверно всё понял и больше так не будет ?

может кому поможет можно отправлять и без firebase для этого нужно составить post запрос на адрес https://fcm.googleapis.com/fcm/send в headers добавить 1)`Authorization` со значением key=fcmapikey 2)`Content-Type` со значением application/json в body должен быть json вот такой { "notification": { "title": "title1611251514", "icon": "ic_push", "body": "body" }, "to": "dHTtJEx-O8g:APA91bGlh0wYs2z4G9fp8UpcGOrfeUkS9O7SZ8Q1N4XSSmWRnszNvemqpEWpCAxRT1A9aLoqdhBfvHvpVE6H1wu23S8IDa2rfSUNjH-xlegKSAKpY8UgjTgNqqOSM9QMrLTL6xwt-xii" }в параметре to указывается токен конкретного устройства

Ну да, Я же говорю так и делали до этого)

view не инициализировался еще?

После инициализации тоже 0

стремный то стремный, но ты "оч круто" объяснил что не так, и человек наверно всё понял и больше так не будет ?

ну он не просил пояснять, так что ок)

Господа, кто как решил для себя проблему перестраивания активити при перевороте? То что все уничтожается, что асинх операции теперь привязаны к старой уничтоженной активити.. Ловить ориентацию и флаг волшебный в манифест добавить - не предлпгайте) я знаю такие решения как moxy, rx+rxlifecycle, что-то там от redmadrobot... Кто че мутит? Это же блять важный вопрос)))

Важный, но 90% или флаг "волшебный" ставят или onRestoreInstance

Господа, кто как решил для себя проблему перестраивания активити при перевороте? То что все уничтожается, что асинх операции теперь привязаны к старой уничтоженной активити.. Ловить ориентацию и флаг волшебный в манифест добавить - не предлпгайте) я знаю такие решения как moxy, rx+rxlifecycle, что-то там от redmadrobot... Кто че мутит? Это же блять важный вопрос)))

К сожалению, приблизительно 100% разработчиков, с которыми я работал, не поддерживали поворот экрана. Так что могу поделиться только своими практиками. 1. Состояние вне активити. Например, пользователь видит список из БД. Хоть поворот, хоть смерть процесса, для удачного перезапуска достаточно лишь сохранить состояние скролла. 2. Кратковременное состояние, которое активити несёт с собой. Например, на экране список Bluetooth-устройств. Тогда весь список идёт в instance state. 3. Элементы интерфейса. EditText, у которого есть id, сохранит состояние (не в AdapterView, конечно). TextView сохранит состояние, если поставить android:freezesText="true". 4. Асинхронно — значит не в активити. Загрузка данных из интернета в БД должна происходить в сервисе. Активити — лишь кратковременное отражение этого процесса. Если не используешь Realm, можно руками отослать broadcast, уведомляющий о том, что состояние изменилось. Есть идея при отправке состояния "загружается" (т. е. когда нужно показывать прогрессБар) использовать липкий broadcast, чтобы после восстановления состояния сразу получить его, но я не пробовал.

Важный, но 90% или флаг "волшебный" ставят или onRestoreInstance

Какой волшебный флаг? configChanges?

Какой волшебный флаг? configChanges?

Да, как выразился автор вопроса

Да, как выразился автор вопроса

На самом деле, никогда не пробовал так сделать. Вёрстка для land же не заинфлейтится? А что, если просто процесс помрёт по нехватке памяти?

В итоге, рекомендация в том, чтобы отделять состояние от представления.

Да, с land не прокатит

К сожалению, приблизительно 100% разработчиков, с которыми я работал, не поддерживали поворот экрана. Так что могу поделиться только своими практиками. 1. Состояние вне активити. Например, пользователь видит список из БД. Хоть поворот, хоть смерть процесса, для удачного перезапуска достаточно лишь сохранить состояние скролла. 2. Кратковременное состояние, которое активити несёт с собой. Например, на экране список Bluetooth-устройств. Тогда весь список идёт в instance state. 3. Элементы интерфейса. EditText, у которого есть id, сохранит состояние (не в AdapterView, конечно). TextView сохранит состояние, если поставить android:freezesText="true". 4. Асинхронно — значит не в активити. Загрузка данных из интернета в БД должна происходить в сервисе. Активити — лишь кратковременное отражение этого процесса. Если не используешь Realm, можно руками отослать broadcast, уведомляющий о том, что состояние изменилось. Есть идея при отправке состояния "загружается" (т. е. когда нужно показывать прогрессБар) использовать липкий broadcast, чтобы после восстановления состояния сразу получить его, но я не пробовал.

а чо бы не хранить состояния в статических полях?

MVC там юзать

20й век

https://en.wikipedia.org/wiki/File:MVC-Process.svg

Потому что активити может быть несколько, в разных тасках, в разных частях стека, а статические поля — одни.

И, да, очень легко создать утечку по неосторожностию

ну допустим у меня покерный стол и я повернул активити, тогда стол просто присылает апдейты на отрисовку UI, а сам хранится в статических полях

"асинх операции теперь привязаны к старой уничтоженной активити" - это значит у вас дата хранится в UI а не в data model

вот и огребаете

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Потому что активити может быть несколько, в разных тасках, в разных частях стека, а статические поля — одни.

ок тока это не баг, а фича

ну да, а хранение состояния в статическом поле — баг

nope

Activity - это часть View (в терминах MVC) Хранить состояние в Активити = огребать. Статическое же поле привязано к аппликейшону, а не к Activity поэтому относится к Model

Activity - это часть View (в терминах MVC) Хранить состояние в Активити = огребать. Статическое же поле привязано к аппликейшону, а не к Activity поэтому относится к Model

Активти в терминах МВС и контроллер и вию))

Хранить состояние в Активити = огребать. Согласен. Бывает что именно определенный активность подыхает.

Активти в терминах МВС и контроллер и вию))

в этом и состоит Ваша ошибка

Уточните.

Я могу доказать что это именно так.

Акитивити больше контроллер чем виюха на самом деле.

Который хэндлит переходы, имет лайфцикл. Который входная точка аппа(Один из компонентов)

А вию не может быть входной точкой к аппу. Даже если он супер активный.

ну как бы, в той же википедии. "view отвечает за отображение информации" именно этим и занимается активити, вся бизнес логика вынесена в controller

MVP же..

Активити - это чисто андройдовская поебота для рисования UI если приложение написанно с корректным использованием MVC то замена андройдовских вьюшек на какойнить Swing с последующим запуском апликухи на десктопе не должна вызвать трудностей

в этом и состоит Ваша ошибка

Может быть вы правы. Но я думал что у меня достаточно знании по этой теме. Начиная классические версии этих патернов которые предназначены для работы с приложениями которые имеют UI часть

Акитивити больше контроллер чем виюха на самом деле.

Активити имеет точку входа, но тут ничо не поделать

Активити - это чисто андройдовская поебота для рисования UI если приложение написанно с корректным использованием MVC то замена андройдовских вьюшек на какойнить Swing с последующим запуском апликухи на десктопе не должна вызвать трудностей

Слово МВС очень относительное. Относительнее МВС только сама теория отностительности.

Так как свинг, жафаЭфИкс тоже не МВС.

Насчет Андроида согласен. Было бы замечательно делить на Вию часть отдельно, на апликейшн ложик лэер отдельно. И еще фигню платформа зависимую для быстрого запуска.

И на этом уровне можно было бы управлять этими лайфциклами. И это было бы входной точкой. И кэширования процесса. Именно этот zygote часть нужно было полностю отделить.

Тогда подружать UI часть и апликэйшн ложик каждый раз не было бы проблемой.

А вот сама zygote часть оставалось бы внизу.

Тогда цены бы не было. Были явные у чуваков создателей Ведра с проектированием.

Обычно OS level, Си левел кодеры не думает о таких фигнях как проектирование, архитектура, патерны)

ERROR: S client not available

Слово МВС очень относительное. Относительнее МВС только сама теория отностительности.

Мало кому интересны теортетические изыски. В данном случае у человека проблема, что приложение работает через жопень при повороте экрана. Источником проблемы являтся ошибка проектирования состоящая в том, что данные приложения привязаны к активити. Пишите код так словно активити дестроится на каждый поворот экрана. А лучше уничтожайте её сами для гарантии. Тогда сразу получится, что Активити это просто View и ей нельзя доверять хранение данных. И дальше жизнь наладится.

Мало кому интересны теортетические изыски. В данном случае у человека проблема, что приложение работает через жопень при повороте экрана. Источником проблемы являтся ошибка проектирования состоящая в том, что данные приложения привязаны к активити. Пишите код так словно активити дестроится на каждый поворот экрана. А лучше уничтожайте её сами для гарантии. Тогда сразу получится, что Активити это просто View и ей нельзя доверять хранение данных. И дальше жизнь наладится.

+1 Согласен с вами!

Золотые твои слова, Юрий Венедиктович!

На том и порешили)

Подскажите пожалуйста как сделать что бы в конструкции чекбоксов определенные чеки делали к общему результату +1.

Коллеги, подскажите по RxJava. Есть Observable на который подписан подписчик, он в свою очередь получает данные. Когда данные получил нужно тут же запустить еще два Observable и дождаться пока оба выполнятся и когда они выполнятся надо чтобы каждый из них выполнил определенный метод и только когда оба выполнят каждый свой метод уже потом выполнять дальше логику. Как реализовать ? Ожидание выполнения двух Observable делаю через zip а вот когда в каждом Observable выполняю метод то логика дальше выполняется а не ожидает выполнения методов

Жрёт оперативку?

Не только

то есть нормально сделать стили это не ваш вариант ? и написать интерфейсы для обработки кликов из самого адаптера, это сложно ?

Нормально сделать стили - это именно наш вариант. Допустим, если б как в listview - был selector drawable. Если моим айтемам нужен селектор - то да, но видится мне что ежели айтемами управляет лист - то скорее селектор нужен ему, а не им, так же как и клик-перехватчик - нужен листу - а не айтемам И дураку понятно что клик-слушатель можно через адаптер на каждый холдер пробрасывать. Но это не покаким архитекутрным, паттерновым и прочим делам не правильно. Это оч. популярное и рабочее решение, но..... не должен адаптер по природе своей разруливать клики И в этом свете в absListview - были заложены правильные (архитектурно-правильные) подходы.

Нормально сделать стили - это именно наш вариант. Допустим, если б как в listview - был selector drawable. Если моим айтемам нужен селектор - то да, но видится мне что ежели айтемами управляет лист - то скорее селектор нужен ему, а не им, так же как и клик-перехватчик - нужен листу - а не айтемам И дураку понятно что клик-слушатель можно через адаптер на каждый холдер пробрасывать. Но это не покаким архитекутрным, паттерновым и прочим делам не правильно. Это оч. популярное и рабочее решение, но..... не должен адаптер по природе своей разруливать клики И в этом свете в absListview - были заложены правильные (архитектурно-правильные) подходы.

ну перехватики клик у ресайкла и ему назначь эту роль.

Ну вот жалко, что не коробочно - это всё у ресайклера ... а так то да

а селекторы, у меня в итемсе может быть куча не просто обработка нажатий. в селекторы я перебрасываю стейты , например, как новый, прочитанный или нет. итд.

а селекторы, у меня в итемсе может быть куча не просто обработка нажатий. в селекторы я перебрасываю стейты , например, как новый, прочитанный или нет. итд.

Ну это другое дело, это как раз те кейсы - когда твои селекторы отвечают за большее чем просто клики и селекты

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

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

Сунуть её в onResume у фрагмента?

Хотя вроде так не сработает

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

Оффскринлимит 1 сделай

Оффскринлимит 1 сделай

А они кешироваться будут?

А они кешироваться будут?

Ручками кешируй

Оффскринлимит 1 сделай

По умолчанию же так

Вообще, оффскрин фрагменты ведут себя довольно неприятно, например, с onActivutyResult.

@korotovskii в fragment.setUserVisibleHint()

По умолчанию же так

По умолчанию 4 вроде

Пусть в бандл сохраняет и будет счастье

Тем более, мы не знаем какой адаптер он использует

Чем лечить?

На старых апи

Может, сделать fitsSystemWindows="@boolean/fitsSystemWindows" и написать разны булеаны для разных версий?