По лейаутам:
- Много пустых, где есть только 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 нинада - это просто заметание пыли под ковер.
- При обработке кликов адаптера желательно не лазать в адаптер снаружи по индексу, а чтобы сам адаптер вызывал коллбек со своими готовыми данными.
В целом - жить можно. Нормальный процесс обучения вижу я ;-)