Comments 13
Порог входа в андройд разработку неуклонно растет. Теперь что бы просто пользоваться Preferences уже нужно знать корутины.
0
Ну корутины знать в целом нужно. Либо RX Java, что еще труднее. Ибо сейчас почти нет приложений в которых бы кто-то писал на хендлерах и т.п. Ну и корутины это часть Kotlin SDK по сути. Так что да.
+1
Да, конечно, я сам очень рад, что андройд разработка становится современной, код с использованием подобных инструментов более выразительным. Но новичку это все постичь все больше непросто.
0
DataStore идеально подходит для небольших простых наборов данных и не поддерживает частичные обновления или ссылочную целостность.
Ради чего тогда весь сыр-бор?
+2
А Preference Screens теперь предлагается руками рисовать? C Shared Preferences можно просто xml-ку скормить PreferenceFragmentCompat-у и всё.
+1
Так это же самая первая альфа (на самом деле уже вторая вышла), к релизу может и подтянут обертку для экранов
+1
Есть большие сомнения на этот счёт. «Обертка для экранов» по сложности больше самого механизма хранения. И никакой информации о том, что эта фича в разработке, нет.
Я к тому, что Гугл как всегда лукавит — взяли хранение настроек, нашли там недостатки, и полностью проигнорировали вопросы взаимодействия пользователя с этими настройками. Просто key-value хранилищ и без гугла хватало — тот же SnappyDB или Hawk.
Я к тому, что Гугл как всегда лукавит — взяли хранение настроек, нашли там недостатки, и полностью проигнорировали вопросы взаимодействия пользователя с этими настройками. Просто key-value хранилищ и без гугла хватало — тот же SnappyDB или Hawk.
0
Хм…
А как же: EncryptedSharedPreferences?
Мне кажется что данный подход требует от нас слишком много тело движений и кучу реализаций пусть и маленьких на первый взгляд.
Ведь я могу взять: EncryptedSharedPreferences, сохранить в нём Json объект в виде строки. Зашифровать и сохранить. А потом точно так же доставать наружу. Вроде проще, нет?
Preferences DataStore — хранит данные по принципу «ключ — значение» и не предоставляет нам никакой типобезопасности.
А как же: EncryptedSharedPreferences?
Proto DataStore — хранит данные в объектах. Это дает нам типобезопасноть, но описывать схему нужно с помощью protocol buffers.
Мне кажется что данный подход требует от нас слишком много тело движений и кучу реализаций пусть и маленьких на первый взгляд.
Ведь я могу взять: EncryptedSharedPreferences, сохранить в нём Json объект в виде строки. Зашифровать и сохранить. А потом точно так же доставать наружу. Вроде проще, нет?
0
EncryptedSharedPreferences работает аналогично SharedPreferences в части интерфейсов чтения/записи, отличие в том что дополнительно сами поля в хранимом XML будут зашифрованы. А так если нужен любой тип, кроме примитива или массива примитивов — самостоятельно сериализуйте, типобезопасности из коробки нет.
0
Спасибо за обзор! Полезно было почитать
Заметил несколько неточностей:
это не совсем так, apply тоже работает асинхронно
может только при записи?
Заметил несколько неточностей:
В отличие от SharedPreference, DataStore работает асинхронно.
это не совсем так, apply тоже работает асинхронно
DataStore предоставляет асинхронный API для записи и чтения данных, в отличие от Shared Preference, который предоставляет асинхронный API только при чтении данных.
может только при записи?
0
Про apply я в целом упомянул.
Про «может только при записи?». — у вас же для чтения есть интерфейс который отдает на чтение Flow. Посмотрите в самом вверху статьи;)
Про «может только при записи?». — у вас же для чтения есть интерфейс который отдает на чтение Flow. Посмотрите в самом вверху статьи;)
0
Sign up to leave a comment.
Обзор DataStore Library. Прощаемся с SharedPreference?