Получение ресурса string в классах

@asttoxa · Регистрация: 25.10.2016

Студворк — интернет-сервис помощи студентам

Доброе утро товарищи.

Понадобилось получение строк из классов не содержащих context или activity.
Погуглив узнал, что есть 2 способа,
1) передать context/activity через конструктор класса
2) использовать Application так как он виден всегда и везде.

Так как у меня классы мелкие, и контекст там нужен ТОЛЬКО для получения строковых. Я посчитал это излишним пихать контекст и поэтому больше склонился ко 2 способу, тем более что класс, унаследованный от Application, у меня уже есть.
Увидел способ который советуют :
И сразу вспомнилась статья https://habrahabr.ru/company/sebbia/blog/243537/
Где сказано "Никогда не сохраняйте ссылки на activity (view, fragment, service) в статических переменных"
Мне показалось в предложенном способе как раз этот пункт и нарушается. Или нет?
Что думаете уважаемые по этому поводу?

И может есть еще способы получить строковые ресурсы без передачи context через конструктор?

Спасибо.

@ExFau$t · 18.04.2017, 09:52

Сообщение от asttoxa

И может есть еще способы получить строковые ресурсы без передачи context через конструктор?

Передать string в конструктор.

@asttoxa · 18.04.2017, 10:00 **[ТС]**

Тоже проблемно. Там не одна строка.

Проще 1 контекст в конструктор пропихнуть, чем все строки.

@shavuz · 18.04.2017, 10:27

Сообщение от asttoxa

передать context/activity через конструктор класса

- Это мемори лик, с этим надо быть очень осторожным.
лучше не держать контекст а обращаться к нему через гетАктивити, гетКонтекст или гет апликейшн. если нет такой возможности, можно передавать через констрактор интерфейс и через него запрашивать контекст, но тут тоже надо не забыть обнулить интерфейс

@ExFau$t · 18.04.2017, 10:34

Ты переписываешь конструктор на приём стринга, получаешь этот стринг в активити до вызова этого конструктора и передаёшь туда какие хочешь строки, и не паришься с контекстом.

@ILNAR_93 · 18.04.2017, 11:01

Сообщение от shavuz

- Это мемори лик, с этим надо быть очень осторожным.

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

@shavuz · 18.04.2017, 11:36

Сообщение от ILNAR_93

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

так тоже утечка

Pablito · 18.04.2017, 11:40

Java
1
View v = new View(context);

тоже утечка?

demixdn · 18.04.2017, 12:04

Сообщение от asttoxa

Проще 1 контекст в конструктор пропихнуть, чем все строки.

проще один метод getString(int stringId) в Application прописать и к нему обращаться из любого места.

@vxg · 18.04.2017, 12:21

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

@shavuz · 18.04.2017, 12:34

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

@vxg · 18.04.2017, 21:03

shavuz, если мы не уродуем вселенную засовывая контекст активити в статику приложения то объекты логически наверное у нас имеют время жизни меньшее чем активити и не должны вызывать утечку. просто мысли в слух

Добавлено через 43 секунды
...кстати - а является ли контекст чем-то индивидуальным? уж не одна и та же штуковина там выскакивает для всего приложения)?

demixdn · 19.04.2017, 11:37

Сообщение от vxg

уж не одна и та же штуковина там выскакивает для всего приложения

getApplicationContext один на все приложение. Поэтому многие сторонние либы требуют инициализации в Application классе. Они получают один контекст, который живет пока живет все приложение. И соответственно не может быть утечки памяти, потому что все живет в зависимости от Application. Единственный случай, когда может быть 2 Application, это если запустить сервис в новом процессе, указав в манифесте android: process. Думаю аналогичное поведение и у других компонентов, если выставить этот флаг.

Pablito · 19.04.2017, 12:17

я думаю, что тег process не связан с разными контекстами, ApplicationContext все равно будет один

Добавлено через 28 минут
перепроверили тут... беру свои слова назад
походу реально создается отдельный процесс и ссылка на ApplicationContext будет другая

@vxg · 19.04.2017, 12:21

Паблито, слава экспериментаторам! кстати, философски, зачем вообще нужен контекст и зачем он у каждой активити разный (не проверял)

Pablito · 19.04.2017, 12:27

да у меня тоже возник этот вопрос и я тут же развил тему в стиле "прожектор пэрис хилтон"
а что если прописать своему сервису тег process, в он стартанет в UI потоке? да в UI
но это будет уже не тот UI поток, в котором активити из другого процесса? х.з., проверять лень потому что не совсем понимаю зачем такое может понадобиться

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

мутновато написал, да

@vxg · 19.04.2017, 12:49

Паблито, я тупанул по поводу предположительной одинаковости контекста у разных активити - наивно думал что каст активности в контекст исторгнет из ее недр некую общую сущность - чудес не бывает - активити = контекст - засунете его в статику или что то живущее сверх жизни активити и пипец

demixdn · 19.04.2017, 12:52

vxg, точно из ApplicationContext нельзя вызвать другой Activity, не проставив ему флаг FLAG_ACTIVITY_NEW_TASK. Также нельзя его засунуть в LayoutInflater, только от контекст от Activity.
Так что Activity Context нужно использовать внутри компонентов этого Activity, а Application Context для более глобальных вещей, типа БД, SharedPreferences и т.д. В том числе и для вычитывания строк

@ExFau$t · 19.04.2017, 12:54

Не по теме:

Чувствую себя участником научного симпозиума, организованного в подвале пивного бара. А ТС, наверное, представляет себя ещё и в китайском баре.

@vxg · 19.04.2017, 13:07

demixdn, имхо система сама толкает на идиотизм вымогая в некоторых случаях контекст на что получает первый попавшийся

Новые блоги и статьи Все статьи Все блоги /
Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .
Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .	Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .

@asttoxa 1 / 1 / 0 Регистрация: 25.10.2016 Сообщений: 83

	Получение ресурса string в классах 18.04.2017, 09:45. Показов 1604. Ответов 19 Метки нет (Все метки) Доброе утро товарищи. Понадобилось получение строк из классов не содержащих context или activity. Погуглив узнал, что есть 2 способа, 1) передать context/activity через конструктор класса 2) использовать Application так как он виден всегда и везде. Так как у меня классы мелкие, и контекст там нужен ТОЛЬКО для получения строковых. Я посчитал это излишним пихать контекст и поэтому больше склонился ко 2 способу, тем более что класс, унаследованный от Application, у меня уже есть. Увидел способ который советуют : И сразу вспомнилась статья https://habrahabr.ru/company/sebbia/blog/243537/ Где сказано "Никогда не сохраняйте ссылки на activity (view, fragment, service) в статических переменных" Мне показалось в предложенном способе как раз этот пункт и нарушается. Или нет? Что думаете уважаемые по этому поводу? И может есть еще способы получить строковые ресурсы без передачи context через конструктор? Спасибо. 0

@asttoxa 1 / 1 / 0 Регистрация: 25.10.2016 Сообщений: 83
	18.04.2017, 10:00 [ТС]
	Тоже проблемно. Там не одна строка. Проще 1 контекст в конструктор пропихнуть, чем все строки. 0

@ExFau$t 1570 / 1168 / 426 Регистрация: 08.05.2012 Сообщений: 5,219
	18.04.2017, 10:34
	Ты переписываешь конструктор на приём стринга, получаешь этот стринг в активити до вызова этого конструктора и передаёшь туда какие хочешь строки, и не паришься с контекстом. 0

@vxg Модератор 3409 / 2181 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	18.04.2017, 12:21
	shavuz, мне кажется утечка будет если будет циклическая ссылка - если же мы просто передаем контекст в некий объект, а потом этот объект выходит из области видимости и попадает на прием к сборщику мусора, то проблем с его удалением быть не должно - в месте создания уже нет актуальной ссылки на объект. если объекты живут дольше чем контекст, то тут конечно есть над чем подумать, но применительно к контексту это звучит невероятно... 0

@shavuz 114 / 120 / 26 Регистрация: 29.01.2014 Сообщений: 609
	18.04.2017, 12:34
	в таком контексте вы правы, но если будет продолжение то будет лик. по этому не советуется изначально так делать. например придет другой программист и использует тот же обьект с тем же активити и сборщик мусора не соберет нужный мусор так как его держит другой обьект 0

@vxg Модератор 3409 / 2181 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	18.04.2017, 21:03
	shavuz, если мы не уродуем вселенную засовывая контекст активити в статику приложения то объекты логически наверное у нас имеют время жизни меньшее чем активити и не должны вызывать утечку. просто мысли в слух Добавлено через 43 секунды ...кстати - а является ли контекст чем-то индивидуальным? уж не одна и та же штуковина там выскакивает для всего приложения)? 0

Pablito 2884 / 2296 / 769 Регистрация: 12.05.2014 Сообщений: 7,978
	19.04.2017, 12:17
	я думаю, что тег process не связан с разными контекстами, ApplicationContext все равно будет один Добавлено через 28 минут перепроверили тут... беру свои слова назад походу реально создается отдельный процесс и ссылка на ApplicationContext будет другая 0

@vxg Модератор 3409 / 2181 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	19.04.2017, 12:21
	Паблито, слава экспериментаторам! кстати, философски, зачем вообще нужен контекст и зачем он у каждой активити разный (не проверял) 0

Pablito 2884 / 2296 / 769 Регистрация: 12.05.2014 Сообщений: 7,978
	19.04.2017, 12:27
	да у меня тоже возник этот вопрос и я тут же развил тему в стиле "прожектор пэрис хилтон" а что если прописать своему сервису тег process, в он стартанет в UI потоке? да в UI но это будет уже не тот UI поток, в котором активити из другого процесса? х.з., проверять лень потому что не совсем понимаю зачем такое может понадобиться тут же пришла идея что теперь можно стартовать сервисы в отдельных процессах-thread-ах и там работать например с базой данных, и не нужно будет тяжелые операции выносить в другие потоки, все равно UI поток сервиса уже отличается от UI потока активити мутновато написал, да 0

@vxg Модератор 3409 / 2181 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	19.04.2017, 12:49
	Паблито, я тупанул по поводу предположительной одинаковости контекста у разных активити - наивно думал что каст активности в контекст исторгнет из ее недр некую общую сущность - чудес не бывает - активити = контекст - засунете его в статику или что то живущее сверх жизни активити и пипец 0

demixdn 314 / 257 / 81 Регистрация: 31.10.2016 Сообщений: 619
	19.04.2017, 12:52
	vxg, точно из ApplicationContext нельзя вызвать другой Activity, не проставив ему флаг FLAG_ACTIVITY_NEW_TASK. Также нельзя его засунуть в LayoutInflater, только от контекст от Activity. Так что Activity Context нужно использовать внутри компонентов этого Activity, а Application Context для более глобальных вещей, типа БД, SharedPreferences и т.д. В том числе и для вычитывания строк 0

@ExFau$t
	19.04.2017, 12:54
	Не по теме: Чувствую себя участником научного симпозиума, организованного в подвале пивного бара. А ТС, наверное, представляет себя ещё и в китайском баре. 0

@vxg Модератор 3409 / 2181 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	19.04.2017, 13:07
	demixdn, имхо система сама толкает на идиотизм вымогая в некоторых случаях контекст на что получает первый попавшийся 0