Дескриптор настроек можно получить двумя способами

Дескриптор настроек можно получить двумя способами

• Проще всего поступить так, как продемонстрировано в нашем примере, т.е. вызвать PreferenceManager.getDefaultSharedPreferences(this). Аргумент this представляет собой контекст для поиска стандартных разделяемых настроек, а имя пакета для this будет использовано для определения имени и местоположения файла настроек — это файл, созданный активностью PreferenceActivity, т.к. они разделяют одно и то же имя пакета.

• Получить дескриптор для файла настроек можно и с помощью вызова метода getSharedPreferences() , передав ему в качестве аргументов имя файла и режим. В е 13.2 этот вариант тоже показан, но он закомментирован. Учтите, что нужно указать только базовое имя файла, но не путь и не расширение имени файла. Режим управляет правами доступа к XML-файлу настроек. В приведенном выше примере аргумент режима не влияет ни на что, т.к. создается внутри активности PreferenceActivity, которая устанавливает стандартные права MODE_PRIVATE (т.е. ноль). Аргумент режима будет описан ниже, в разделе, посвященном сохранению состояния.

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

В методе setOptionText() с помощью ссылки на настройки вызываются соответствующие методы для получения значений настроек. В нашем примере вызывается метод getString() , поскольку известно, что из настроек должно извлекаться строковое значение. Первый аргумент — строковое значение ключа параметра. Выше уже упоминалось, что использование идентификатора гарантирует отсутствие опечаток при создании приложения. В качестве первого аргумента можно было просто указать строку selected_flight_sort_option, но тогда вы должны позаботиться о том, чтобы эта строка была в точности такой же, как и в остальных частях кода, где используется значение ключа. Во втором аргументе указывается значение по умолчанию, на случай, если первый аргумент не будет найден в XML-файле настроек. При самом первом запуске приложения XML-файла настроек еще нет, и без значения во втором аргументе будет возвращено null. Так будет даже если указать значение по умолчанию для параметра в спецификации ListPreference в flightoptions.xml. В нашем примере значение по умолчанию устанавливается в XML, и для этого задействуется идентификатор ресурса, поэтому код в setOptionText() можно использовать для чтения значения идентификатора ресурса, соответствующего значению по умолчанию. Без использования идентификатора прочитать значение по умолчанию непосредственно из ListPreference было бы гораздо сложнее. Совместное использование идентификатора ресурса в XML и коде позволяет получить только одно место, в котором следует изменять значение по умолчанию — файл strings.xml.

Кроме значения настройки, нужно отображать и пояснительный текст для этой настройки. В нашем примере используется упрощение: определение значений flight_ sort_options_values на основе индексов массива. Простое преобразование значения в тип int позволяет определить, какую строку необходимо прочитать из flight_sort_ options. При использовании другого набора значений в flight_sort_options_values нам пришлось бы определять индекс элемента для настройки и использовать этот индекс для выборки пояснительного текста из flight_sort_options.

Поделиться в соц. сетях

Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс

Добавить комментарий