Денис Загаевский

Конечно они об этом знают и переопределяют equals и hashCode правильно.

Практически у любой UI системы есть свой тред, на котором надо осуществлять доступ к элементам UI. Очевидно, здесь нужно перенести выполнение обратно на FX application thread.

Указатель это есть адрес, он и хранится в переменной.
& Это ссылка. Как бы алиас на то место, куда ссылается. Разница есть.
Ссылку нельзя изменить, изменить можно только значение в памяти, куда ссылается ссылка. Саму ссылку поменять нельзя. Указатель можно менять. Константный указатель нельзя поменять.
Ссылка не может быть неинициализированна, указатель может быть.
Указатель может указывать на память в куче, которая должна быть освобождена, ссылку никогда не нужно освобождать отдельно.
Плюс ещё бывают r-value ссылки(кажется, так называются) &&. В них нельзя присваивать, только читать.

Статический класс имеет смысл только когда он расположен внутри другого класса. В этом случае он не будет иметь доступа к нестатическим полям объемлющего класса.
Поэтому static здесь просто лишнее.

С другой стороны, непонятно, что ты хочешь сделать. Выглядит так, что у тебя есть какой-то this, на котором ты вызываешь методы getApplicationContext, bindService и тд. Это активити? В лбом случае это какой-то контекст, и меня сразу настораживает сочетание слов "static" и "Context". Скорее всего, ты что-то делаешь не так, и все эти твои методы должны быть просто приватными методами твоей активити в простейшем случае.

Это не "создание объекта через родителя". Создание во всех случаях происходит одинаково. Здесь ссылка на ребенка сохраняется в переменную типа родителя. В этом, типа, и заключается динамический полиморфизм. Смысл в том, что ты можешь разных, заранее не определенных детей, складывать в коллекцию с типом родителя, например. Или принимать и возвращать из методов - тоже родителя, а не конкретных детей.
Зачем? Например, у тебя есть объект клетка, который содержит животное. Условно, ты не должен делать разные клетки - PigCage, DogCage, CatCage, а должен использовать одну.

Строки лежат в xml(может быть в бинарном виде запакованном) в ресурсах приложения. Также генерируется R-файл(IDE его генерирует, и при билде он тоже генерируется), в нём лежат айдишники строк, не сами строки. В рантайме строки из ресурсов читаются по айдишникам из R-файла, есть специальный класс Resources, в нём используется AssetManager. Когда ты делаешь
context.getString(R.string.mystring) или context.getResources().getString(R.string.mystring) это и происходит.
Хочешь узнать больше - открывай код и читай его.

Потому что этот айдишник используется для сохранения в бандл. Представь ситуацию, когда ты добавил в один лэйаут две своих вьюхи, и у них случилось разное состояние - как их сохранить в в один бандл? Вот тут-то айдишник и поможет. А если ты сделаешь "постоянный айди", то, очевидно, он будет у них одиинаковый, и в описанной ситуации всё просто упадёт.
Ответ - так и должно быть. Состояние вьюхи сохраняется только если у неё есть айди, это нормально и правильно.

layoutManager scrollToPosition, smoothScrollToPosition

Нужно сохранять в бд на сервере. Например, в Firebase. Или поднять свой сервер.

json в теле post, и в ответе get. Не используй HttpUrlConnection, бери Retrofit+OkHttp + какой-нибудь из сериализаторов(Moshi, Gson, Jackson).

Во-первых, у тебя почему-то где-то расширение h, а где-то hpp. Нужно привести к одному виду.
Во-вторых у тебя циклический include, это не будет работать. Это надо решать. Например, можно решить с помощью forward declaration и pimpl.

Что ещё за Single<String> или Single<Exception>? Это же дичь. Сделай так: репозиторий пускай возвращает Single<Result>.

sealed class Result {
    data class Success(result: String): Result()
    data class Error(exception: Exception): Result()
}

Пара замечаний:
1. Сабжект тут не нужен, в com.jakewharton.rxbinding2:rxbinding-kotlin есть для этого нормальный extension textChanges()
2. Нужно минимизировать мутирование внешнего стейта из rx-цепочки.

Calendar.DAY_OF_MONTH - это константа. Её нужно передавать в метод Calendar::get.
Читай доку.Календарь лучше получать с помощью фабричного метода Calendar.getInstance().

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