Написание для общих предпочтений слишком медленно?

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

Как только пользователь удалит виджет, я удалю эту информацию в общих настройках.

То, что я испытал, состоит в том, что если пользователь помещает, например, 2 виджета, затем удаляет один, затем снова помещает его, делая все эти действия быстро, файл общих предпочтений получает в нем непоследовательные значения. Иногда это работает нормально, но большую часть времени я застрял с неправильными значениями в нем.

Я использую apply (), я пытался с фиксацией, но то же самое происходит.

Значения, хранящиеся в общих предпочтениях, имеют решающее значение для работы системы, без этого виджеты бесполезны, поскольку они подкрепляются информацией из Интернета на основе пользовательской конфигурации, которая написана в настройках.

Переключение на решение базы данных более надежное или любое другое жизнеспособное решение, которое исправит это «состояние гонки»? (Возможно, для моего собственного механизма синхронизации, но, насколько я понял из docs, apply () уже синхронизирован, и чтение / запись должны сначала перейти в ОЗУ, которые должны сделать это быстро, и я не должен испытывать никаких проблем, таких как Это, поскольку пользователь не может физически удалять виджет и размещать новый быстрее, чем 2-3 секунды!)

Попробуйте использовать синхронизированное ключевое слово при работе с самими SharedPreferences . Например, вот метод, который можно использовать при настройке приложения String в SharedPreferences приложения для Android:

public synchronized static void setAppString(Context context, String pref, String val) { SharedPreferences sp = context.getSharedPreferences( APP_PREFS_UNIQUE_ID, Context.MODE_PRIVATE); Editor editor = sp.edit(); editor.putString(pref, val); editor.commit(); } 

Для нескольких / простых пар ключ-значение вам может не потребоваться накладные расходы парадигмы базы данных.