https://habrahabr.ru/post/343248/

Arsen сейчас делаю что то подобное запихнул тот intent в ресивер и отправляю данный с датой intent.putExtra("data", remoteMessage?.data?.toJsonString()) после чего в главной активити где соержаться все фрагменты получаю эти данные intent.getStringExtra("data") но вы сказали мол дальше создавать фрагмент, я правильно всё понял?

на хабре по нему какраз таки туториалов годных оверх100500

Да, статья годная, но например я так и не понял для чего нужен например subcomponent, то есть как его внедрять на стадии написании кода.

и проблема с эмулятором Android Studio!

и проблема с эмулятором Android Studio!

как?

https://medium.com/revolut/building-new-features-using-recyclerview-only-aa7db3d8f282

Всем привет! Мне одному так кажется: Firebase - рекламирует себя как набор супер-полезных фич для Android-а но по факту залазиванья туда (в Firebase) - приходит понимание, что это целая платформа(экосистема/философия и тд), где у тебя либо всё должно быть на ней based (server, ios, android, web). В противном случае, Google Cloud Console - более чем покрывает всё необходимое Иными, словами - затаскивание файербейза должно быть комплексным и всеобъемлющим, в противном случае - оно не оправдано (Поддержка консоли, админки, своя база юзеров, плагин для студии со 100500 скрытыми manifest-мерджами и тд)

Насколько я понимаю, целая система не обязательна для мелких задач.

Ну вот в том то и дело - что отличить гугловый "маркетинговый deprecated" от "реального технического" иногда сложно))

Как можно разбить получения Map<String, String> по полям?

WakefullBroadcastReceiver - deprecated. Поэтому если у тебя объявлен в манифесте ресивер - нужно дважды думать как в нём выполняться правильно и если дергать сервис - то тем более думать как))

Согласен, я этот момент как-то декомпили изучал, и вот что интересно поддержка нового O заимплеменчена в том же core который и gcm юзает и там на самом деле они правильно(с учетом doze и bg-limitations) проксируют вызовы из бродкаст ресивера в твоем манифесте в службу в твоем манифесте...)) но там это сделали за тебя - в остальных случаях на O - тебе самому все равно придется это решать в подобных случаях, для твоих ресиверов и служб

Arsen да всё тоже на самом деле в методе ресивера обращаюсь к данным remoteMessage?.data который из себя представляют Map<String, String> Нашёл некое решение для отображения map в методо putExtra: intent.putExtra("data", remoteMessage?.data as Serializable?) и в активити когда получаю эти данные делаю следующее: intent.getSerializableExtra("data") as Map<String, String> Вот он мне и ругается на cast мол: Unchecked cast хотя по идее работает, вот и ищу альтернативу как сделать так, чтобы он не шумел. Как вариант - разбить на "получение полей карты"

А можно как-нибудь получать пуши не в бекграунде, а при закрытом (killed) приложении? (если только оно не whitelisted производителем, хе) Нашел только вот это https://stackoverflow.com/questions/24313539/push-notifications-when-app-is-closed/24314088#24314088 И предложение открывать/просить пользователя открыть экран в Settings с apps auto-launch

Arsen поэтому я и написал что скорей всего работать будет, но шуметь не перестанет. Хочу избавитьсяь от него

можешь сделать свою модель с данными serializable и класть в интент ее.

ну создать модель проблем нет, а вот дальше чутка можно пояснить? сами данные remoteMessage?.data где у меня будет обитать?

А можно как-нибудь получать пуши не в бекграунде, а при закрытом (killed) приложении? (если только оно не whitelisted производителем, хе) Нашел только вот это https://stackoverflow.com/questions/24313539/push-notifications-when-app-is-closed/24314088#24314088 И предложение открывать/просить пользователя открыть экран в Settings с apps auto-launch

https://www.javacodegeeks.com/2014/01/android-tutorial-two-methods-of-passing-object-by-intent-serializableparcelable.html

Кстати если в кратце в gcm гугл ща делает финт ушами - если билдSDK < smth то всё по-старому: startService, если новый апи - то там же в ресивере (onReceive): - имея контекст - делаем bindService (тем самым имеем единый process, приоритет) - а значит foreground - синхронно блокируемся и 10с ждем завершения - по таймауту кидают службе cancel - unbind и выход из onReceive (либо если код "уложился" в 10 сек - сервис сам отбиндивается, лок снимается - и ... так же... выход из onReceive) я так понимаю в основе лежит два правила: прибиндиная служба - имеет тот же приоритет к чему прибиндилась выполнение в onReceive() - имеет foreground приоритет

кто знает почему добавленные библиотеки в gradle влияют на холодный старт приложение? у меня абсолютно пустой проект одним activity splash открывается около 3 сек. удалил все библиотеки с gradle стало ~1.4ms?

Manifest Merge - проверяй))

Можно подробнее?

Если я получаю данный через intent.getSerializableExtra("data") могу ли я потом делать проверку на наличе чего то внутри таким образом: intent.getSerializableExtra("data") извините за может очевидный вопрос, но логами не могу показать, так как для того чтобы показать нужен доступ к учетке для отправки нотификаций с firebase console

Шота я из деревни походу. Не понял(