Первая версия Multiplatform Settings была выпущена в мае 2018 года. Тогда я предполагал, что оставлю ее в виде пререлиза 0.x до тех пор, пока Kotlin/Native и Kotlin Multiplatform не станут полностью стабильными. Но прошло уже более четырех лет, и множество других библиотек в экосистеме перешли на версию 1.0. Поскольку бета-версия Kotlin Multiplatform Mobile уже не за горами, я решил, что настало время выпустить стабильный релиз для Multiplatform Settings.

В рамках подготовки к этому я недавно выпустил версию 1.0.0-alpha01. Она включает в себя ряд изменений, чтобы сделать API более последовательным и интуитивно понятным. Я сделал все возможное, чтобы предоставить помощь в миграции в виде аннотаций @Deprecated, которые в большинстве случаев позволят пользователям обновляться автоматически. Но если по какой-то причине вы не готовы это сделать, недавно была выпущена версия 0.9 с почти такой же функциональностью и без поломок.

Если вы никогда не слышали о Multiplatform Settings или хотите взглянуть на нее поближе, обязательно ознакомьтесь с ней на Github!

repositories {
    mavenCentral()
    // ...
}

commonMain {
    dependencies {
        // ...
        implementation("com.russhwolf:multiplatform-settings:0.9")
    }
}

Внесение изменений

Вот краткий обзор изменений и других обновлений, чтобы вы знали, чего ожидать.

Переименование классов реализации

В ранние дни, как правило, существовала одна реализация класса Settings для каждой платформы, поэтому я давал им такие имена, как AndroidSettings, AppleSettings и JsSettings. Эта схема именования не смогла удержаться, так как были добавлены такие реализации, как KeychainSettings и DataStoreSettings. Для обеспечения последовательности, в версии 1.0 все названия, основанные на платформе, будут изменены, чтобы обозначить базовый API, который использует реализация. Полный список переименований приведен ниже.

Обновление изменений слушателя

Первоначальный интерфейс ObservableSettings был основан на нетипизированной функции addListener(), при этом потребитель отвечал за считывание текущего значения наблюдаемого ключа при вызове слушателя. Это было неудобно в использовании, поэтому позже были добавлены типизированные функции расширения, такие как addIntListener(), чтобы делать эту работу за вас, но основной API остался. Однако я не вижу особого смысла в использовании нетипизированного API, и это усложняет преобразование между ObservableSettings и FlowSettings, которое включает только типизированные API. Поэтому в версии 1.0 нетипизированный addListener() будет удален, а функции расширения перенесены в интерфейс ObserableSettings.

Если вы поддерживаете пользовательскую реализацию ObservableSettings, миграция, надеюсь, не будет слишком плохой, потому что вы можете оставить ваш нетипизированный addListener() в качестве детали внутренней реализации и просто вызывать его из типизированных методов. Так же сейчас поступает большинство библиотечных классов.

Значения по умолчанию

Если вернуться к самому первому выпуску библиотеки, то во многих местах API Multiplatform Settings API принимает параметр defaultValue, который возвращается, если ключ отсутствует. Эти параметры defaultValue почти всегда имеют значения параметров по умолчанию, поэтому вы можете вызвать settings.getInt("key"), который сделает то же самое, что и settings.getInt("key", defaultValue = 0). Совсем недавно были добавлены геттеры с нулевым значением, так что вы можете делать такие вещи, как settings.getIntOrNull("key"), которые вернут null, если "key" не установлен. Это делает API немного запутанным, когда вы можете удивиться, что getInt("key") возвращает 0 вместо null, поэтому я решил убрать значение параметра по умолчанию из геттеров, не имеющих значения null. Это немного более многословно в случае, если вам нужны значения по умолчанию библиотеки, но я думаю, что так будет меньше сюрпризов.

Удаление multiplatform-settings-coroutines-native-mt

Когда я впервые опубликовал API взаимодействия с coroutines, я создал два отдельных модуля в попытке удовлетворить потребности людей, использующих как mainline, так и native-mt версии coroutines. Поскольку новая модель памяти Kotlin/Native уже не за горами, и я понимаю, что ветка native-mt в kotlinx-coroutines больше не будет поддерживаться, я удалил модуль multiplatform-settings-coroutines-native-mt в 1.0.0-alpha01. Если вы использовали его, вам следует перейти на multiplatform-settings-coroutines вместо него.

Удаление экспериментальных маркеров

Некоторые, но не все, вещи, которые ранее были помечены как @ExperimentalSettingsApi или @ExperimentalSettingsImplementation, больше не аннотируются, чтобы указать, что они будут стабильными в версии 1.0. Это включает интерфейсы ObservableSettings и SettingsListener, а также реализации PreferencesSettings и PropertiesSettings.

Некоторые элементы остаются экспериментальными в версии 1.0, чтобы показать, что они еще недостаточно хорошо протестированы, или чтобы предусмотреть возможность внесения изменений в будущем. К ним относятся API взаимодействия с корутинами и сериализацией, а также RegistrySettings на Windows и KeychainSettings на платформах Apple. Я очень хочу получить больше отзывов обо всех этих вещах, чтобы они тоже стали стабильными, поэтому, пожалуйста, дайте мне знать, что у вас работает хорошо, а что нет.

Дальнейший путь

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

Интеграция корутинов

Для API multiplatform-settings-coroutines я хочу знать, полезно ли введение SuspendSettings и FlowSettings. Я немного беспокоюсь, что это много API для одной реализации (DataStoreSettings), но альтернативой является обертывание множества runBlocking, что кажется еще хуже. Мне нравится текущее положение вещей, когда вы можете использовать некорутинные интерфейсы с внутренней runBlocking, если хотите, вызывая toBlockingSettings() или toBlockingObservableSettings(), потому что это делает блокировку явной и опциональной. Но я хотел бы услышать, работает ли это и для вас. Вы можете оставить отзыв в этой теме

Интеграция сериализации

Для API multiplatform-settings-serialization я хочу знать, находят ли люди эту интеграцию полезной. Я уже получил несколько хороших отзывов о добавлении аналогов remove() и contains() для сериализуемых значений, и уже открыт PR, который служит доказательством концепции. Я был бы рад услышать отзывы по этому PR или по связанному с ним вопросу. Я также хотел бы узнать, чего еще не хватает в этих API. Вы можете оставить отзыв в этом выпуске

Интеграция с Apple Keychain

Реализация KeychainSettings является экспериментальной, поскольку она еще не прошла серьезных испытаний. Если вы пробовали ее, пожалуйста, дайте мне знать, удовлетворяет ли она вашим требованиям безопасности. Если вы или кто-то из ваших знакомых хорошо разбирается в API связки ключей, я был бы рад получить отзыв о том, делает ли эта реализация все, что нужно, с точки зрения безопасности. Вы можете оставить любой из этих отзывов в соответствующем вопросе

Реализация для Windows

Реализация RegistrySettings на Windows является экспериментальной в основном потому, что я хочу добавить поддержку ObservableSettings, и я хочу оставить возможность внесения изменений, пока это не будет сделано. Если у вас есть идеи по этому поводу или вы хотите помочь, дайте мне знать в соответствующем вопросе

Реализация в Linux

На данный момент не существует реализации Settings для настольного Linux. Я создавал различные прототипы в течение многих лет, но это не среда разработки, в которой я провожу много времени, поэтому у меня нет понимания того, что полезно. Вы можете увидеть некоторые из вещей, которые я пробовал, в PR, связанных с этим вопросом. Для меня наиболее важен отзыв о том, какой backing API будет наиболее полезен с точки зрения взаимодействия, если у вас есть общий и специфичный для платформы код. Это не обязательно должен быть один из тех, которые я уже опробовал.

Что дальше для 1.0?

Хорошо, это было много текста. Спасибо, что остаетесь со мной, пока я рассказываю о состоянии библиотеки и дорожной карте до 1.0 и далее.

Я думаю, что хотел бы нацелить финальный релиз 1.0 примерно на сроки выхода Kotlin 1.8, что будет где-то этой осенью. Поэтому я хотел бы услышать, что люди думают об этих изменениях и о библиотеке в целом. Если есть что-то еще, что, по вашему мнению, должно быть изменено, пока библиотека находится на стадии pre-1.0, сейчас самое время дать мне знать!