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;
}
Related
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).
How do I update the text of a button to a listview through another class without modifying the text of the other buttons on the list?
Ex:
ITEM 1 [DOWNLOAD]
ITEM 2 [DOWNLOADING... 60%]
ITEM 3 [DOWNLOADING... 40%]
ITEM 4 [DOWNLOAD]
Actually, works but scrolling the listview, other buttons have your values changed too..
I need to create a list of mÃdia ready for download, but when I click in a download button, the download starts, the percent updates but other buttons have your text changed too...
I would like to update the text "downloadBt" buttons of the listView items through my class Downloader, making progress on them: Downloading ... 30%
What is the best form to make this?
Solution:
Create a new instance of List:
private static class ViewHolder {
protected ImageView cover;
protected TextView issueNumber;
protected TextView details;
protected Button downloadBt;
protected Button moreBt;
protected View convertView; <<<
protected ViewGroup parent; <<<
}
#Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder viewHolder;
list.get(position).setListPosition(position);
if (convertView == null) {
LayoutInflater inflater = context.getLayoutInflater();
convertView = inflater.inflate(R.layout.list_item_list_issue, null);
viewHolder = new ViewHolder();
viewHolder.cover = (ImageView) convertView.findViewById(R.id.issue_list_item_cover);
viewHolder.issueNumber = (TextView) convertView.findViewById(R.id.issue_list_item_number);
viewHolder.details = (TextView) convertView.findViewById(R.id.issue_list_item_details);
viewHolder.downloadBt = (Button) convertView.findViewById(R.id.list_item_issue_download);
viewHolder.moreBt = (Button) convertView.findViewById(R.id.list_item_issue_more);
viewHolder.parent = parent;
viewHolder.convertView = convertView;
convertView.setTag(viewHolder);
} else {
viewHolder = (ViewHolder) convertView.getTag();
}
viewHolder.issueNumber.setText(list.get(position).getIssue());
viewHolder.downloadBt.setText(list.get(position).getDownloadStatus());
try{
vList.remove(position);
}catch(Exception e){
e.printStackTrace();
}
vList.add(position, viewHolder);
return convertView;
}
And in my Downloader class, send the position and the Adapter instance. I have been created a method refresh in my adapter class:
public void refresh(int position){
if((listView.getFirstVisiblePosition() <= position)&&(position <= listView.getLastVisiblePosition()))
getView(position, vList.get(position).convertView, vList.get(position).parent);
}
And this update only a selected item in the listview.
!!UPDATE!!
It is clear from the log that you are trying to update the button from a different thread other than UI thread. The UI objects/views should be updated only from the UI thread and UI thread should not be used for long running operations. These are basics you are supposed to know. I strongly recommend you go through the docs and/or videos for better understanding.
The solution is to use AsyncTask instead of Runnable and AsyncTask has a method progressUpdate() that runs on the UI thread. Alternatively, you can have your Runnable as a subclass in Activity and use the method runOnUiThread() for updating the view.
I also notice problem with your thread pools as you associate them with the objects in list view, which means, if there are 10 convertView objects, you'll have 10 thread pools with 50 threads. This will degrade the performance and you're essentially using only one thread from this pool. You need to get strong with your basics and revisit the solution.
Inside a list view, the item objects are reused, which is the convertView argument in the getview()method in the Adapter. So, when convertView is null, you create the item view object for the first time and as you scroll through, the same object is re-used instead of creating a new one as this saves CPU cycles( and hence battery) in terms of avoiding garbage collection and creating new objects. In other words, if you have a list of 100 items and only 10 items can be fit on your screen only 10 objects will be created even though you scroll through all the 100 items as the same 10 objects are re-used as the screen responds to scrolling. This is true for the child views as well(i.e., the buttons as well).
From your code, I see that you are using Button objects in your download threads. Button objects are also re-used. Check if this could be the problem.
Check this video if you haven't already.
The problem is that you are trying to update the button itself, you should update the items wrapped by adapter and call on the main thread adapter.notifyDataSetChanged(); in order to get your list view refreshed (trigger other calls to getView for visible positions). So your ComicDownloader should accept a comic object and a reference to the adapter itself.
Sundeep is right, convertView (toghether with the button in it) gets reused (and this is a normal and wanted behaviour) and you should'n rely on it.
This line: viewHolder.downloadBt.setText(list.get(position).getDownloadStatus()); should be called just before returning the convertView, and not only when convertView is null, doing so you make sure the returned view is up to date according to requested position, no matter if is reused or fresh created.
EDIT:
In your DownloadListener implementation, IssueListAdapter.this.notifyDataSetChanged(); should be called on the main thread. Currently, it's called directly from your run() call, wich is executed in background. Because this listener already knows which comic is updated, you can have a singleton for all your comics. Also, since your ComicDownloader is final, it will be related to first position that 'created' it, that means that wen you'll start a download, your button will update correct, but the comic downloaded behind may not be the one you think it is. To solve this, I recomend to create a ComicDownloader when button is clicked (you can also share one clickListener instance and retreive current comic for pressed button - setting a tag related to current position for button is a correct way to do it).
In your ComicDownloader class, executorService should be static (one pool shared across downloaders).
Ok, so my approach is something like this. I am decoding locally stored encrypted and serialized Objects in an AsyncTask in an Activity. The Activity uses a BaseAdapter (HistoryAdapter) for the data to display. The AsyncTask shows a ProgressDialog until decoding is done. When onProgressUpdate() is first called, the ProgressDialog is cancelled. So far, so good. Next, in onProgressUpdate(), the HistoryAdapter is notified of the changes in the common way, triggering it's getView() method. In the HistoryAdapter's getView(), a second AsyncTask is run to modify the created convertView and set the data onto the View.
Here is where it all fails on me. I inflate the final layout in onProgressUpdate(), and set properties and data on convertView just fine here. The changes just don't show, even though all the data is set...
So, the AsyncTask in HistoryAdapter in itself in fact works perfectly, the changes are just not visible. I tried numurous suggestions mentioned on SO, like invalidating convertView, passing a reference to the ListView and using invalidateViews() (causes an eternal loop but no visible changes, which makes sense).
I really want this, because I really don't want to load the layout with image placeholders before data is available. That I got working, but looks nasty and like the easy way out. So I need the ListView to update (add the item) only when progress is done. Any ideas?
EDIT: to clarify: the data is set on the adapter in just the right time. The problem is, the adapter creates a blank View (placeholder) first (don't know any other way, otherwise you will get a NullPointerException in getView), then this View is inflated / replaced with another View in onProgressUpdate(). The second View is the one who should be visible. This works somewhat, because I can get and set properties on the newly inflated View. The changes are just not visible, and I am still seeing the blank, initially created View. I want to update the ListView on each added item, not when all items are done loading...
public View getView(int position, View convertView, ViewGroup parent) {
if (convertView == null) {
//convertView = mInflater.inflate(R.layout.history_list_item_holo_dark, null);
convertView = mInflater.inflate(R.layout.blank, parent, false); // CHEAT: LOAD BLANK/ EMPTY LAYOUT
HistoryHolder item = history.get(position);
new AsyncRequest(convertView, position).execute(item);
}
this.parent = parent;
return convertView;
}//end method
static class ViewHolder {
TextView TITLE;
TextView SUMMARY;
TextView DATE;
ImageView CONTACT_ICON;
ImageView OPTIONS_ICON;
ImageView TYPE_ICON;
}//end class
private class AsyncRequest extends AsyncTask<HistoryHolder, View, View> {
ViewHolder holder = null;
String title = "";
String summary = "";
String date = "";
long id = 0;
private View convertView = null;
private String type = "";
private int position = -1;
public AsyncRequest(View superView, int position){
this.convertView = superView;
this.position = position;
}//end constructor
#Override
protected View doInBackground(HistoryHolder... item) {
Thread.currentThread().setName(getClass().getSimpleName());
if (item[0].TYPE.equals("log")){
//massive decrypting going on here 50-100 ms
//values like title and summray set here
}
if (item[0].TYPE.equals("sms")){
//massive decrypting going on here 50-100 ms
//values like title and summray set here
}
publishProgress(convertView);
return convertView;
}// end method
#Override
protected void onProgressUpdate(View... view) {
super.onProgressUpdate(view);
}// end method
#Override
protected void onPostExecute(View result) {
super.onPostExecute(result);
if (!MathUtils.isEven(position)){
result .setBackgroundColor(context.getResources().getColor(R.color.darker)); //this works as expected, list items vary in color
} else {
result .setBackgroundColor(context.getResources().getColor(R.color.medium_dark));
} //this works as expected, list items vary in color
result = mInflater.inflate(R.layout.history_list_item_holo_dark, parent, false);
result.setTag(id);
holder = new ViewHolder();
holder.TITLE = (TextView) result .findViewById(R.id.title);
holder.SUMMARY = (TextView) result .findViewById(R.id.summary);
holder.DATE = (TextView) result .findViewById(R.id.date);
holder.CONTACT_ICON = (ImageView) result .findViewById(R.id.icon);
holder.TYPE_ICON = (ImageView) result .findViewById(R.id.type);
holder.OPTIONS_ICON = (ImageView) result .findViewById(R.id.options);
holder.OPTIONS_ICON.setFocusable(false);
holder.OPTIONS_ICON.setTag(id);
holder.TITLE.setText(title); //this change doesnt show
holder.SUMMARY.setText(summary); //and so on
result .setTag(holder);
}//end method
}//end inner class
And I know I could modify my AsynTask and that I don't need to pass reference to the View in so many places, but then again, it's code in progress. Simplified example...
EDIT
Okay, so it seems my approach was poor to begin with, resulting in the need to have a AsyncTask in my HistoryAdapter. I adressed a few issues to resolve this.
Based on #Delyan 's suggestion, I decided it was good to load/ decrypt data before it is actually needed. I am using a PropertyChangeListener for this. This implements a OnSharedPreferenceChangeListener so that it get's notified of changes to the data I need. Changes are then propagated to any interested listeners. The data is decrypted on application start and stored in a global variable, which is accesible throughout the application. See this as the 'memory cache' he referred to.
Based on the comments and on the accepted answer, decrypting now is done in the background, so there is no longer a need for AsyncTasks.
To further optimise the performance of my adapter, I am storing images needed for the ListView in a SparseArray, so they are only created and stored once. Don't use a HashMap for this! Furthermore, the images are only created for the current View if they aren't already in a HashMap (images aren't unique).
public class HistoryAdapter extends BaseAdapter{
private static Context context = ApplicationSubclass.getApplicationContext_();
private Contacts contacts = Contacts.init(context);
private SparseArray<Drawable> c_images = new SparseArray<Drawable>();
private HashMap<Long, Drawable> contact_imgs = new HashMap<Long, Drawable>();
private ArrayList<HistoryHolder> history;
private LayoutInflater mInflater;
public HistoryAdapter(Context context) {
HistoryAdapter.context = context;
mInflater = LayoutInflater.from(context);
}//end constructor
...
public View getView(int position, View convertView, ViewGroup parent) {
final HistoryHolder item = history.get(position);
Drawable d = null;
if (c_images.get(position) == null){
if (!contact_imgs.containsKey(item.CONTACT_ID)){
if (item.IN_CONTACTS && item.CONTACT_ID != 0 && item.CONTACT_ID != -1){
Bitmap photo = contacts.getContactPhotoThumbnailByContactId(item.CONTACT_ID);
if (photo != null){
d = Convert.bitmapToDrawable(context, photo, 128, 128);
} else {
d = context.getResources().getDrawable(R.drawable.ic_contact_picture);
}
} else {
d = context.getResources().getDrawable(R.drawable.ic_contact_picture);
}
contact_imgs.put(item.CONTACT_ID, d);
}
}
c_images.put(position, contact_imgs.get(item.CONTACT_ID));
ViewHolder holder;
if (convertView == null) {
convertView = mInflater.inflate(R.layout.history_list_item_holo_dark, null);
holder = new ViewHolder();
holder.POSITION = position;
holder.TITLE = (TextView) convertView.findViewById(R.id.title);
holder.SUMMARY = (TextView) convertView.findViewById(R.id.summary);
holder.DATE = (TextView) convertView.findViewById(R.id.date);
holder.CONTACT_ICON = (ImageView) convertView.findViewById(R.id.icon);
holder.CONTACT_ICON.setTag(position);
holder.OPTIONS_ICON = (ImageView) convertView.findViewById(R.id.options);
holder.OPTIONS_ICON.setFocusable(false);
holder.OPTIONS_ICON.setTag(position);
convertView.setTag(holder);
} else {
holder = (ViewHolder) convertView.getTag();
}
holder.CONTACT_ICON.setBackgroundDrawable(c_images.get(position));
holder.TITLE.setText(item.TITLE);
holder.SUMMARY.setText(item.SUMMARY);
holder.SUMMARY.setMaxLines(2);
holder.DATE.setText(item.DATE);
if (!MathUtils.isEven(position)){
convertView.setBackgroundColor(context.getResources().getColor(R.color.darker));
} else {
convertView.setBackgroundColor(context.getResources().getColor(R.color.medium_dark));
}
return convertView;
}//end method
static class ViewHolder {
TextView TITLE;
TextView SUMMARY;
TextView DATE;
ImageView CONTACT_ICON;
ImageView OPTIONS_ICON;
int POSITION;
}//end inner class
}//end class
Dmmh, what you say, you are wanting to do (So I need the ListView to update (add the item) only when progress is done) and what you are doing (AsyncTask in getView) are quite the opposite things.
AsyncTask in the end of getView is used (however in different way) for lazy image load i.e. to show large images and show text+imageplaceholder until download is complete.
You are trying to gradually fill in your adapter's datasourse in the First AsyncTask, but every time, you notify observers about changes in dataset you will have another cycle of getView calls for every item in dataset. No good.
First, never, NEVER!!! assume that getView will supply you back a convertview, previously filled for this very position. So you MUST either refill convert view with new values, or turn off performance optimization and supply new view every time you are asked for it. There's no way for ListView to turn off recycling attempts because this is the essence of ListView, the feature it is build upon.
Second (resulted from first), avoid at all means storing time-expensive (or user input) data into your newly created Views only. Views come and go, and you do not want to walk the long way to get the expensive data (or just lose user input). The only partial exclusion are simple ineffective implementations of big image lazy loading. To reduce memory usage they download only images that are currently visible by user. More effective implementations use off-ListView caching.
So, if you really want to have the items in your ListView to be added one at a time, but in full glory, you should:
0*. If you have to load user-provided icons and this takes significant time to load (I have not understand your initial post about that) make an empty ArrayList to cache loaded ones and access them by index. If all images are already available by some index, ignore this matter.
class DecryptedRecord {
String title = "";
String summary = "";
String date = "";
int contactViewIndex = -1;
int contactOptionsIndex = -1;
int contactImageIndex = -1;
int typeImageIndex = -1;
int optionsImageIndex = -1; //if option icon varies. ignore otherwise
}
Declare DecryptedRecord class, containing necessary data to fill in the view, e.g.:
In your AsyncTask: after loading every HistoryHolder, perform "heavy decrypting" and fill new DecryptedRecord with the values. If it is necessary to load cusom image(see no.0*), load it here and store its index in cache(ignore this if 0* is irrelevant). Attach filled DecryptedRecord to the HistoryHolder with setTag(). Call publishProgress(HistoryHolder)
In onProgressUpdate just add HistoryHolder to Adapter and call historyAdapter.notifyDataSetChanged();
In getView() synchronously inflate the view if convertView is null, and IN ALL CASES populate it with the data from DecryptedRecord acqired from HistoryHolder.getTag(). Inclusive, call setImageBitmap() on your ImageViews adressing necessary Bitmap in the corresponding list by index.
This should do what you want. Please, if you would have errors/problems, try to include complete code in your question, or it will be very difficult to understand the details of your situation. Hope that helps.
You need to separate your concerns. Decrypting/decoding data has no place in the UI layer.
In general, your current approach to have AsyncTasks per item is difficult and (some would say) wrong for multiple reasons:
Honeycomb and above, there's only ever one AsyncTask running at any one point in time, unless you explicitly set the Executor.
More importantly, by holding a reference to convertView, you're leaking abstraction from the ListView - it's possible that the view you're holding a reference to is being reused for a different position. Unless you take painstaking care to cancel AsyncTasks and ensure proper result delivery, this will cause you trouble.
As mentioned above, decrypting/decoding data has no place in the UI layer (and I consider the Adapters UI layer, since they have similar constraints on execution speed).
If I were you, I'd use a memory cache of decrypted data, expanding/shrinking it as demand changes. Then, I would just fetch decrypted data in the getView() method of the adapter. In order to avoid decrypting items when scrolling, you can set up a scroll listener on the ListView, so that you only show the items when the list is not moving. There's a demo in ApiDemos that does something similar.
EDIT:
As for your obvious problem, you're reinflating a view (result) without adding it to the list item (the convertView field in the task). You can fix that by adding it to convertView (in an empty layout, for example). Again, this will not work as you expected in all cases.
You could create a content provider which has your decoded data stored in a db/temp data structure and use that to update your views. The decoding etc could happen in a background via a service/thread. The adapter could talk to the decoded data via this provider. This is related to alexei burmistrov idea mentioned above.
Not the good option - To use your current layout - a layout file that has both blank & filled layouts. When the layout is first shown, the blank view is visible. and when task is finished the visibility is set to gone.
This solution is not optimal as the asynctask would run each time a getView is called. And Android re-uses views so it could be many times based on how you scroll on the UI etc.
sample code:
public void getView(){
result = mInflater.inflate(R.layout.history_list_item_holo_dark, parent, false);
holder = new ViewHolder();
holder.TITLE = (TextView) result .findViewById(R.id.title);
holder.SUMMARY = (TextView) result .findViewById(R.id.summary);
..
holder.OPTIONS_ICON.setTag(id);
result.setTag(holder);
result.setTag(R.id.view_id ,id);
AsyncTask.execute(result);
convertView = result;
}
AsyncTask(View ...){
onPostExecute(View view){
ViewHolder holder = view.getTag();
if(holder != null){
//set visibility of views in holder
//update Text & data
}
}
}
First, when the async task runs the onPostExecute you will have to set the data to the adapter and notifydatasetchanged().
Now be a little more clean with the list view when is empty using something like creating a progressBar and set it to the listview like this:
listView.setEmptyView(progressbar);
I am working on a small project where I create a listview bound to an ArrayAdapter. In the getView() function of ArrayAdapter, I do a loading of images from web urls on thread, and set them to list items (based on position of course, so url[0] image is set to list_item[0] etc). It all seems to work well.
However when I was testing the app, I noticed that if I wait my listview to fully display, then perform a fast scroll back and forth, I see sometimes the image on one list item is misplaced on other (like being in an intermediate state). However it's not going away until I scroll the wrongly-displayed-item out of screen and then back.
I do not know if it relates to my loading web url using thread, or maybe loading image from local resource folder can have the same issue.
This actually leads to a question I have about getView() function. I think the logic is correct in my getView() because it's as simple as a binding of url to view based on position. And whenever getView() get a chance to be called, like when I scroll an item out of screen then back, it will make the list item display correctly.
The thing I do not understand is how to explain the issue that happened (like an intermediate state), and how to avoid it when writing code?
I paste my adapter code piece below, but I think the question maybe a general one:
#Override
public View getView(int position, View v, ViewGroup parent) {
ViewHolder viewHolder = null;
if (v == null) {
LayoutInflater inflater = (LayoutInflater) getContext()
.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
v = inflater.inflate(layoutResourceId, parent, false);
viewHolder = new ViewHolder();
viewHolder.title = (TextView) v.findViewById(R.id.title);
viewHolder.description = (TextView) v.findViewById(R.id.description);
viewHolder.image = (ImageView) v.findViewById(R.id.image);
v.setTag(viewHolder);
} else {
viewHolder = (ViewHolder) v.getTag();
}
listItem item = items[position]; //items is some global array
//passed in to ArrayAdapter constructor
if (item != null) {
viewHolder.title.setText(item.title);
viewHolder.description.setText(item.description);
if (!(item.imageHref).equalsIgnoreCase("null")) {
mDrawableManager.fetchDrawableOnThread(item.imageHref, viewHolder.image);
} else {
viewHolder.image.setImageDrawable(null);
}
}
return v;
}
}
static class ViewHolder {
TextView title;
TextView description;
ImageView image;
}
I have same issue when scroll quickly it alternate the vales of some item to others, just like background color of some items if changes randomly. I solved this issue by searching a lot and find exact solution is just adding these two methods in your adapter if you are using ViewHolder in your adapter
#Override
public int getViewTypeCount() {
return getCount();
}
#Override
public int getItemViewType(int position) {
return position;
}
Assuming that you are not caching the downloaded image.. lets see the following code:
if (!(item.imageHref).equalsIgnoreCase("null")) {
mDrawableManager.fetchDrawableOnThread(item.imageHref, viewHolder.image);
} else {
viewHolder.image.setImageDrawable(null);
}
Now if the image view is getting reused then it would already have the old image for the assigned list item. So until the thread download the image from the network it would display the old image and when the thread download the image for the current item it would be replaced with the new image. Try to change it to:
if (!(item.imageHref).equalsIgnoreCase("null")) {
viewHolder.image.setImageDrawable(SOME_DEFULAT_IMAGE);
mDrawableManager.fetchDrawableOnThread(item.imageHref, viewHolder.image);
} else {
viewHolder.image.setImageDrawable(null);
}
Or you can use something link smart image view that supports HTTP URI and also caches the images. Check out following link for smart image view:
https://github.com/loopj/android-smart-image-view
http://loopj.com/android-smart-image-view/
Add ImageLoader class from below link in your project.
link
just call DisplayImage() methode of Image loader class as below in getView()
ImageLoader imageLoader = new ImageLoader();
yourImageView.setTag(URL_FOR_Your_Image);
imageLoader.DisplayImage(URL_FOR_Your_Image,ACTIVITY.this, yourImageView);
Your images will load in background as you want without wait.
I think you should declare your downloader method fetchDrawableOnThread() as "synchronized" . Because a lot of threads are working simultaneously and any thread which started later, can end earlier. So there are chances of images being misplaced.
It happened to me for a long time. Finally "synchronized" helped me do it cleanly. I hope it helps you too.
I give it a try with synchronization again. Either synchronize the fetchDrawableOnThread(), or synchronize the global hashmap data within fetchDrawableOnThread(). First i thought the issue is gone, but when i tried more times later, i found the issue is still there.
Then i thought about the synchronization. fetchDrawableOnThread() is called from getView(), and getview() itself does not have a concurrency issue. Even if as Yogesh said, what happened INSIDE getView() is thread-based, and return early or late, it can not affect the correctness of getView(), i.e. the list item's display, only the sooner or later.
What i did(synchronization) inside fetchDrawableOnThread() i think it's still correct, 'cause i used a hashmap to cache images downloaded from remote url, and this hashmap is read/write upon in a multi-thread situation, so it should be locked. But i do not think it's the rootcause of the UI misplace, if hashmap is messed up, the image misplacement will be permanent.
Then i looked further on convertView reuse mechanism based on Praful's explanation. He explained clearly what happened when image always comes from remote and no cache locally, but my situation is i waited my list to display fully, i.e. all images download complete and cached complete, before i do the fast scroll. So in my experiment, the images are read from cache.
Then when inspecting my code, i saw one minor difference in the use of convertView as in getView() method, a lot of the example usages are like this:
public View getView(int position, View convertView, ViewGroup parent) { // case 1
View v = convertView;
.... // modify v
return v;
}
However the example i happened to copy from use:
public View getView(int position, View convertView, ViewGroup parent) { // case 2
.... // modify convertView
return convertView;
}
I thought it makes no difference at first, 'cause according to what android says, 'ListView sends the Adapter an old view that it's not used any more in the convertView param.', so why not use 'convertView' para directly?
But i guess i was wrong. I changed my getView() code to case 1. Boom! everything works. No funny business ever no matter how fast i scroll the list.
Quite strange, is convertView only old, or is it old & in-use? If the later, we should only get a copy and then modify..... ??
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.