Хранение настроек (preferences)

Приложение, которое каждый раз начинает с нуля, злит тихо, но надёжно: пользователь второй раз выбирает ту же тему, второй раз вводит имя, второй раз двигает громкость. Причина проста — все значения жили в памяти: источники семнадцатого урока умирают с процессом, и на диск не попадает ничего. Fyne решает это встроенным хранилищем: у каждого приложения есть fyne.Preferences, доступный как myApp.Preferences(). Запрос «fyne preferences» — это интерфейс с четырьмя парами для базовых типов: SetString(key, value) и String(key), SetBool(key, v) и Bool(key), SetFloat(key, v) и Float(key), SetInt(key, v) и Int(key). Плюс RemoveValue(key), который стирает ключ — на следующий запуск его будто никогда и не было. Хранилище ключ-значение: ключ — строка, значение — один из четырёх типов; никаких списков и структур, сложное сериализуй сам — об этом в разделе про практику. Главная ценность в том, что запись и чтение выглядят как работа со словарём, а сохранение на диск Fyne делает сам: ни путей, ни файлов, ни форматов. Русский запрос «fyne настройки» приводит в то же место. Вторая ценность — предсказуемость чтения: пустое хранилище возвращает пустые значения без ошибок и паник, а для честных значений по умолчанию есть семейство WithFallback, которое сейчас покажем в коде. Осталось собрать первый пример: приветствие, которое помнит имя.

Семейство WithFallback — главный инструмент загрузки при старте: StringWithFallback(key, fallback) вернёт сохранённое значение, а если его нет — запасное. Аналогично устроены BoolWithFallback(key, def), FloatWithFallback(key, def) и IntWithFallback(key, def). Семантика строгая: запасное значение подставляется только при отсутствии ключа; записанный false или ноль вернутся как есть. Отсюда правило выбора: для значений, где пустота и ноль — легитимное состояние, обычных String и Bool достаточно; для значений, где нужна разумная стартовая точка — громкость 0.5, тема «тёмная», язык «ru» — бери WithFallback и не пиши if-ы. Ключи именуй как пути в конфиге: «user.name», «theme.dark», «audio.volume» — группировка по префиксу спасает, когда ключей становится пара десятков; строковые константы для ключей собери в одном месте и не повторяй литералы по коду. Четыре типа — целые, дробные, булевы и строки — покрывают настройки как класс, но не данные: список задач или структуру профиля в preferences не положишь. Сериализуй в JSON-строку и храни её одним ключом — приемлемо для небольших блобов; всё, что больше пары килобайт, — территория файлов и хранилища приложения, это двадцать первый урок. И помни объём: preferences — про десятки мелких значений, читаемых быстро, а не про базу данных.

Настройки пишутся в JSON-файл в каталоге пользователя, и путь определяется идентификатором приложения. Поэтому каркас начинается с app.NewWithID("io.gomaster.notepad") — по convention идентификатор пишется в обратном доменном стиле, как пакет для сторов. Если создать приложение через app.New() без идентификатора, Fyne выдаст ему случайный на каждый запуск: значения будут работать в памяти, но файл настроек каждый раз окажется новым, и всё написанное утонет. Это самый частый вопрос новичков — «почему настройки не сохраняются» — и самый частый ответ: добавь идентификатор. Каталог зависит от платформы и берётся из правил системы: на Linux это внутри ~/.config, на macOS — в ~/Library/Application Support, на Windows — в %AppData%; точное место подскажет метод StoragePath() хранилища. Внутри лежит preferences.json с твоими ключами — можно открыть и посмотреть, что именно сохранено, полезно при отладке. Запись на диск не мгновенная: Fyne копит изменения и сбрасывает файл с небольшой задержкой, поэтому не рассчитывай прочитать файл в ту же миллисекунду после Set — работай через API хранилища. На мобильных платформах из двадцать второго урока идентификатор обязателен вдвойне: там он становится именем пакета в сторе, а настройки живут в изолированном каталоге приложения. Один идентификатор — один набор настроек: смена ID обнулит видимые значения, это удобный способ получить «чистый профиль» для теста.

Хранилище умеет то же, что источники семнадцатого урока, — сообщать об изменениях. AddChangeListener(func()) вешает колбэк, который вызывается, когда значения меняются; RemoveChangeListener(listener) снимает подписку. Сигнатура обманчиво пустая — func() без аргументов: хранилище не говорит, какой именно ключ изменился, оно сообщает факт перемены. Что делать колбэку? Перечитать интересующие ключи и обновить интерфейс — дешёвые чтения из памяти, так что перечитать можно хоть всё. Такой слушатель — удобное место для глобальных реакций: тема сменилась — перекрась самописные примитивы из седьмого урока, ведь виджеты перекрасятся сами, а canvas-примитивы хранят цвет значением и требуют Refresh. Порядок и группировка не гарантированы: несколько быстрых Set могут прийти одним уведомлением или двумя — не строй логику на счёте вызовов, перечитывай состояние целиком. Правила жизни те же, что у DataListener: снимаешь ненужного, не создаёшь циклов — колбэк, который сам пишет в хранилище, обязан избегать бесконечной эхо-петли: изменяй условно или проверяй, что значение реально поменялось, прежде чем писать ответ. На живом примере видно, как одна кнопка меняет булев ключ, а слушатель перерисовывает подпись — интерфейс и данные снова не встретились напрямую.

Семнадцатый урок оставил мост недостроенным — пора достроить. binding.BindPreferenceString(key, prefs) создаёт источник, живущий прямо в хранилище: Get читает ключ preferences, Set пишет в него же. Дальше всё знакомо: Entry.Bind(source) — и поле из девятого урока двусторонне связано с хранилищем; печать пользователя сохраняет значение, а загрузка при старте происходит сама, ведь источник читает ключ уже при подключении. Аналогично работают BindPreferenceBool для Check, BindPreferenceFloat для Slider и BindPreferenceInt. Получается самый короткий путь к экрану настроек: один Bind заменяет и поле ввода с обработчиком, и чтение при старте, и запись при изменении. Когда что выбирать? Прямые String и WithFallback удобны, когда значение читается в нескольких местах и записывается по событию — приветствие из первого примера; привязка удобна, когда значение — собственность одного контрола: имя пользователя в поле, громкость в слайдере, тема в галочке. Осторожность одна: привязка пишет на каждую правку поля, а не по кнопке «Сохранить» — для настроек это обычно и нужно, но если требуется явное подтверждение, оставь обычный источник семнадцатого урока и пиши в preferences по OnSubmit формы из восемнадцатого. Мост между уроками работает в обе стороны: проверка гарантирует, что в хранилище не попадёт мусор, а хранилище делает привязки персистентными без единой новой строки кода.

Соберём короткий список того, что в реальных приложениях живёт в настройках. Выбор темы: галочка тёмного режима из примера выше читается при старте до построения интерфейса, и тема из пятнадцатого урока применяется сразу — обещание того урока исполнено; меняется — слушатель перекрашивает остатки. Черновики: текст редактора в String по таймеру или OnChanged — пользователь перезапустил приложение и нашёл текст на месте; для больших текстов — файл. Флаги «больше не показывать» и «первый запуск»: Bool-ключ превращает онбординг в одноразовый, а итоговый счётчик запусков удобно показать в ShowInformation из тринадцатого урока. Счётчики: число запусков из предсказания, номер последней открытой вкладки, геометрия окна — размеры и позицию Fyne сам не помнит, два Int-ключа решают дело. Что НЕ стоит: всё, что изменяется часто и требует истории — журнал действий; всё, что должно жить на сервере и путешествовать между машинами — preferences локальны по определению; всё, что пользователь не выбирал сам, — кеш не настройка. Проверь связку при старте: читать настройки лучше до ShowAndRun из второго урока, чтобы первый кадр уже отражал сохранённое состояние, — мигание «дефолт, потом тёмная тема» выглядит как баг, даже если это просто порядок инициализации.

Теперь приложение помнит пользователя: значения переживают перезапуск, тема возвращается, экран настроек собран из трёх привязок без обработчиков. Опора урока — второй с каркасом запуска и идентификатором, семнадцатый с источниками и Bind, восемнадцатый с проверкой значений на входе, пятнадцатый с темой, выбор которой теперь сохраняется. Следующая тема — многопоточность в GUI: что случится, если Set из семнадцатого урока позвать из горутины, почему интерфейс трогать можно только из главного потока и как fyne.Do делает bridges безопасными. Домашнее задание соберёт экран настроек, который переживает перезапуск целиком. Полный маршрут — на странице курса Fyne.