m обозначает member field. Но нахуа это писать, если code inspection в студии всё расскажет и покажет? 😏

https://t.me/android_ru/1062156

Power Save Mode?🤨

Скорее, Notepad mode 😁

Как грится: дебаггер придумали для неучей, которые не умеют писать правильный код без ошибок😎

остались еще даже те, кто ВИМ юзает. Когда начинал учиться, умные дядьки на форумах писали, что настоящий прграммист пишет в линуксе, и должен всё юзать в консоли, никакого GUI. И упаси бог хоть раз отправить коммит в Гит мышкой, только git commit, только хардкор)) пока один не написал "хватит строить из себя крутых консольщиков, как человеку удобно, так пусть и делает"

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

И правильно он написал :)

дебаггер придумали те, кто не умеет System.out.println() быстро набирать)))

Какой проект смотреть? UtilityBills?

да, это текущий. просто оцените качество кода, насколько все ужасно)

Специально для них в котлине println()

Здравствуйте. Почему при использовании scrollToPositionWithOffset не вызывается onScrollStateChange?

По лейаутам:
- Много пустых, где есть только ConstraintLayout или LinearLayout и больше ничего. Либо нужно добавить TODO, либо удалить, если они не используются.
- Не нужно хардкодить margins/paddings и т.п. Их нужно вынести в dimen и дать имена по предназначению (ни в коем случае не что-то типа margin_16dp)
- В ConstraintLayout избегайте со страшной силой вложенные контейнеры типа LinearLayout, ConstraintLayout. Его придумали именно для того, чтобы избавиться от вложенных контейнеров. Вложенность плохо влияет на его производительность.

По цветам:
- Желательно их называть по предназначению, а не по имени цвета (то же самое, что и с dimen).

По коду:
- Разрешена работа с бд на главном потоке - как бы нехорошо так делать, нужно в фоне.
- Желательно использовать подход single activity + fragments
- Чтобы избавиться от findViewById, используйте view binding.
- AddApartmentActivity - нет смысла в активити хранить ее контекст. Она сама - контекст :)
- Все приватные поля должны быть приватными (например, та же AddApartmentActivity). Вообще, классы должны прятать всё по максимуму, а не заниматься эксгибиционизмом :)
- getString в активити и фрагментах можно вызывать без getResources. Меньше писанины.
- Бизнес-логику следует выносить в специализированный класс, а не держать ее в активити (pushDataBase)
- MyCustomFragment(int layoutResId) - у Fragment уже есть свой конструктор, куда можно передать layoutResId. Вы делаете то, что уже сделано за вас :)
- Нинада у фрагментов хранить контекст. Жизнь фрагмента сложна и непредсказуема. Контекст в любой момент может превратиться в тыкву. Используйте requireContext() - он хотя бы вызовет крэш, если вы обратитесь к контексту в неподходящий момент. Тогда можно будет найти причину и исправить. Проверять контекст на null нинада - это просто заметание пыли под ковер.
- При обработке кликов адаптера желательно не лазать в адаптер снаружи по индексу, а чтобы сам адаптер вызывал коллбек со своими готовыми данными.

В целом - жить можно. Нормальный процесс обучения вижу я ;-)

Спасибо огромное, все учту. Моя проблема - итеративный подход к написанию кода - наделать костылей, а потом постепенно причесывать)). вложенный LinearLayout для того, чтобы оперативно перебрать чилдов, не проверяя их класс. или может есть другой способ?

Итеративный подход - это хорошо.
Можно оставить LinearLayout, если это удобно в данном случае.

Просто учтитывайте, что в ConstraintLayout этим не стоит злоупотреблять. Я лечил проект, в котором специалисты такого в лейаутах навертели, что приходил ANR + крэш.

Привет ещё раз, помогите пожалуйста. При переходе на конкретный фрагмент крашится аппликация, как решить проблему?
Upd: defaultValue выставлял, все равно ругается

ок, буду иметь в виду. Впервые слышу о таком, в интернетах пихают по три вложенных лайаута, и говорят что так норм. а в ConstraintLayout сколько нужно делать привязок? обязательно все 4, или достаточно 2? и есть вязать, например, нижний к верхнему, то нужно ли делать привязку верхнего к нижнему?

Ну, синтаксис позволяет, вот и пихают. К тому же осталась старая привычка (до CL) вкладывать одно в другое.

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

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

много нового узнал для себя. то что пишут в туториалах, и как делают на производстве - разные вещи. Спасибо)