Так можно же и заплатить) И вряд-ли схема с бд будет надежнее пушей работать

Как гарантировать доставку пуша когда у пользователя могут: 1. сесть телефон 2. потеряться связь 3. кончиться деньги на интернете 4. еще куча вариантов ?

Голубиной почтой можно пушить

6. быть запрещены фоновые приложения на очередном сяоми

7. Пользователь может банально умереть. 🤷‍♂

Это можно попросить пользователя выключить)

Можно ещё также попросить пользователя всегда держать телефон заряженным, всегда пополнять счёт своевременно, не идти в лес, не терять телефон, ещё куча вариантов...

Можно ещё также попросить пользователя всегда держать телефон заряженным, всегда пополнять счёт своевременно, не идти в лес, не терять телефон, ещё куча вариантов...

Ребята, такой вопрос, не могу найти в документации четкого ответа. Вопрос про Firebase Messaging, вызывается ли onNewToken (FirebaseMessagingService) если приложение изначально убито? Если да, то покажите пожалуйста пруфы ?

У меня тут появилась мысль, подскажите, норм или нет: в моём приложении оч важны пуши (это то, ради чего приложение будут качать), и т.к. фб пуши не надёжны, мб взять fb realtime db, сделать там иерархию child-ов, сервер будет пушить в нужные child-ы таймштампы, а все пользователи будут находиться в режиме read-only и чекать таймштампы. Как только таймштапм поменяется, будет выдан пуш. Как вам идея? Похоже на костыль, но гарантированность пушей нужна позарез.

парни, есть вопрос новичка в ведре: есть вьюха – contstrainsLayout, внутри которого recyclerView. у activity этой вьюхи типичная простейшая имплементация из всяких уроков – адаптер там, вью холдер, простая работа с сетью через volley и picasso. вроде всё асинхронно, вроде везде, где работа с json'ами обёрнуто в реактивные вызовы fromCallable, а вьюха при открытии очень медленно открывается и тормозит при скролле, соответственно со всякими: Choreographer: Skipped 86 frames! The application may be doing too much work on its main thread подскажите плес, куда копать и на что обратить внимание

парни, есть вопрос новичка в ведре: есть вьюха – contstrainsLayout, внутри которого recyclerView. у activity этой вьюхи типичная простейшая имплементация из всяких уроков – адаптер там, вью холдер, простая работа с сетью через volley и picasso. вроде всё асинхронно, вроде везде, где работа с json'ами обёрнуто в реактивные вызовы fromCallable, а вьюха при открытии очень медленно открывается и тормозит при скролле, соответственно со всякими: Choreographer: Skipped 86 frames! The application may be doing too much work on its main thread подскажите плес, куда копать и на что обратить внимание

Слишком много жрет говорят

Если не в ресайклере, то меньше чем 2 вложенных линера

Есть ссылка?

Думаю из за пикассо, картинки какого размера?

апи позволяет брать любого, сейчас гружу 100*100

Стараюсь обходиться без констрейта

может в андроид окружении есть какие-нибудь инструменты, чтобы посмотреть чем там ui-тред занимался?

может в андроид окружении есть какие-нибудь инструменты, чтобы посмотреть чем там ui-тред занимался?

Профайлер

попробовал сейчас это конечно симпотично, но не особо говорит мне о том, чем там занимался ui-тред :)

парни, есть вопрос новичка в ведре: есть вьюха – contstrainsLayout, внутри которого recyclerView. у activity этой вьюхи типичная простейшая имплементация из всяких уроков – адаптер там, вью холдер, простая работа с сетью через volley и picasso. вроде всё асинхронно, вроде везде, где работа с json'ами обёрнуто в реактивные вызовы fromCallable, а вьюха при открытии очень медленно открывается и тормозит при скролле, соответственно со всякими: Choreographer: Skipped 86 frames! The application may be doing too much work on its main thread подскажите плес, куда копать и на что обратить внимание

Переопредели метод onFailedRecyclerView и посмотри, ресайклятся ли вьюхи у тебя

спасибо, проверил, но вьюхи переиспользуются как положено частично при помощи профайлера проблему нашёл – я в viewHolder сунул Picasso.get(), который на старте активити съедает аж ~3 секунды, уже вынес эту конструкцию в синглтон инициализирующийся на старте приложения

А что находится во ViewHolder?

ну теперь он выглядит так

ну теперь он выглядит так

Это у тебя оптимизация с findViewById? Или есть другие соображения их так юзать? Почему не itemView.user_id.text = comment.text в методе bind.

Зачем пикассо в конструктор?

Использовать логи?

да не. мне надо в коде сделать действия если апп просто запущен но активити нет

да не. мне надо в коде сделать действия если апп просто запущен но активити нет

Что делать если мне в тестах нужен applicationContext?

Activity lifecycle callback например

ну теперь он выглядит так

Это у тебя оптимизация с findViewById? Или есть другие соображения их так юзать? Почему не itemView.user_id.text = comment.text в методе bind.

Зачем пикассо в конструктор?

Если у тебя в viewHolder есть ресайклер, то у него свой отдельный viewPool. Сделай общий viewPool. В onCreateViewHolder сделай holder.commentsList.serRecycledVieePool(viewPool)

У гугля есть штатное апи для сокращения ссылок. Где то в консоли всех api. Но х.з. какая у него скорость. А так встроенный gзип сожмет раза в 3-4

Хм, как дестроить активити без прерывания дебага в сингл-активити приложении?

А ещё лучше LayoutContainer.

Кто нибудь знает куда делся swiperefreshLayout в версии 1.1.0 в com.google.android.material:material ?

пропал? классная штука была

может как-то по другому называется, кто в курсе?

Что за commentsList? У тебя есть вложенный список?

а что гугл говорит?

нет, вложенных списков нет. спасибо, посмотрю на собственный pool ресайклера.