Develop Reference

What is the working of setTag and getTag in ViewHolder pattern?

I have a simple code snippet for implementing custom listview.
My code is as follows:
WeatherAdapter.java :
public class WeatherAdapter extends ArrayAdapter<weather>{
Context mcontext;
int mlayoutResourceId;
weather mdata[] = null;
View row;
public WeatherAdapter(Context context, int layoutResourceId, weather[] data) {
super(context, layoutResourceId, data);
mlayoutResourceId = layoutResourceId;
mcontext = context;
mdata = data;
}
#Override
public View getView(int position, View convertView, ViewGroup parent) {
row = convertView;
WeatherHolder holder = null;
if(row == null)
{
LayoutInflater inflater = ( (Activity) mcontext).getLayoutInflater();
row = inflater.inflate(mlayoutResourceId, parent, false);
holder = new WeatherHolder(row);
row.setTag(holder);
}
else
{
holder = (WeatherHolder)row.getTag();
}
weather w = mdata[position];
holder.txtTitle.setText(w.mtitle);
holder.imgIcon.setImageResource(w.micon);
return row;
}
WeatherHolder.java:
class WeatherHolder
{
ImageView imgIcon;
TextView txtTitle;
public WeatherHolder(View v){
imgIcon = (ImageView)row.findViewById(R.id.imgIcon);
txtTitle = (TextView)row.findViewById(R.id.txtTitle);
}
}
}
I have seen so many answers on SO and other sites and I understood the recycling mechanism of listview.
I also understood that from viewholder, we can hold the child views in the adapter and we do not have to call findViewById() many times. So, it is for optimization.
But I have only the confusion in setTag(holder) and getTag() methods. From this question, I came to know that it is for making a key-value pair on multiple objects, so that we can access them easily. But, I do not understand why they are required here...because, we do not have multiple holder objects...only we have to change holder's variables each time. can we code here without using setTag and getTag?
can anyone explain better that what setTag and getTag do "here"?

tag is a mechanism to make your views remember something, that could be an object an integer a string or anything you like.
so when your ListView is going to create for the first time your convertView is null. so you create a new convertView and put all of your references of the objects of that row in a viewHolder. then save your viewHolder into the memory of that convertView(setTag). Android takes your convertView and puts it in its pool to recycle it and passes it again to you. but its pool may not have enough convertViews so it again passes a new convertView thats null. so again the story is repeated till the pool of android is filled up. after that android takes a convertView from its pool and passes it to you. you will find that its not null so you ask it where are my object references that I gave to you for the first time? (getTag) so you will get those and do whatever you like.
More elaboration on below line
but its pool may not have enough convertViews so it again passes a new convertView thats null
android pool is empty when your listView is going to create. so for the first item of your listView it sends you a convertView that must be displayed. after that android saves it in its pool, so its pool now contains just one convertView. for your second item of your listView that is going to create android can not use its pool because it is actually has one element and that element is your first item and it is being shown right now so it has to pass another convertView. this process repeates until android found a convertView in its pool thats not being displayed now and passes it to you.
Android inflates each row till the screen filled up after that when you scroll the list it uses holder.

Lets Look in a Different Perspective:
Lets imagine that the Helicopter is the "row" while the rope is the "setTag" and the car below is "WeatherHolder", but the pilot of the Helicopter is inside that car and he/she the one managing controlling the helicopter using a "WIRED REMOTE".
When you cut the Rope Which is "setTag" the Hellicopter still fly but the pilot can no longer control it since the pilot is drop in the ground which means the pilot is now dead! (In java when an object loss its reference the Garbage Collector will collect that and free from the memory).
When you did not place or attach the rope to the car while the Helicopter is about to fly where the Pilot is sitting - you potentially loss a control on the helicopter because you are using "WIRED REMOTE".
I hope this help :).

But, I do not understand why they are required here...because, we do not have multiple holder objects
This is where you are wrong - there is one holder per view (aka visible or cached ListView entry).

Android Listview GC_FOR_ALLOC freed: DDMS android.graphics.Bitmap

I'm having trouble with a listview in android. When I start scrolling down my List, it is very slow and I see that the GC is called. When I'm at the bottom of my List, everything works fine and smooth. I think that at this point my ViewHolder does the work.
But I can't find the source that is calling the GC. I searched which lead to:
DDMS 436816 byte[] 1 android.graphics.Bitmap nativeCreate
I can't interpret that line. My ArrayAdapter and it's getView method looks like this:
public class DiagnoseAdapter extends ArrayAdapter<Visualizer> {
#Override
public View getView(int position, View convertView, ViewGroup parent) {
int type = TYPE_DEFAULT;
final Visualizer item = getItem(position);
switch(item.getType()){
case TYPE_DEFAULT:
convertView = DefaultTextView.getView(position, convertView, mlayoutInflater, item, parent);
break;
// more cases/types
}
return convertView;
}
}
which is calling the following getView Method of the class DefaultTextView
public class DefaultTextView{
public static View getView(int position, View convertView, LayoutInflater layoutInflater, Visualizer item, ViewGroup parent){
ViewHolder holder;
if (convertView == null || item.getReleatedObject() == null || convertView.getTag()!=TAG_DEFAULT) {
convertView = layoutInflater.inflate(R.layout.diagnose_item, null);
holder = new ViewHolder();
holder.value = (TextView) convertView.findViewById(R.id.diagnose_function_value);
holder.name = (TextView) convertView.findViewById(R.id.diagnose_function_setname);
holder.mLinLayout = (LinearLayout) convertView.findViewById(R.id.default_linlayout);
convertView.setTag(TAG_DEFAULT);
convertView.setTag(R.layout.diagnose_item,holder);
item.setReleatedObject(convertView);
} else {
holder = (ViewHolder) convertView.getTag(R.layout.diagnose_item);
}
holder.value.setText(item.toString());
holder.name.setText(item.getToolTip());
holder.mLinLayout.removeAllViews();
if (item.getUpdateFlag(4)) {
if (holder.back == null){
holder.back = new ImageView(convertView.getContext());
holder.back.setScaleType(ScaleType.FIT_CENTER);
holder.back.setAdjustViewBounds(true);
holder.back.setImageBitmap(bm1);
}
holder.mLinLayout.addView(holder.back);
}
if (item.getUpdateFlag(1)) {
if (holder.update == null){
holder.update = new ImageView(convertView.getContext());
holder.update.setScaleType(ScaleType.FIT_CENTER);
holder.update.setAdjustViewBounds(true);
holder.update.setImageBitmap(bm2);
}
holder.mLinLayout.addView(holder.update);
}
if (item.getUpdateFlag(2)) {
if (holder.timer == null){
holder.timer = new ImageView(convertView.getContext());
holder.timer.setScaleType(ScaleType.FIT_CENTER);
holder.timer.setAdjustViewBounds(true);
holder.timer.setImageBitmap(bm3)
}
holder.mLinLayout.addView(holder.timer);
}
if (item.getUpdateFlag(3)) {
if (holder.log == null){
holder.log = new ImageView(convertView.getContext());
holder.log.setScaleType(ScaleType.FIT_CENTER);
holder.log.setAdjustViewBounds(true);
holder.log.setImageBitmap(bm4);
}
holder.mLinLayout.addView(holder.log);
}
if (item.getUpdateFlag(0)) {
if (holder.forward == null){
holder.forward = new ImageView(convertView.getContext());
holder.forward.setScaleType(ScaleType.FIT_CENTER);
holder.forward.setAdjustViewBounds(true);
holder.forward.setImageBitmap(bm5);
}
holder.mLinLayout.addView(holder.forward);
}
return convertView;
}
static class ViewHolder {
TextView name, value;
ImageView back, update, timer, log, forward;
LinearLayout mLinLayout;
}
}
Even if I comment the LinearLayout out, so I just have a List with two TextViews.
So my Question. Do I miss anything. Some stupid thing? How do I get my ListView smoother?
BTW: I read in a different thread, that it is happening if the ListView has the attribute android:cacheColorHint="#00000000. I don't have this attribute.
I hope anyone has a solution. Thanks!

About the source of GC calls. If I'm understanding your code correctly, everytime your ListView items are recycled and you call removeAllViews(), a previously dynamically created ImageView is removed and its Bitmap is garbage collected. So, Maybe those GC calls would be avoided if you use the same ImageView declaring it in your xml layout and just replace the Bitmap according to your getUpdateFlag().
And two more things about ListViews and Images. First thing is that if the image is too big, your ListView is going to be laggy no matter what. You would need to scale the image down if that is the case( Loading Large Bitmaps Efficiently). And second, maybe you would also need to implement a Lazy List, which loads images on demand, there is a famous question about that --> How do I do a lazy load of images in ListView?

I've finally solved my Problem. Like above, I thought the problem was based on the images of my list items. But that wasn't the problem. I just didn't use my ViewHolders and the getItemViewType(int position) method correctly. I have a list with many different item layouts and I saw, that my code above created a new convertView and a new ViewHolder for every single item, which wasn't supposed to be. I found a great tutorial about how to use multiple item layouts (see link below):
Multiple List Item Layouts

Effective ArrayAdapter

First of all, my problem:
My ListView woun't scroll smoothly.
Now a bunch of details:
I'm currently using an ArrayAdapter<CustomClass> in my App for displaying Text and and Image in each element of the ListView. I've been trying to make the ListView to scroll as smooth as possible. But as soon as the text becomes longer (about 40 characters), the ListView starts to stutter when scrolling.
I am displaying about 9 rows at the same time. If I make the ListView smaller (about 6 rows) it works fine..
I am not implementing onScrollListener and I am not running big background tasks.
This is the code I'm currently using (only getView and Holder):
#Override
public View getView(int position, View convertView, ViewGroup parent) {
//View row = convertView;
Holder holder = null;
if(convertView == null){
//Log.e("adapter", "convertview == null");
LayoutInflater inflater = ((Activity)context).getLayoutInflater();
convertView = inflater.inflate(layoutResourceId, parent, false);
holder = new Holder();
holder.imgIcon = (ImageView)convertView.findViewById(R.id.icon);
holder.txtTitle = (TextView)convertView.findViewById(R.id.folder_name);
holder.txtInfo = (TextView)convertView.findViewById(R.id.info_text);
holder.pBar = (ProgressBar)convertView.findViewById(R.id.pBar);
convertView.setTag(holder);
}else{
holder = (Holder)convertView.getTag();
}
TrackInfo tInfo = data.get(position);
if(tInfo == null){
return convertView;
}
holder.imgIcon.setImageResource(icon);
holder.txtTitle.setText(tInfo.getTitle());
return convertView;
}
static class Holder
{
ImageView imgIcon;
TextView txtTitle;
TextView txtInfo;
ProgressBar pBar;
}
You may notice there are more elements than I actively use. This is due to the reason that I normally use the others, too, but I am currently ignoring them since I was trying to find out why it's not scrolling smoothly.
As already mentioned, it seems to be the length of the string tInfo.getTitle(). I can't change the length of the strings, since those are filenames I can't influence.
Now my QUESTION:
What's the problem? Is it that much data to handle? Or is my code bad?
I'm testing on a Moto G (1.2GHz Quad-Core, more details here).
Thank you for your attention, have a good flight!

I was working with marquee effect in the ListView. I always thought that as long as I don't call TextView.setSelected(true), this wouldn't cause any further processing. Therefore, I had android:ellipsize="marquee" as a parameter for my TextView in the layout-file of the ListView-element, while only one to-be-highlighted element was set selected.
Apparently, I was wrong.
As long as the text wasn't too long for the given space (about 40 characters), there was no problem. But if the size of the text exceeded the given space, the problems started.
I am not sure what exactly the problem is, but after having a look into the source of the TextView, I recognized that there is a lot more to do when marquee is enabled:
The TextView is faded out on the right side (instead of ...)
A Spannable is used as a CharSequence
It needs to be checked if marquee should start
...
So long story short:
I removed marquee and ListView scrolls very smoothly.

ListView recycles images

I have a custom ArrayAdapter that gets images from the web. I understand that the views get recycled. My code seems to work but there is a problem with the images that are loaded from the web. Occassionally, the wrong image might show for another row. For example, Mickey Mouse might be the image on Row 0 and when I scroll down Mickey Mouse might appear briefly for Row 9 (example) before changing to Donald Duck. And when I scroll back up to the top, Donald Duck might appear for Row 0 before changing back to Mickey Mouse.
Here is my code:
class OffersCustomAdapter extends ArrayAdapter<Merchant>{
Context context;
ArrayList<User> userName;
private LayoutInflater inflater;
private ImageLoadingListener animateFirstDisplayListener;
private ImageLoader imageLoader;
public OffersCustomAdapter(Context c, ArrayList<User> users) {
super(c, R.layout.single_row, users);
this.context=c;
this.userName=users;
imageLoader = ImageLoader.getInstance();
imageLoader.init(ImageLoaderConfiguration.createDefault(context));
}
static class ViewHolder{
TextView title;
TextView cat;
TextView type;
TextView desc;
ImageView pic;
}
#Override
public int getViewTypeCount() {
return 1;
}
#Override
public int getItemViewType(int position) {
return position;
}
#Override //parent is listview
public View getView(int position, View convertView, ViewGroup parent) {
View row=convertView;
ViewHolder viewHolder;
if(convertView == null){
inflater = (LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
//row contains our relative layout
row =inflater.inflate(R.layout.single_row, parent, false);
viewHolder = new ViewHolder();
viewHolder.title =
(TextView) row.findViewById(R.id.textView1);
viewHolder.pic = (ImageView) row.findViewById(R.id.imageView1);
row.setTag(viewHolder);
}else{
viewHolder = (ViewHolder) convertView.getTag();
}
viewHolder = (ViewHolder) row.getTag();
User u = userName.get(position);
String titleSt = userName.get(position).getName();
viewHolder.title.setText(titleSt);
imageLoader.displayImage(imageUrl+userName.get(position).getImg(), viewHolder.pic, animateFirstDisplayListener);
return row;
}
I've looked at other examples of SO but no luck.

It's because The view is being recycled. When you scroll down, the next view that comes up will use the same view that just scrolled out of view (i.e. Mickey Mouse). You can fix this by displaying a loading image while your imageLoader fetches the new image.
If you don't have a loading image, you can do something like this at the beginning of your getView(...) method:
viewHolder.pic.setImageDrawable(null);
Edit: fixed based on comment.

It's likely because the previous image loading operation isn't canceled if still underway when the view is recycled, so this introduces a race condition on setting the view's bitmap. This issue is discussed briefly in this post, which might be worth a read through: Multithreading for Performance
The author explains it in a bit more detail:
However, a ListView-specific behavior reveals a problem with our
current implementation. Indeed, for memory efficiency reasons,
ListView recycles the views that are displayed when the user scrolls.
If one flings the list, a given ImageView object will be used many
times. Each time it is displayed the ImageView correctly triggers an
image download task, which will eventually change its image. So where
is the problem? As with most parallel applications, the key issue is
in the ordering. In our case, there's no guarantee that the download
tasks will finish in the order in which they were started. The result
is that the image finally displayed in the list may come from a
previous item, which simply happened to have taken longer to download.
This is not an issue if the images you download are bound once and for
all to given ImageViews, but let's fix it for the common case where
they are used in a list.
and provides a workaround example that may be of help.

Try picasso
Once you have the jar in your workspace, you just need one line of code.
Replace imageLoader.displayImage(imageUrl+userName.get(position).getImg(), viewHolder.pic, animateFirstDisplayListener);
with
Picasso.with(context).load(your_image_Url).into(viewholder.pic);
I believe your_image_url in your case is imageUrl+userName.get(position).getImg();

There is a 5 year old Android blog post that describes how to solve this by hand, Multithreading for Performance.
Nowadays, you should use Picasso or Volley for image loading. These network APIs will easily solve your problem and give you additional benefits, such as caching. Volley is the API that Google uses inside their own apps. I use it in my apps and am a fan.
See a thorough introduction to both frameworks.

Setting visible to elements that were invisible before in GridView

I have a GridView in which I want to always show 7 icons, and sometimes an additional icon depending on a request. In the beginning the additional icon is never shown. This is the structure:
0 1 2
3 4 5
6 [7]
All the icons fit into the screen so I don't need/have scroll. Each icon is composed by an image and a text.
For this, I have a CustomAdapter which extends BaseAdapter. I have overriden the getView method in which I set the text and the image for each icon.
public View getView(int position, View convertView, ViewGroup parent) {
View v = null;
if (convertView == null) {
LayoutInflater li = ((Activity) context).getLayoutInflater();
v = li.inflate(R.layout.icon, null);
} else {
v = convertView;
}
TextView tv = (TextView) v.findViewById(R.id.icon_textView);
tv.setText(position);
ImageView iv = (ImageView) v.findViewById(R.id.icon_ImageView);
iv.setImageResource(imageResourcesArray[position]);
if ((position == ADDITIONAL_ICON)) && !showAdditionalIcon) {
v.setVisibility(View.INVISIBLE);
}
return v;
}
The imageResourcesArray[] is an array of integers with the image resources.
The other functions and variables in the CustomAdapter are:
public static final int ADDITIONAL_ICON = 7;
private boolean showAdditionalIcon = false;
public showAdditionalIcon(){
this.showAdditionalIcon = true;
notifyDataSetChanged();
// notifyDataSetInvalidated();
}
public hideAdditionalIcon(){
this.showAdditionalIcon = false;
notifyDataSetChanged();
// notifyDataSetInvalidated();
}
Later on, I create and set the CustomAdapter to the GridView from a class which extends Activity (say ClassA):
GridView grid = (GridView) findViewById(R.id.main_gridView);
customAdapter = new CustomAdapter(this);
grid.setAdapter(customAdapter);
My problem appears when after some calculations and requests to a server, I have to show the additional icon (number 7). So I call (from ClassA):
customAdapter.showAdditionalIcon();
Now, the additional icon appears, but the first icon disappears... I have tried to use notifyDataSetInvalidated() and notifyDataSetChanged() but both had the same result.
Of course, I could generate a new CustomAdapter with the additional icon allowed, but I would preffer not to do it...
Thanks in advance.

I'm not sure if this counts as an answer for you. Root of the problem seems to be the convertView we are using. I did not dig so deep into Android source, but I think there is no guarantee on how views are reused even it is obvious that all views are already visible and there should be no reuse behind the scenes.
What this means is that the view we linked to position 7 as we visualize this whole scenario is actually reused later at position 0. Since your code does not explicitly reset a view to be visible, the view will be reused with visibility set to INVISIBLE, thus the mystery of the disappearing first item.
Simplest solution should be as #Vinay suggest above, by explicitly setting to View.VISIBLE.
if ((position == ADDITIONAL_ICON))) {
if (!showAdditionalIcon)
v.setVisibility(View.INVISIBLE);
else
v.setVisibility(View.VISIBLE);
}
Hope this helps, but I'm really hoping some Android expert pops by to tell us more about how this whole thing of reusing old views actually works.