ImageView.setTag cannot be used for ViewHolder when root of layout

[TWiStErRob]

Glide Version/Integration library (if any): 3.5.2
Device/Android Version: S4/4.4
Issue details/Repro steps:
Consider a ListView containing a dead simple layout:

<?xml version="1.0" encoding="utf-8"?>
<ImageView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/image"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    />

and an Adapter which is using the usual ViewHolder pattern, i.e. inflating the view from resource (above) and setTag(vh);, now Glide wants to do the same when loading the image. There could easily be a way to prevent conflicts, by allowing the ViewTarget users to set an ID to use with setTag(int, Object), even if it's just a static method on ViewTarget (default beingView.NO_ID -> setTag(Object)).

Glide load line:

Glide.with(context).load(...).into(vh.image);

Stack trace:

    java.lang.IllegalArgumentException: You must not call setTag() on a view Glide is targeting
            at com.bumptech.glide.request.target.ViewTarget.getRequest(ViewTarget.java:105)
            at com.bumptech.glide.GenericRequestBuilder.into(GenericRequestBuilder.java:605)
            at net.twisterrob.app.android.view.Adapter.bindView()
            ...

[sjudd]

This is a good idea, we should definitely let people optionally set a tag. A static is kind of a hack, but it would work for v3. In v4 we will let people register their own target factories, so we can add the tag optionally to the constructor of the Target and provide it from the factory.

We could also release as an aar and use a resource id ourselves, but last time I looked aars weren't supported as well as jars by gradle/maven.

[TWiStErRob]

All that sounds reasonable.

I though about the static, because it's not really a Glide configuration, only the ViewTarget and subclasses use this method to store/retrieve the Request.

You don't and shouldn't have anything in Glide which justifies using resources and aar.
Though it works in Gradle, you must have checked it long ago, because almost everything in android-sdk\extras\android\m2repository\com\android\support is an .aar.

[sjudd]

It was more about transitive dependencies. I think gradle and/or maven don't (or didn't) support transitive dependencies for aars the way they do for jars.

Also worth noting, applications can always define their own resource ids use setTag with a resource id to get around the problem. In fact it might almost be preferable to just say that's the correct solution. It's just about the same amount of hassle to define a resource id and use it in your own tags as it is to define one and tell Glide to use it.

[TWiStErRob]

Yes I was thinking about the amount of hassle, but at the same time I like if libraries have common methods, like in almost every Java program I write I have to write a copyStream method instead of using the framework's non-existent method.

I guess this is a rare use case (ImageView being root) and you don't really need a ViewHolder in that case, just (ImageView)convertView, so we can accept that as a workaround.

There's also the case of using some base Adapter where you can't change the use of setTag yourself (in this case there's no hassle involved, it's plain impossible to do it without copying some existing class). I was trying to find an example, but SimpleAdapter, CursorAdapter are not using view holders nor the problem arises with RecyclerView.

However another argument for the library supporting this is: I would have N adapters to modify instead of "a line" in MyApp.java setting up which ID Glide should use for tags and everything can work without modification. Note that there's a View.generateViewId() since 16, so no need for xml.

I guess based on the factory in v4 we can close this one. There's a record of multiple ways how to work around it above in case someone ever finds this issue in v3. But still it may worth adding the support to ViewTarget even if there's no central way of providing it.

[ultimaters]

I got the same problem. I used Picasso before, Picasso works good. I hope Glide can surpport it too.

[TWiStErRob]

@ultimaters, I wouldn't wait for it, this is a nice to have, and there are several workarounds mentioned in the above comments, feel free to pick one of those instead. Extending ImageViewTarget and overriding get/setRequest seems the easiest one (you'll need .into(new YourImageViewTarget(iv))).

Also this should be obsolete once v4 comes.

[TWiStErRob]

Another use case for ViewTarget.setTagId(int): storing model data in setTag