Develop Reference

Images flickering in android

I am working on social application and it's about to complete but I got stuck on one issue that is image flickering. When there is around 9 to 10 images on screen and if I scroll the page then the image flicker take place.
#Override
public View getView(final int position, View convertView, ViewGroup parent) {
final ViewHolder holder;
if (convertView == null) {
LayoutInflater inf = (LayoutInflater) act.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
convertView = inf.inflate(R.layout.view_grid_explore, null);
holder = new ViewHolder();
holder.img = (ImageView) convertView.findViewById(R.id.img_grid_album);
} else {
holder = (ViewHolder) convertView.getTag();
}
ImageLoader.getInstance().displayImage(
Static_Urls.explore_pic + data.get(position).talk_pic,
holder.img);
convertView.setTag(holder);
notifyDataSetChanged();
return convertView;
}

Note : Don't forget to remove notifyDataSetChanged();.
This is happening because once the images are downloaded in the device by UIL(Universal Image Loader), it caches the images in Memory and device.
By using this code :
ImageLoader.getInstance().displayImage(Static_Urls.explore_pic +data.get(position).talk_pic,
holder.img);
every time getView() is called UIL tries to fetch the image from network, but by the time it releases that image is already being cached so it shows the image after making a network request first.
so in order to get rid of this flickering use this code :
ImageLoader imageLoader = ImageLoader.getInstance();
File file = imageLoader.getDiskCache().get(Static_Urls.explore_pic +data.get(position).talk_pic);
if (file==null) {
//Load image from network
imageLoader.displayImage(Static_Urls.explore_pic +data.get(position).talk_pic,
holder.img);
}
else {
//Load image from cache
holder.img.setImageURI(Uri.parse(file.getAbsolutePath()));
}
This code will first check whether the image is already cached or not, Then accordingly fetch image from Network or from cache.

The notifyDataSetChanged() line is redundant there. Working with adapters always keep in mind that(in case of adapters extending BaseAdapter) the getView() method is responsible for inflating the layout of the list item and also updating the UI if if you handle it so(normally you do)
Calling notifyDataSetChanged() will cause the getView() being called again right away which is why you see the flickering.
You should only call notifyDataSetChanged() when you would like to update the adapter content. One example would be when you build yourself a "refresh()" method inside your adapter like:
public void refresh(List<Object> list) {
data.clear();// Assuming data is a List<> object or an implementation of it like ArrayList();
data.addAll(list);
notifyDataSetChanged(); // This will let the adapter know that something changed in the adapter and this change should be reflected on the UI too, thus the getView() method will be called implicitly.
}

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.

Async image loading, check if an image is recycled

This question came to me after reading this: Performance tips (specifically the part named "Async loading"). Basically he's trying to save info about a row to see if it's been recycled yet and only set the downloaded image if the row is still visible. This is how he saves the position:
holder.position = position;
new ThumbnailTask(position, holder)
.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, null);
Where ThumbnailTask constructor is:
public ThumbnailTask(int position, ViewHolder holder) {
mPosition = position;
mHolder = holder;
}
In onPostExecute() he then does the before mentioned check:
if (mHolder.position == mPosition) {
mHolder.thumbnail.setImageBitmap(bitmap);
}
I just don't see how this gives any result. The Holder and the position are set in the constructor at the same time, to the same value (the position in the holder is the same as the position in mPosition). They don't get changed during the AsyncTask (it's true that the position might change in getView(), but the ones stored in the AsyncTask as private members are never manipulated). What am I missing here?
Also saving the position doesn't seem like a good option in the first place: I believe that it's not guaranteed to be unique, and if I recall correctly it resets itself to 0 after scrolling. Am I thinking in the right direction?

Background (you probably know this, but just in case): An adapter contains a collection of objects and uses info from these objects to populate Views (each view is a line item in the list). The list view is in charge of displaying those views. For performance reasons the ListView will recycle views that are no longer visible because they scrolled off the top or the bottom of the list. Here's how it does it:
When the ListView needs a new view to display it calls the Adapter's getView with an integer argument "position" to indicate which object in the Adapter's collection it wants to see (position is just a number from 1 to N -1) where N is the count of objects in the adapter.
If it has any views that are no longer visible, it will pass one of them in to the Adapter, too, as "convertView" This says "reuse this old view rather than creating a new one". A big performance win.
The code in the article attaches a ViewHolder object to each view it creates that, among other things, contains the position of the object requested by the ListView. In the article's code, this position is stashed away inside the ViewHolder along with a pointer to the field within the view that will contain the image. The ViewHolder is attached to the View as a tag (a separate topic).
If the view gets recycled to hold a different object (at a different position) then ListView will call Adapter.getView(newPosition, oldView...) The code in the article will store new position into the ViewHolder attached to the oldView. {make sense so far?) and start loading this new image to put into the view.
Now in the article, it is starting an AsyncTask to retrieve data that should go into the view) This task has the position (from the getView call) and the holder (from the oldView). The position tells it what data was requested. The holder tells it what data should currently be diplayed in this view and where to put it once it shows up.
If the view gets recycled again while the AsyncTask is still running, the position in the holder will have been changed so these numbers won't match and the AsyncTask knows it's data is no longer needed.
Does this make it clearer?

When AsyncTask is passed with ViewHolder and position it is given value of position (say 5) and value of reference (not a copy) to ViewHolder object. He also puts current position in ViewHolder (said 5), but the whole "trick" here is that for recycled views, the old ViewHolder object is also re-used (in linked article):
} else {
holder = convertView.getTag();
}
so whatever code references that particular ViewHolder object, will in fact check against its position member value at the moment of doing check, not at the moment of object creation. So the onPostExecute check makes sense, because position value passed to task constructor remains unchanged (in our case it has value of 5) as it is primitive, but ViewHolder object can change its properties, if view will be reused before we reach onPostExecute.
Please note we do NOT copy ViewHolder object in the constructor of the task, even it it looks so. It's not how Java works :) See this article for clarification.
Also saving the position doesn't seem like a good option: I believe
that it's not guaranteed to be unique, and it resets itself to zero
after scrolling. Is this true?
No. Position here means index in *source data set, not visible on the screen. So if you got 10 items to display, but your screen fits only 3 at the time, your position will be in range 0-9 and visibility of the rows does not matter.

As I understand you are trying to cancel the async-loading-task of the image when the view recycled, and no longer on screen.
To achieve that you can set up an RecyclerListener to the listview. It will be invoked when the listview don't need this view (when is not on screen), just before it passes it as a recycled view to the Adapter.
within this listener you can cancel your download task:
theListView.setRecyclerListener(new RecyclerListener() {
#Override
public void onMovedToScrapHeap(View view) {
for( ThumbnailTask task : listOfAllTasks )
task.viewRecycled(task);
}
});
and within ThumbnailTask :
public void viewRecycled(View v){
if(mHolder.theWholeView == v)
v.cancel();
}
Don't for to implement the cancel.
Note that its not the best approach since you should keep track of all your asynctask tasks. note that you could also cancel the task within the adapter where you also get the
public View getDropDownView (int position, View recycledView, ViewGroup parent){
//.. your logic
}
but note that this might require you to allocate the ThumbnailTask within the adapter with is not good practice.
note that you could also use image loading libraries that do eveything for you, from async download to chaching. for instance : https://github.com/nostra13/Android-Universal-Image-Loader

The accepted answer and Marcin's post already describe perfectly what's supposed to happen. However, the linked webpage does not and the google site on this topic is also very vague and only a reference for people who already know about the "trick". So here's the missing part, for future references, which shows the necessary additions to getView().
// The adapter's getView method
public View getView(int position, View convertView, ViewGroup parent) {
// Define View that is going to be returned by Adapter
View newViewItem;
ViewHolder holder;
// Recycle View if possible
if (convertView == null) {
// No view recycled, create a new one
LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
newViewItem = inflater.inflate(R.layout.image_grid_view_item, null);
// Attach a new viewholder
holder = new ViewHolder();
holder.thumbnail = (ImageView) newViewItem.findViewById(R.id.imageGridViewItemThumbnail);
holder.position = position;
newViewItem.setTag(holder);
} else {
// Modify "recycled" viewHolder
holder = (ViewHolder) convertView.getTag();
holder.thumbnail = (ImageView) convertView.findViewById(R.id.imageGridViewItemThumbnail);
holder.position = position;
// Re-use convertView
newViewItem = convertView;
}
// Execute AsyncTask for image operation (load, decode, whatever)
new LoadThumbnailTask(position, holder).execute();
// Return the ImageView
return newViewItem;
}
// ViewHolder class, can be implemented inside adapter class
static class ViewHolder {
ImageView thumbnail;
int position;
}

Android listview image loading problem

I have an application that contains a couple of listviews. The listviews contains items that consist of imageviews and textviews.
All images are thumbnail sized on a server and the pattern used for loading them is like this:
Instantiate a DrawableManager
in the getView() method I do the following:
Pass the thumb uri and the ImageView instance to the DrawableManagers getImageAsync method
The method will first look on sd card if the image exists if so load it from SD card and save a softreference + update imageview drawable
If not exists on sd. Fetch from HTTP and save on SD (if there is enough space) put as softreference and update imageview drawable.
When the images exists on sd card everything works fine. But first time (or when using the app without sd card) the images seems to be populated into the wrong listviews rows when scrolling. When i stop scroll the problem fixes it self after a couple of seconds.
Its almost like if the ImageView references are pooled or something.
Any ideas?
I also include the getView method:
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder vh;
if (convertView == null) {
convertView = inflater.inflate(R.layout.informationrow, null);
vh = new ViewHolder();
vh.imageView = (ImageView) convertView.findViewById(R.id.rowInformationIcon);
vh.textView = (TextView) convertView.findViewById(R.id.rowInformationTitleLine);
convertView.setTag(vh);
}
else {
vh = (ViewHolder) convertView.getTag();
}
CustomCategory cc = items.get(position);
if (cc != null) {
vh.textView.setText(cc.get_name());
if (cc.getMediaUrl() != null) {
_drawMgr.fetchDrawableOnThread(cc.getMediaUrl(), vh.imageView);
vh.imageView.setBackgroundDrawable(getResources().getDrawable(R.drawable.imageframe));
}
else {
vh.imageView.setImageDrawable(getResources().getDrawable(R.drawable.trans4040));
vh.imageView.setBackgroundDrawable(null);
}
}
return convertView;
}

This is the View recycling used by ListView...
The convertView parameter passed to your getView() can refer to an existing item that has scrolled off the displayed part of the list, and can be reused to show an item that is now appearing.
So, yes, the same ImageView will be reused in multiple downloads in the code you posted. In your getView() you should check to see if a download is already pending and cancel it if it's no longer needed (or let it complete to a FIFO image cache somewhere, but not touch the ImageView which is now needed for a more recently-started download).
(An alternative, lazy developers implementation that assumes infinite memory would be to ignore the convertView parameter and instantiate fresh informationrow views on every call to it. Don't do that. :) ).

Use this Library for loading images in ListView.
https://github.com/nostra13/Android-Universal-Image-Loader

Best way to handle multiple getView calls from inside an Adapter

I have a ListView with custom ArrayAdapter. Each of the row in this ListView has an icon and some text. These icons are downloaded in background,cached and then using a callback, substituted in their respective ImageViews. The logic to get a thumbnail from cache or download is triggered every time getView() runs.
Now, according to Romain Guy:
"there is absolutely no guarantee on
the order in which getView() will be
called nor how many times."
I have seen this happen, for a row of size two getView() was being called six times!
How do I change my code to avoid duplicate thumbnail-fetch-requests and also handle view recycling?
Thanks.

Exactly, that could happen for example when you have
android:layout_height="wrap_content"
in your ListView definition. Changing it to fill_parent/match_parent would avoid it.

From api.
public abstract View getView (int position, View convertView,
ViewGroup parent)
convertView - The old view to reuse, if possible. Note: You should check that this view is non-null and of an appropriate type before using. If it is not possible to convert this view to display the correct data, this method can create a new view.
So if getView has already been called for this specific index then convertView will be the View object that was returned from that first call.
You can do something like.
if(!(convertView instanceof ImageView)){
convertView = new ImageView();
//get image from whereever
} else {} // ImageView already created

I m experiancing the same issue i change the layout_height of listView to match_parent resolve my issue.

My understanding is that you need to use the ViewHolder design pattern here. Just using a returned convertView can lead to reuse of a previous view (with some other image assigned in this case).
public class ImageAdapter extends ArrayAdapter<String> {
// Image adapter code goes here.
private ViewHolder {
public ImageView imageView;
public String url;
}
#Override
public View getView(final int position, View convertView, ViewGroup parent) {
View view = null;
ViewHolder viewHolder;
String url = getUrl(position);
if (convertView == null) {
// There was no view to recycle. Create a new view.
view = inflator.inflate(R.layout.image_layout, parent, false);
viewHolder = new ViewHolder();
viewHolder.imageView = (ImageView) view.findViewById(R.id.image_view);
viewHolder.url = url;
view.setTag(viewHolder);
} else {
// We got a view that can be recycled.
view = convertView;
viewHolder = ((ViewHolder) view.getTag());
if (viewHolder.url.equals(url)) {
// Nothing to do, we have the view with the correct info already.
return view;
}
}
// Do work to set your imageView which can be accessed by viewHolder.imageView
return view;
}
}

The better would be to create a object with Thumbnail(bitmap) and the text. And read the thumbnail if its not available in the object.

Create an array of ImageView objects in your adapter and cache them as you retrive them (whether from cache or web). For example, in getView, before you fetch the ImageView, check if it's already in your local array, if so, use it, if not fetch, once received store in your local ImageView array for future use.

My Fragment.xml has a ListView, the layout setting of this ListView was android:layout_height="wrap_content", and this ListView will bind to SimpleCursorAdapter later. Then I have the same issue in ViewBinder be called 3 times. The issue resolved after I change the layout_height="wrap_content" to "95p". I do consider that the "wrap_content" height cause this issue.
Trying to modify your Fragment.xml and I guess the 3 times called issue will no longer exist.