Ну и плюс не особо понятно, зачем тут вообще Map? У мапы совершенно другое применение. Вы видимо неверное вычитали смысл этой библиотеки. Спорить с тем, что я мог плохо это объяснить в статье не буду, так скорее всего и есть
Нет, не все принимает на вход Map. Exposed - это вообще либа для SQL. Джавовские файлы тоже не принимают на вход Map. Jetpack DataStore не принимает на вход мама, к тому же там вообще флоу.
Крэйты для всех этих библиотек позволяют сделать единый унифицированный при, в котором не будет этих зависимостей. Крэйты убирают из кода полностью зависимость от конкретных библиотек.
На примере рассмотрим. Допустим, раньше хранили данные пользователя в SharedPreferences в жосне. Данные стали слишком большими, префоф стало недостаточно. Как хорошо что у нас были Крэйты. Мы теперь будем хранить данные пользователя локально в файле, а верхнеуровневый при останется такой же каким был. То же самое и с датастором и SQL
Не совсем понял, при чем тут NoSql. Но окей. Допустим, вы используете одну либу для NoSql. У нее одна реализация для Map. Кто-то захотел другую либу для NoSql взять. Там уже другая обёртка. А вам нужно хранить одинаковый тип данных. С Крейтами вы просто оборачивание это в крейт и у вас код, где использовались Крэйты раньше, никак не меняется. Как и писал, это нужно для увеличения уровня абстракции.
Речь конечно не конкретно про NoSql. Тут именно подход для Key-Value хранения. В андроиднвх библиотеках, вроде как и у всех, абстракции разные. А Крэйты просто унифицируют этот доступ
Ну и плюс не особо понятно, зачем тут вообще Map? У мапы совершенно другое применение. Вы видимо неверное вычитали смысл этой библиотеки. Спорить с тем, что я мог плохо это объяснить в статье не буду, так скорее всего и есть
Нет, не все принимает на вход Map. Exposed - это вообще либа для SQL. Джавовские файлы тоже не принимают на вход Map. Jetpack DataStore не принимает на вход мама, к тому же там вообще флоу.
Крэйты для всех этих библиотек позволяют сделать единый унифицированный при, в котором не будет этих зависимостей. Крэйты убирают из кода полностью зависимость от конкретных библиотек.
На примере рассмотрим. Допустим, раньше хранили данные пользователя в SharedPreferences в жосне. Данные стали слишком большими, префоф стало недостаточно. Как хорошо что у нас были Крэйты. Мы теперь будем хранить данные пользователя локально в файле, а верхнеуровневый при останется такой же каким был. То же самое и с датастором и SQL
В этом и задумка. У каждого кейсы разные.
Кто-то в файле хочет хранить, кто-то в MultiplatformSettings, кто-то в DataStore. А написать код, который это выполняет, можно очень по-разному
Не совсем понял, при чем тут NoSql. Но окей. Допустим, вы используете одну либу для NoSql. У нее одна реализация для Map. Кто-то захотел другую либу для NoSql взять. Там уже другая обёртка. А вам нужно хранить одинаковый тип данных. С Крейтами вы просто оборачивание это в крейт и у вас код, где использовались Крэйты раньше, никак не меняется. Как и писал, это нужно для увеличения уровня абстракции.
Речь конечно не конкретно про NoSql. Тут именно подход для Key-Value хранения. В андроиднвх библиотеках, вроде как и у всех, абстракции разные. А Крэйты просто унифицируют этот доступ
Обновленная статья
https://habr.com/ru/articles/910392/