Почему у Android есть собственный способ получить текущую локаль?

Кажется, Java уже предоставляет эту информацию в виде этого метода:

Итак, почему разработчики Android представили другой способ получить локаль? Выделяли ли эти две строки кода разные результаты при одновременном выполнении бок о бок?

Ответы

Ответ 1

Я согласен, что это сбивает с толку, и пока я не нападаю на него, и не защищаю его, я вижу, что он позволяет вам что-то делать.

Пусть начнется с начала.

java.util.Locale.getDefault() определяется временем выполнения java. Это язык телефона/устройства. Это то, что дает такие функции, как DateFormats (стандарт ISO Dateformat, стандартный формат США и т.д.), NumberFormats (запятая или десятичная дробь, группировки из 3 или 4 и т.д.) И CurrenyFormats (выглядит ли это как $или CAD), когда ни один язык не является данный. В этих случаях, вероятно, лучше всего указать Locale на эти типы объектов.

context.getResources().getConfiguration().locale - это локаль, которая зарегистрирована в текущем пакете ресурсов в данном Контексте. Он может включать в себя значение локали, которое будет учитывать весь контент ресурсов для текущей пары контекст/ресурсы. Конфигурация может быть похожа на текущее состояние устройства, которое лучше всего фильтруется для текущих ресурсов. Вам не обязательно указывать какой-либо контент, который изменяется в зависимости от языкового стандарта, но это опция.

Ресурсы используют набор дискриминаторов в настройках, таких как ориентация, ширина экрана, локаль и т.д. Таким образом, в вашем приложении вы можете переопределить текущие ресурсы() с помощью другого, просто изменив конфигурацию локального приложения на другой язык. Например, вы делаете макет для адреса. Вы можете захотеть, чтобы определенные поля изменялись в зависимости от выбранной страны. (Не сказать, что это правильное поведение для такого приложения, но это самое простое, о чем можно подумать прямо сейчас). Если вам нужно просто полагаться на Locale.getDefault(), это сделало бы для некоторого неудобного сброса системных приложений и состояния, когда вы захотите сделать что-то, как я только что описал.

Вам по существу потребуется изменить Locale для всего устройства (это не обязательно безопасно, и это не понравится любому старому пользователю). Даже если мы будем игнорировать проблемы менеджера безопасности, которые будут дублироваться хостом vm; на большинстве устройств существует много состояний, которые кэшируются для кантри-набора. Таким образом, было бы значительное отставание и, вероятно, большая нестабильность при переключении этого значения (если кто-то мог это сделать). Другая альтернатива должна всегда указывать локаль для всего. Вы могли видеть, насколько это раздражает. Таким образом, он находится в Конфигурации контекста.

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

Снова не основывается на факте, так как я не являюсь разработчиком ОС, но в основном основан на анализе преимуществ и недостатков системы. Я думаю, что локаль в конфигурации вполне разумна.