Рекомендации по предложенному делегату:
1. preferences.edit() можно создать один раз и хранить ссылку в классе.
2. apply() желательно вызывать отдельно, так как если будет много вызовов setValue(), то на каждый apply() будет отдельное сохранение в файл. Общий Editor может частично решить эту проблему.
3. В preferences для каждого значения сохраняется также и его тип. Можно предусмотреть прозрачную. конвертацию. Иначе, возможны конфликты, например, Integer <-> Long.
Текущая реализация SharedPreferences очень плохая.
Из проблем:
1. Загрузка данных из файла может происходить в UI потоке при создании инстанса SharedPreferences. В новых версиях SDK это уже вроде как починили.
2. apply() добавляет таску сохранения в очередь, которая общая для всех Preferences. И самое печальное, что пока эта очередь не обработана, активити залипает при закрытии. Для чего это сделано — непонятно. Уж лучше commit() в бэкграунде.
3. Каждый экземпляр SharedPreferences работает со своей копией данных. Надо следить, чтобы на каждый файл был один инстанс.
4. На больших данных работает очень медленно.
Проблема в патронах с плохим контактом, из-за которого очень сильно нагревается сам контакт, а потом и вся электронника в цоколе лампы. Сначала высыхают электролитические конденсаторы, начинается мерцание, а потом помирают другие компоненты. Очень часто конденсаторы вздуваются и могут взорваться. Сами светодиоды мрут очень редко, да и только на дешевых китайских лампочках без нормального драйвера.
Помогает замена патронов на новые с подпружиненным контактом фазы и нормальным металическим кольцом для резьбы цоколя. Да и надо обязательно проверять, чтобы фаза в патроне была снизу, а ноль сбоку.
Замечание про Handler. Eсли нет необходимости обрабатывать свои Messages, и надо что-то сделать в UI потоке, то предпочтительней использовать runOnUiThread() или сделать синглтон на базе MainLooper для отвязки от контекста. Если наплодить много Handler-ов и Looper-ов, то можно словить ANR из-за глобального synchronize в методе обработки очереди сообщений. Этой проблеме уже много-много лет.
1. preferences.edit() можно создать один раз и хранить ссылку в классе.
2. apply() желательно вызывать отдельно, так как если будет много вызовов setValue(), то на каждый apply() будет отдельное сохранение в файл. Общий Editor может частично решить эту проблему.
3. В preferences для каждого значения сохраняется также и его тип. Можно предусмотреть прозрачную. конвертацию. Иначе, возможны конфликты, например, Integer <-> Long.
Из проблем:
1. Загрузка данных из файла может происходить в UI потоке при создании инстанса SharedPreferences. В новых версиях SDK это уже вроде как починили.
2. apply() добавляет таску сохранения в очередь, которая общая для всех Preferences. И самое печальное, что пока эта очередь не обработана, активити залипает при закрытии. Для чего это сделано — непонятно. Уж лучше commit() в бэкграунде.
3. Каждый экземпляр SharedPreferences работает со своей копией данных. Надо следить, чтобы на каждый файл был один инстанс.
4. На больших данных работает очень медленно.
Помогает замена патронов на новые с подпружиненным контактом фазы и нормальным металическим кольцом для резьбы цоколя. Да и надо обязательно проверять, чтобы фаза в патроне была снизу, а ноль сбоку.
апокалипсисабсолютный перфекционизм.