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

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

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

Что ещё за 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-цепочки.

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

До чего убогий API у этой штуки...
Тебе надо написать кастомный LiveData, который будет ходить в поиск, а также использовать switchMap вместо map.
Вот тут доступно описано.
И не надо использовать асинктаски для того, чтобы ходить в сеть...

В Bundle. onSaveInstanceState/onRestoreInstanceState.
И ты же не думаешь, что Мокси это то,чем все пользуются?

Итого ответ - нет, так делать не надо, фрагмент должен быть независим от активити. Если нужно закрывать приложение при закрытии последнего фрагмента, надо правильно добавлять фрагменты в бекстек.

Это штатная ситуация, и приложение так себя вести не должно (в смысле начинать самоубиваться при сворачивании. Это дичь.)

android.R.id.home

Только Foreground Service

Эмм, shuffle ()?

Вообще бд вправе отдать данные в произвольном порядке, так что задавай в запросе явно order by по нужному тебе полю.

Не читал всю портянку, но. Очевидно, что dbManager во фрагменте даже не создаётся. Все поля с присвоением создаются сразу при создании объекта, и в этот момент, конечно же, context == null. Читай про жизненный цикл фрагментов. Нужно отложить создание менеджера, например, использовав by lazy, или lateinit var.

forEachIndexed это extension, сахар для for(x in list). А это уже синтаксический сахар для while(iterator.hasNext()). Дальше надо разбираться с итератором, и там возможны варианты. Самый плохой из них - это ConcurrentModificationException, то есть изменение списка, по которому сейчас происходит итерация.
Ответ - так делать вообще не надо.
По коду выглядит так, будто тебе надо просто использовать напрямую iterator() и в нужный момент вызывать у него remove(). А index здесь вообще лишний.

как быть?

Учить язык, на котором пишешь. Ну и документацию читать.
Метод возвращает Serializable, как, по-твоему, оно должно "распознаваться"? Нужно кастовать к твоему типу. as Note.

Очевидно надо использовать новый способ. В новых версиях андроида могут грохнуть этот метод (или просто он не будет работать), и тогда ты с жопой в огне будешь переписывать. Пока просто пометили deprecated, чтобы все перестали пользоваться.