0

Допусти есть listView состоящий из textView's. Нужно к каждому textView прицепить какие-то данные, но чтобы они не были видны пользователю. Ps идея чтобы дописать нужные данные в textView и скрыть эту часть не подходит.

pavlofff
  • 36,765
Belenot
  • 750

2 Answers2

2

у класса View (и всех его наследников соответственно) есть методы setTag() , getTag() которые позволяют привязать к View любой объект, а затем извлечь его.

pavlofff
  • 36,765
1

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

Стоп! У нас же список! Значит, мы откуда-то подгружаем его? У списков есть как идентификаторы, так и возможность получить элемент списка (и это совсем не обязятельно будет вьюха!), так что лучше всего правильно организовать адаптер списка, а при клике (или другому событию) по нужному элементу брать его позицию или идентификатор и использовать их для получения данных. Это наиболее правильный способ. И никакие отдельные теги не нужны!

bukkojot
  • 2,144
  • В общем случае все верно, но автор не раскрывает целей, для которых требуется прикрепить к View доп. информацию. Так же я использовал прикрепление к тегам в такой схеме, это самое простое решение для RecyclerView на активити, если данные требуется передать в нее. – pavlofff Sep 09 '17 at 05:03
  • Посмотрел ответ: лично мне очень неприятно, когда что-то постоянно аллоцируется (в данном случае вьюшки и теги), да к тому же там изобретается велосипед по получению позиции. Из-за этого и таких программистов, мои планшеты с 1 гигом оперативы, которые я покупал как "крутые" несколько лет назад, теперь считаются "устройствами с малым количеством памяти" и для них пишут специальные кастрированные версии приложений, хотя приложения лучше почему-то не становятся. Я вообще предпочитаю не использовать RecyclerView и просто реализую ListAdapter - это просто и быстро, дает полный контроль над всем. – bukkojot Sep 09 '17 at 05:25
  • Если вы потестите эту схему профилировщиком, то и сами увидите, что речи о какой то перезагруженности памяти не идет вовсе, а позиция только для примера, в реальном использовании передавался POJO-объект и это самый простой способ сделать это. Проблема же современных приложений не в таких незначительных затратах памяти, как в примере, а в использовании всяких левых SDK, ксамаринов, кордовы и прочей многомегабайтной ереси. – pavlofff Sep 09 '17 at 06:21
  • Непонятно ваше отношение к использованию памяти: вы готовы экономить на спичках, как критика примера, но не признаете RecyclerView, который на порядок оптимизированее ListView по использованию памяти – pavlofff Sep 09 '17 at 06:21
  • @pavlofff, вы считаете, что костыль из саппорт-либы лучше, чем нативный контрол? Я всегда считал, что RecyclerView для тех, кто не может голый ListView использовать – bukkojot Sep 10 '17 at 22:40
  • да, и это объективное преимущество, а не мое мнение. "Костыль" был создан, так как "нативный контрол" перестал удовлетворять требованиям оптимизации, так же использовать RecyclerView сложнее, чем ListView, но дает гораздо больший контроль "над всем". Непонятен и скептицизм по поводу саппорт либ. Это официальные компоненты андроид, вынесенные в отдельную библиотеку, чтобы был доступ с минимальных API и для 100% числа устройств, а не с какого нибудь API 24 с 10% пользователей. Вы могли бы ознакомится с возможностями и причинами появления виджета, прежде чем отказываться от его использования – pavlofff Sep 11 '17 at 06:12
  • А это ничего, что костыль официально потребляет больше памяти из-за того, что все референсы в памяти лежат и это фишка такая? А это ничего, что хендлеры надо вешать на каждый элемент? Если это и оптимизация, то оптимизация чего, а? Причин использовать этот виджет я не вижу. Единственное полезное в нем - это встроенные анимации, все остальное или сомнительно, или недостатки. С саппорт-либами у меня тоже как-то не сложилось. При этом мои приложения почему-то работают начиная с API 3 (к сожалению, я так и не смог скомпилить под 1.0, видимо потому, что это железо такое не выпускалось) – bukkojot Sep 11 '17 at 11:09
  • https://medium.com/wolox-driving-innovation/the-good-the-bad-and-the-ugly-things-about-the-new-recyclerview-1795df6f94c9 – bukkojot Sep 11 '17 at 11:10
  • посмотрите сколько создает объектов ListView и сколько RecyclerView при работе, как ими управляет. А поддержка API3 не нужна никому и ничем, кроме желания разработчика иметь геморрой на пустом месте, тут хвастаться нечем. – pavlofff Sep 11 '17 at 12:22
  • ListView выделяет ровно столько объектов, сколько нужно для отображения + при скроллинге 1-2 штуки. Если перевернешь экран, то доаллочит нехватающие или удалит ненужные. Потому ваш Рецайклер - жуткий к тому же велосипед, его "рецайкленность" была из коробки с первой версии ListView, который был с первых версий Андроида. Кроме как раздутым хайпом это объяснить ничем не могу. API3 - показывает размер моей пипись^W^Wмоего профессионализма, благо если писать грамотно (ну и с NDK), то версию можно поставить практически любую. – bukkojot Sep 11 '17 at 20:43
  • Ну понятно. Ладно. за 23 ревизии API конечно ничего путнего не добавили, да и вообще в гугле одни индусы костыли клепают. Это из серии "я до сих пор черно-белый телевизор смотрю, потому что, смотреть надо грамотно", смысла дальше что то обсуждать не вижу. – pavlofff Sep 11 '17 at 21:51