потому что наговнокодишь и без даггера херни которая повалит приложение

и все равно будет ручное протыкивание/тесты на CI

конечно будет

а еще тоже самое можно сказать про динамическую типизацию

О, а какие альтернативы для андроида тогда лучше использовать? Самописный di?

https://www.youtube.com/watch?v=ZnIv79j_iuY

а еще тоже самое можно сказать про динамическую типизацию

ну да, рантаймовый DI — это динамикодрисня

https://www.youtube.com/watch?v=ZnIv79j_iuY

разве не пиарит? даггер-андроид же и так на этом

разве не пиарит? даггер-андроид же и так на этом

что?

просто в названии "апи, которое не рекламирует гугл"

короче, профайлер лучше, чем кофейная гуща

Типа кинуть дамп аллокации памяти? Я прост за год разработки, ни разу а профайлер не заходил

Типа кинуть дамп аллокации памяти? Я прост за год разработки, ни разу а профайлер не заходил

Да при чём тут память? В логах написано же: приложение делает слишком много работы.

а как теперь даггеру это объяснить?

@named?

https://www.youtube.com/watch?v=ZnIv79j_iuY

спасибо за крутой доклад

ребят, что вы юзаете для показа лайв потока видео с rtsp юрла?

Да при чём тут память? В логах написано же: приложение делает слишком много работы.

Так каким инструментом я могу чекнуть, что грузит main поток?

Так каким инструментом я могу чекнуть, что грузит main поток?

CPU-профайлером

Так каким инструментом я могу чекнуть, что грузит main поток?

System trace или Profiler

nanoscope топчик)

Так все же как мне сравнить timestamp и дату в формате iso 8601? Не нашел рабочего способа кроме как парсить строку

мне нужно провеирть прошло ли 24 часа с полученной даты. такой способ: val createdAt: Callendar = car.createdAt createdAt.add(Calendar.DAY_OF_MONTH, 1) val now = Calendar.getInstance(TimeZone.getTimeZone("GMT")) if (createdAt.before(now)) {...} верный?

мне нужно провеирть прошло ли 24 часа с полученной даты. такой способ: val createdAt: Callendar = car.createdAt createdAt.add(Calendar.DAY_OF_MONTH, 1) val now = Calendar.getInstance(TimeZone.getTimeZone("GMT")) if (createdAt.before(now)) {...} верный?

не очень, createdAt тоже приравняй к GMT

не очень, createdAt тоже приравняй к GMT

он и так возвращает GMT. Мне больше хочется узнать про метод add у Callendar. Он ведь перематает мне дату на одни сутки вперёд верно?

он и так возвращает GMT. Мне больше хочется узнать про метод add у Callendar. Он ведь перематает мне дату на одни сутки вперёд верно?

да

День добрый, вопрос про navigation component. У меня есть экран с BottomNavigationMenu, на этом экране я делаю bnm.setupWitNavController и устанавливается bottom_navigation для моего меню. В графе bottom_navigation есть два фрагмента - CalendarFragment и ProfileFragment. И с фрагмента ProfileFragment я хочу сделать переход на другой фрагмент, который лежит в main_navigation. Как можно осуществить такую штуку? Не исключаю, что это неправильный подход, но у меня кейс такой, что только на главном экране видно BottomNavigation, на других - нет.

через интерфейс вызываешь у активити bnm.visibility = view.invisible

если я правильно понял тебя

Коллеги, никто не работал с Huawei Mobile Services? Пуши, покупки? У них семпл 20 века с комментами на китайском)

через интерфейс вызываешь у активити bnm.visibility = view.invisible

что-то мне это не нравится, вызывать метод везде, чтобы скрывать меню

Всм, ты скрыл bnm у он не появится пока ты не вызовешь обратно в нужный момент

потом, юзер жмакает "назад", и надо проверять показывать здесь или нет bnm

CPU-профайлером

получается Хореографер долго грузит UI поток, т.е. получается у меня верстка перегружена? или это может быть в чем-то еще проблема?

потом, юзер жмакает "назад", и надо проверять показывать здесь или нет bnm

можно навКонтроллеру добавить onDestinationChangedListener в котором проверять текущее положение и решать показывать или нет bnv

получается Хореографер долго грузит UI поток, т.е. получается у меня верстка перегружена? или это может быть в чем-то еще проблема?

«хореографер долго грузит UI-поток» — это какой-то набор слов. Здесь видно, что measure в ресайклере тяжёлый

можно навКонтроллеру добавить onDestinationChangedListener в котором проверять текущее положение и решать показывать или нет bnv

неужели нельзя без проверок этих обойтись?

неужели нельзя без проверок этих обойтись?

а чем эти проверки плохи? 3-4 строки же

«хореографер долго грузит UI-поток» — это какой-то набор слов. Здесь видно, что measure в ресайклере тяжёлый

хм...странно, у меня там только один уровень вложенности и сделан на ConstraintLayout, внутри около 30 вьюшек по типу TextView, ImageView (для иконок)

хм...странно, у меня там только один уровень вложенности и сделан на ConstraintLayout, внутри около 30 вьюшек по типу TextView, ImageView (для иконок)

а, ну вот констреинт и тормозит, ничего странного

а, ну вот констреинт и тормозит, ничего странного

ипааааать. Так вроде проблемы с производительностью уже фиксанули?

ипааааать. Так вроде проблемы с производительностью уже фиксанули?

это бесконечная тема, они есть у всех и везде)

Всем привет, подскажите пожалуйста. сделал двойную навигацию navgationdrawer и viewPager. Навигация по одним и тем же фрагментам, не могу соединить. Нужно сделать так чтобы при выборе пункта меню переходило на соответствующий таб и выводился нужный фрагмент и тоже самое с viewPager. щас при пролистывании табов меняются фрагменты и получается что фрагмент измененный в viewPager накладывается на фрагмент выбранный в navgationdrawer

это бесконечная тема, они есть у всех и везде)

но люди ведь после этого не идут все верстать на framelayout ?

но люди ведь после этого не идут все верстать на framelayout ?

нет, поэтому принято говорить, что андроид тормозит

всем привет, подскажите есть бд на ROOM для месседжера, из некого класса MessageItem. вот так я получаю диалог @Query("SELECT * FROM chatRooms") List<MessageItem> getAll(); можно как-то сюда добавить поле id диалога? или правильнее делать бд для диалога вот так: @Entity(tableName = "chatRooms") public class ListMessageItem{ @PrimaryKey() public Integer id; @TypeConverters(MessageItemConvertor.class) private List<MessageItem> messages; }

ипааааать. Так вроде проблемы с производительностью уже фиксанули?

Там нечего фиксить, он так и будет работать. Там достаточно сложные алгоритмы рассчёта позиции вью. Здесь недавно кидали статью о том что к него под капотом

У констреинта есть атрибут optimization level или как-то так, он может спростить некоторые этапы measure, но у него есть своя цена тоже

если в кажом Сообщение хранить id диалога, это глупо... а если делать поле id и поле list<Сообщение> то list<Сообщение> надо парсить, а это вроде тоже не хорошо.. чет не знаю как быть и путного не могу найти в инете

если в кажом Сообщение хранить id диалога, это глупо... а если делать поле id и поле list<Сообщение> то list<Сообщение> надо парсить, а это вроде тоже не хорошо.. чет не знаю как быть и путного не могу найти в инете

хранить ид диалога в сообщении — здраво и логично

если в кажом Сообщение хранить id диалога, это глупо... а если делать поле id и поле list<Сообщение> то list<Сообщение> надо парсить, а это вроде тоже не хорошо.. чет не знаю как быть и путного не могу найти в инете

> в кажом Сообщение хранить id диалога, это глупо Ни разу

полно, как и у всех, как и везде. Могу ещё повторить)

хранить ид диалога в сообщении — здраво и логично

получается что в сообщении появится поле ид диалога и придется добавлять собственный ид @PrimaryKey(autoGenerate = true), чтобы ид чообщений не пересеклись?

получается что в сообщении появится поле ид диалога и придется добавлять собственный ид @PrimaryKey(autoGenerate = true), чтобы ид чообщений не пересеклись?

у любой нормальной сущности есть первичные ключи, чо тут такого

у любой нормальной сущности есть первичные ключи, чо тут такого

ну если бы как-то можено было бы припилить id к list<Сообщения> то тогда было бы достоточно индентифицировать сообщение в бд по id сообщения, а не создавать новый id

ну если бы как-то можено было бы припилить id к list<Сообщения> то тогда было бы достоточно индентифицировать сообщение в бд по id сообщения, а не создавать новый id

у тебя каждое сообщение все равно должно содержать id диалога

ничего не понял, но очень интересно

сами по себе сообщения не живут

сами по себе сообщения не живут

это понятно)

но погоди, я получается сообщения со всех диалогов, буду хранить в одном бд.. это же по моему не хорошо

получается что в сообщении появится поле ид диалога и придется добавлять собственный ид @PrimaryKey(autoGenerate = true), чтобы ид чообщений не пересеклись?

Во внешних ключах ничего страшного нет, поверьте

но погоди, я получается сообщения со всех диалогов, буду хранить в одном бд.. это же по моему не хорошо

С чего бы? И что значит в одной бд? В одной таблице может быть?

но погоди, я получается сообщения со всех диалогов, буду хранить в одном бд.. это же по моему не хорошо

более того, в одной таблице. Это абсолютно нормально.

Кстати, SQLite индексы по внешним ключам строит? Не помню что то, по идее должен

но погоди, я получается сообщения со всех диалогов, буду хранить в одном бд.. это же по моему не хорошо

а ты под каждый диалог хочешь создавать новую бд?)

более того, в одной таблице. Это абсолютно нормально.

интересно)

спасибо за помощь)

а ты под каждый диалог хочешь создавать новую бд?)

таблицу* немного не так выразился)

нет, поэтому принято говорить, что андроид тормозит

а если попробовать внутри кострэинта разделить все еще на маленькие контейнеры? т.е. если у меня сейчас просто 30 элементов, то сделать 3 контейнера и в них запихать по 10 элементов, будет ли увеличена скорость отрисовки у констрэинта?

а если попробовать внутри кострэинта разделить все еще на маленькие контейнеры? т.е. если у меня сейчас просто 30 элементов, то сделать 3 контейнера и в них запихать по 10 элементов, будет ли увеличена скорость отрисовки у констрэинта?

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

http://wiresareobsolete.com/2016/07/constraintlayout-part-2/

Вот сколько там "дерьма" внутри

Кому интересно, гуглите алгоритм Cassowary

Этот алгоритм тоже вроде бы использован в Autolayout на iOS. И там тоже с ним есть некоторые "шороховатости"

Этот алгоритм тоже вроде бы использован в Autolayout на iOS. И там тоже с ним есть некоторые "шороховатости"

там приемлемая производительность только начиная с iOS 12

там приемлемая производительность только начиная с iOS 12

Переписали? 😁

Переписали? 😁

поправили экспоненциальную сложность на константную 🌚

добрый день. подскажите где можно посмотреть реализацию таблицы(см.скрин) с возможностью заполнения из json

добрый день. подскажите где можно посмотреть реализацию таблицы(см.скрин) с возможностью заполнения из json

Что именно посмотреть?

поправили экспоненциальную сложность на константную 🌚

А, изи-пизи

Что именно посмотреть?

как реализовать подобный грид

как реализовать подобный грид

а подскажите, почему notification изначально создается, но потом не меняется, когда я делаю NotificationManager.notify с тем же ID и нотифаем, но другим текстом