Я ищу, чтобы написать настройки, которые могут быть применены к устройствам 3.0 и pre-3.0. Обнаружив, что PreferenceActivity
содержит устаревшие методы (хотя они используются в прилагаемом примере кода), я посмотрел PreferenceFragement
и пакет совместимости, чтобы решить мои проблемы.
Похоже, что этого PreferenceFragment
нет в пакете совместимости. Кто-нибудь может сказать мне, было ли это преднамеренным? Если да, могу ли я легко настроить таргетинг на ряд устройств (то есть <3.0 и> = 3.0) или мне придется прыгать через обручи? Если это не было преднамеренно исключено, можем ли мы ожидать новый выпуск пакета совместимости? Или есть другой обходной путь, который безопасно использовать?
ура
Джеймс
PreferenceFragment
которое вы забудете даже там. Смотри мой ответ ."Because most of Preferences' implementation is hidden, therefore impossible to backport without lots of hackery."
PreferenceFragmentCompat
недавно был добавлен в библиотеку поддержки.Ответы:
Устаревшие методы устарели с Android 3.0. Они прекрасно работают на всех версиях Android, но нацелены на использование
PreferenceFragment
Android 3.0 и выше.Я думаю, это вопрос инженерного времени, но это всего лишь предположение.
Я считаю, что это сделать "легко". Имеют две отдельные
PreferenceActivity
реализации, одна с использованием заголовков предпочтений, аPreferenceFragments
другая с использованием оригинального подхода. Выберите правильный в нужной точке (например, когда пользователь нажимает на пункт меню параметров). Вот пример проекта, демонстрирующего это. Или есть один,PreferenceActivity
который обрабатывает оба случая, как в этом примере проекта .Вы узнаете, когда остальные из нас узнают, то есть, если и когда это отправит.
Смотри выше.
источник
<include>
работает с предпочтением XML. Кстати, если вы подписчик, об обновлении книги, касающемся этого проекта, было объявлено несколько минут назад.Тонкий смысл ответа от @CommonsWare заключается в том, что - ваше приложение должно выбирать между API совместимости или встроенным API фрагментов (начиная с SDK 11 или около того). Фактически это то, что сделала «легкая» рекомендация. Другими словами, если вы хотите использовать PreferenceFragment, ваше приложение должно использовать встроенный API-фрагмент и работать с устаревшими методами в PreferenceActivity. И наоборот, если важно, чтобы ваше приложение использовало компат. API вы столкнетесь с отсутствием класса PreferenceFragment вообще. Таким образом, нацеливание на устройства не является проблемой, но скачкообразное изменение происходит, когда вам нужно выбрать один или другой API и, таким образом, представить свой дизайн непредвиденным обходным путям. Мне нужен компат. API, поэтому я собираюсь создать свой собственный класс PreferenceFragment и посмотреть, как это работает. В худшем случае я
РЕДАКТИРОВАТЬ: после попытки и просмотра кода на http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/preference/PreferenceFragment.java? av = h - создание собственного PreferenceFragment не произойдет. Похоже, что в PreferenceManager либеральное использование package-private вместо «protected» является основным блокирующим фактором. Это действительно не похоже на то, что есть какая-то безопасность или действительно хорошая мотивация, чтобы сделать это, и это не очень хорошо для юнит-тестирования, ну да ладно ... меньше печатать, я думаю ...
РЕДАКТИРОВАТЬ v2: На самом деле это произошло, и это сработало. Определенно было головной болью заставить код работать с JAR API совместимости. Мне пришлось скопировать около 70% пакета com.android.preference из SDK в мое приложение, а затем бороться с типично посредственным Java-кодом в Android. Я использовал v14 SDK. Для инженера Goog было бы намного проще сделать то, что я сделал, вопреки тому, что я слышал от ведущих разработчиков Android по этой теме.
Кстати, я говорил "нацеливание на устройства - это не проблема"? Это полностью ... если вы используете com.android.preference, вы не сможете обменяться с API совместимости без серьезного рефакторинга. Веселый журнал!
источник
Основываясь на ответе CommonsWare, а также на наблюдениях Tenacious, я придумал единственное решение класса-потомка, способное нацеливаться на все текущие версии Android API с минимальными усилиями и без дублирования кода или ресурсов. Пожалуйста, смотрите мой ответ на связанный вопрос здесь: PreferenceActivity для Android 4.0 и более ранних версий
или в моем блоге: http://www.blackmoonit.com/2012/07/all_api_prefsactivity/
Протестировано на двух планшетах под управлением 4.0.3 и 4.0.4, а также на телефоне под управлением 4.0.4 и 2.3.3, а также на эмуляторе под управлением 1.6.
источник
Смотрите PreferenceFragment-Compat от Machinarius. Было легко заскочить с Gradle, и я забыл, что это даже там.
compile 'com.github.machinarius:preferencefragment:0.1.1'
Важное обновление: последняя редакция из
v7 support library
теперь имеет нативный PreferenceFragmentCompat .источник
В августе 2015 года Google выпустила новую библиотеку поддержки предпочтений v7 .
Теперь вы можете использовать PreferenceFragmentCompat с любым
Activity
илиAppCompatActivity
Вы должны установить
preferenceTheme
в своей теме:Таким образом, вы можете настроить
preferenceTheme
стиль макетов, используемых для каждого типа предпочтений, не затрагивая другие части вашей деятельности.источник
Ответ Tenacious правильный, но вот еще несколько деталей.
Причина, по которой вы не можете «создать нормальный макет и связать компоненты вида с sharedprefs вручную», состоит в том, что в API android.preferences есть некоторые неожиданные упущения. PreferenceActivity и PreferenceFragment оба имеют доступ к критическим непубличным методам PreferenceManager, без которых вы не сможете реализовать собственный интерфейс предпочтений.
В частности, для построения иерархии предпочтений из XML-файла вам необходимо использовать PreferenceManager, но все конструкторы PreferenceManager являются либо закрытыми, либо скрытыми. Метод присоединения слушателей Preference onClick к вашей активности также является закрытым для пакета.
И вы не можете обойти эту проблему, украдкой поместив свою реализацию в пакет android.preferences, потому что непубличные методы в API-интерфейсах Android фактически исключены из SDK. Приложив немного креативности, включая рефлексию и динамические прокси, вы все равно можете их получить. Единственная альтернатива, как утверждает Tenacious, - это разветвить весь пакет android.preference, включая не менее 15 классов, 5 макетов и аналогичное количество элементов style.xml и attrs.xml.
Таким образом, чтобы ответить на исходный вопрос, причина, по которой Google не включил PreferenceFragment в пакет совместимости, заключается в том, что у них была бы точно такая же сложность, что и у Tenacious и у меня. Даже Google не может вернуться назад во времени и опубликовать эти методы на старых платформах (хотя я надеюсь, что они сделают это в будущих выпусках).
источник
Моя цель приложения - API +14, но из-за использования библиотеки поддержки для некоторой необычной навигации я не мог использовать
android.app.Fragment
и должен был использоватьandroid.support.v4.app.Fragment
, но мне также нужно было иметьPreferenceFragment
место без больших изменений в коде позади.Итак, мое простое исправление - иметь как библиотеки поддержки мира, так и
PreferenceFragment
:источник
Мне нужно было интегрировать настройки в дизайн приложения и поддерживать 2.3 Android. Поэтому мне все еще нужен был PreferencesFragment.
После некоторого поиска я нашел android-support-v4-preferencefragment lib. Эта библиотека экономит много времени на копирование и рефакторинг оригинального PreferencesFragment, как сказал Tenacious. Работает нормально и пользователи наслаждаются настройками.
источник