#android
#Android
Вопрос:
Прямо сейчас они просто хранятся в классе, называемом Globals
как статические поля. Я не тот, кто создал приложение, но я рассматриваю возможность размещения их в локализованных strings.xml
файлах, таких как <string name="API_URL">http://someurl</string>
. Это хорошая или плохая практика?
ОБНОВЛЕНИЕ: я выбрал ответ, который, по моему мнению, наиболее полно отвечает на вопрос. Но после некоторого переосмысления я все вместе выбрал другое решение. Учитывая, что URL-адреса фактически основаны на стране, для которой должно распространяться приложение, нет смысла переключать их в зависимости от локали, поскольку URL-адреса должны оставаться неизменными независимо от языка на телефоне. Вместо этого я реализовал варианты Gradle, которые создают разные APK-файлы на основе разных настроек и тому подобного. Это позволяет вам создавать варианты одного и того же приложения с небольшими изменениями, которые вам нужны. 🙂 Итак, теперь у меня есть URL-адреса в файле, специфичном для конкретного варианта.
Спасибо всем, кто нашел время прокомментировать и помочь мне.
Комментарии:
1. Это хорошо, вы также можете создать базовый класс для того же.
2. В каком сценарии URL-адрес будет зависеть от локали?
3. я не рекомендую это, потому что, если вам позже понадобится изменить URL-адрес, вам нужно будет изменить всю строку в каждой папке values localized. Лучше иметь общую базовую строку URL в качестве статического поля и создавать локализованные во время выполнения, используя выделенный метод / класс
4. @TimCastelijns, ну, я не совсем понимаю причину, но разработчики серверной части решили, что лучше всего использовать совершенно разные URL-адреса для каждого языка. Я не понял причину достаточно, чтобы быть в состоянии объяснить это, но я понял это достаточно, чтобы признать это 🙂 таким образом, разные URL-адреса будут возвращать данные, необходимые для каждого языка. Поскольку решение принимаю не я, заставить его работать — это просто моя работа.
5. @MatPag В любом случае это будет уникально для каждого языка, поэтому независимо от того, как я на это смотрю, это не проблема. Хотя, что касается вашего предложения, что вы подразумеваете под «сборкой локализованных во время выполнения»? Как именно я мог это сделать? Пусть мой класс проверяет локаль и присваивает соответствующее значение? Переменные прямо сейчас являются статическими константами, поэтому, я думаю, мне придется переписать класс, чтобы это произошло.
Ответ №1:
Я согласен с puneet, это ни хорошо, ни плохо. Это зависит от того, что вы делаете с URL-адресами API.
Собираетесь ли вы добавить их позже с помощью пользовательского ввода? Если это так, я бы посоветовал вам сохранить их в качестве глобальных переменных, чтобы вы могли программно изменять URL-адрес API по мере необходимости.
Если URL-адрес API является полным и его не нужно добавлять, то поместите их в strings.xml было бы хорошо. Просто помните, что вам все равно придется создать локальную строковую переменную в Java для хранения текста из API_URL в string.xml , что кажется неэффективным, если вы стремитесь писать меньше кода.
Комментарии:
1. Если это, если то. Лучше обратитесь к OP за разъяснениями и основывайте свой ответ на этом, а не на догадках
2. Тим, вот почему я дал варианты и описания для обоих ответов, которые я предоставил. Чтобы позволить OP решить, какой из них подходит. И пока OP не решит предоставить нам больше информации, угадывание их намерений — это все, что доступно.
3. Прямо сейчас весь URL-адрес объединяется с помощью
String.format()
вызова… Таким образом, все необходимые данные, включая базовый URL, объединяются этой функцией… итак, на мой взгляд, не имеет значения, происходит ли это из строкового файла или глобального класса. Я могу ошибаться, хотя 🙂 Я все еще новичок в разработке Android.4. Никки, в используемом вами String.format() есть ли какие-либо входные данные от пользователя, добавленные к URL-адресу API? Под вводом я подразумеваю текст из edittext, параметры из меню фильтра или какой-либо другой пользовательский ввод, который помогает уточнить вызов URL-адреса API?
5. @OvidioReyna, иногда, да.
Ответ №2:
Ни хорошо, ни плохо.Если вас беспокоит безопасность, то ни один из них не обеспечивает безопасность, поскольку возможна декомпиляция.
Комментарии:
1. Почему это ни хорошо, ни плохо? Безопасность не упоминалась, поэтому нет смысла основывать ответ на этом
2. Безопасность в (предполагаемом) простом контексте это то же самое, после открытия APK нетрудно найти строковый ресурс или статический конечный URL…