Работа со строковыми ресурсами Android

[Alexnn]

Хорошо бы расширить по теме локализации. Как работать с переводами

[hPak]

Разумно. На днях добавлю, чтобы все было в одном месте, под рукой.

[hPak]

Работа со строковыми списками используется не часто и, когда используется, то уже опытными андроид разработчиками, для которых разобраться в них не составляет труда.
Здесь я перечислил те неточности и избыточность в коде, которые я изо дня в день встречаю при ревью кода тех людей, которые только начинают переходить на Android платформу.

[iago]

ИМХО, всё равно на отдельную статью не тянет. Опытный программер (не обязательно опытный Android-программер) при изучении платформы сразу подсечёт, как дяди в примерах хранят строки, и будет делать точно так же.

[delph]

А по моему не плохая статья. Во первых не все на хабре такие уже и опытные программеры сидят — тут вообще разный контенгент: вся IT сфера можно сказать. Во вторых о вкусах не спорят, но на мой взгляд полезная статья для новичков.

[iago]

И всё же, очень ИМХО, лучше оставить этот удел тем, кто пишет книги и мануалы. А хабр я воспринимаю как журнал — лучше почитать об интересных особенностей той или иной технологии, а не об очевидных и доступных вещах, которые можно при желании за 0.5 мин найти в SDK.

[Mutineer]

Не часто? Да банальнейший же активити настроек скорее всего потребует строковых списков. Так что не такая уж это и «опытная» тема

[hPak]

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

[Mutineer]

Например, напиши как из строкового списка в ресурсах получить i-е значение

[hPak]

Годится. Спасибо за совет.

[maep]

да я не думаю что прям нужен опытный разработчик, чтобы строковые списки использовать.
Вообще, конечно, для статьи скажем прямо — скудны материал. Я ожидал увидеть про многоязычные приложения, мне как раз это сейчас интересно. А тут просто про строки.

[bartwell]

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

[muhanov]

ИМХО, было бы здорово рассказать собственно про класс Resources. В нем вся соль. И последний пример в статье не будет таким оторванным от реальности, если уж для новичков пишете.
А метод Context.getString() добавлен лишь как удобный метод.

[hPak]

С базовыми ресурсами вопросы возникают редко, а копать глубже — это нужно не часто. Подобная статья была бы полезной, но я не возьмусь.

[muhanov]

Тогда зачем пишете int strId = getResources().getIdentifier(«score_correct», «string», getPackageName());
где getResources() как раз и возвращает искомый объект Resources, о котором в статье совсем не сказано.

А Вы лишь пользуетесь частным вариантом вызова из Context.

[hPak]

Если перед разработчиком станет практическая задача: загрузить строку, имя которой сгенерированно динамически, то, использовав приведенной код, он ее решит. Подымать для этого весть объем данных по Resources — это хорошо, но время для этого есть не всегда.

[ara89]

Такими темпами скоро в этот блог начнут писать посты вроде «как создать xml файл в Android проекте»

[Infernal]

> в одном файле храню все строки, которые надо будет переводить, во втором текстовые константы, которые я использую для передачи данных между различными Activity, в третьем храню константы, которые использую для составления запросов к веб серверу.

Зачем последние два пункта хранить в ресурсах? Почему не public final static? Строковые ресурсы все-таки нужны именно для хранения UI-строк, для всего остального вами перечисленного есть константы.

[hPak]

Единое место для редактирования всех данных. Можно использовать константы в разных классах и разных пакетах, а можно использовать 3 отдельных файла в ресурсах. Тут важно, что удобно внутри команды. Для человека со стороны такой способ тоже больших сложностей не составит.
Как вариант, в разных файлах можно хранить отдельно строки для перевода и без перевода, если, к примеру, вы пишите англо-русский словарь.

[Infernal]

Странное решение. Строковые ресурсы — это строковые ресурсы, а константы — это константы, как бы очевидно это не звучало. Назначение у них разное. На строковые ресурсы вы ссылаетесь из кода, layoutов и манифеста, для загрузки ресурсов нужен контекст, строковые ресурсы в конце концов может читать не только программист, а еще и переводчик. Ключи для extras или параметры запросов никому кроме разработчика не нужны, у них никогда не будет другого контекста, их никто кроме программистов никогда не увидит, их значения меняются крайне редко после первого релиза.

[Kalobok]

Я бы еще поинтересовался оверхедом за счет обращения к ресурсам вместо использования констант. Не знаю, насколько он велик, но когда мне нужно часто использовать одну и ту же строку (например, как часть контента в элементах длинного списка), я предпочитаю сделать один запрос к ресурсу и сохранить результат (в том же случае списка — как член адаптера).

[NikitaTratorov]

А как добавить разрыв строки? Абзац?