Develop Reference

Android Studio Listview for loop adapter update

i have a question, i have a for loop, that loops through an arraylist and checks if a value is something, and if so, it deletes an row in a listview....I am having trouble though, this is the code...
for (int i=0; i<displayList.size(); i++)
{
Object toRemove = mAdapter.getItem(i);
Log.e("Counter+++",String.valueOf(i));
if (!firstname.equals("")) {
if (firstnamefilterstring.equals("Contains"))
{
if (!displayList.get(i).getFirstname().contains(firstname))
{
//displayList.remove(listView.getItemAtPosition(i)); doesnt work
// displayList.remove(toRemove); doesnt work either
L.e("1");
}
The problem is through debugging I have realized this loop only runs 6/12 times (the for loop is 12 elements big), and I have no clue why... Through some additional debugging, I realized that the two lines with "doesnt work" if you comment them out, it runs fine (12 times), but with either of those two lines it doesnt....Im at a lost here,

The reason it runs half the time is you are removing items from your display List, hence displayList.remove.
The java.util.ArrayList.remove(int index) method removes the element
at the specified position in this list. Shifts any subsequent elements
to the left (subtracts one from their indices).

xamarin mutli selection listview

It's been a while that i'm trying to get an anwser to my problem, but i didn't find it... So i'm searching for your help.
I work on xamarin to make an android application but i dont use Xamarin.Forms (i would have used it, if i knew it when i begin the project
I'll directly to the point, if you have some question, just ask me.
So i got a Listview where i can select 2 or more items :
private void _listViewIntervention_ItemClick(object sender, AdapterView.ItemClickEventArgs e)
{
_intervention[e.Position].IsSelected = !_intervention[e.Position].IsSelected;
if (_intervention[e.Position].IsSelected)
e.View.SetBackgroundColor(Android.Graphics.Color.Rgb(255, 127, 127));
else
e.View.SetBackgroundColor(Android.Graphics.Color.Rgb(230, 230, 230));
_numberInterventionSelected.Text = _intervention.FindAll(elem => elem.IsSelected == true).Count().ToString();
}
That thing work but if i have a listview with 20 items i.e and i select 3 items, if i scroll the listview, everything will be disturb and my 3 highlighted rows won't be anymore and the highlight will be on another row that i've never select.
I think that not that evident and it might be blur.
IMO i'm not changing the good thing when i do the "e.View.SetBackgroundColor" but i've try lot of thing that never worked.
I might not going the best way to do what i want to do btw.
The result i want is when i scroll the listview, nothing change so i can select the first and the last item of the listview i.e.
I search again in my side but i count a little on you know...
Thanks for reading and have a good day !

I have already getting same problem after lot of search and find the solution
In Xamarin custom adapter remove ViewHolder System it's working fine after removing Holder system

setListAdapter(adapter_name) to change the list displayed on screen, but still appears information from the previous displayed list

I have an activity that extends ListActivity, a list of "concepts" (let's call this list "C") and an onItemClickListener defined for this list. Whenever I click a "concept", no matter which one, the app must display another list. I have the following code to change the displayed list:
if(position == 0) change_list("adapter1");
else if (position == 1) change_list("adapter2");
else if (position == 2) change_list("adapter3");
else if (position == 3) change_list("adapter4");
else if (position == 4) change_list("adapter5");
Where position is the position of the clicked element in C
The function change_list performs setListAdapter(parameter) depending on the parameter I pass.
If I click the first element of C (the first concept), a list related to the first concept must appear. However, after calling setListAdapter(adapter), the data related to this concept is displayed, and also part of the C's list data.
For example: let's suppose C has these concepts:
A B C D E
and I click "A", which would lead to display a list with the following data: {a1,a2}
That's the final result:
a1 a2 C D E
And then, when I interact with another element on screen or I scroll down the list, the "ghost" data disappears and only the correct data remains on screen, just like this:
a1 a2
To make things worse, when I want to display list C again, nothing strange happens. Everything is displayed correctly.
At any time incorrect data is stored where it doesn't have to. One function my app must allow is to generate a txt file , and the generated txt file contains exactly the data I introduced. No data is corrupted or duplicated. I also tried using notifyDataSetChanged() and other functions, but I didn't solve the problem.
EDIT :
Here goes the xml code used for the main list of the activity:
<ListView
android:id="#android:id/list"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:background="#FF0000"
android:layout_below="#+id/afegir"/>
And an example of code in which I determine which contents must be displayed on screen:
else if(comprovar_concepte_actiu() == 1){
pnt = mydbhandler.getStoredValues("despeses1");
pnt.moveToFirst();
if(pnt.moveToFirst()){
do{
adapter_mostrar.add(pnt.getString(pnt.getColumnIndex("nom")));
}while(pnt.moveToNext());
}
adapter_mostrar.notifyDataSetChanged();
}
Where comprovar_concepte_actiu() returns and integer that tells which concept has been clicked in the main list C and adapter_mostrar is the single adapter I'm using now, instead of using multiple adapters (which made me use setListAdapter)
At the beginning of the activity, I call this.setListAdapter(adapter_mostrar). That's all I have.
EDIT 2 :
https://www.dropbox.com/s/7twgy043lkxb2x5/conceptes.java?dl=0
Here is a link to my conceptes.java activity. Press CTRL+F once opened and search "this is where I call.. " and you will directly get to the function where the change of list displayed on screen starts
I haven't found a solution yet. Any idea will be totally appreciated

The problem here is that - when you set a new adapter - the old data is still drawn. In other words, there has been no command to "refresh" the listView. However, the new adapter will be commanded to draw its own views. What ultimately occurs is that the old items are still there, the new items are redrawn, but when scrolled away the new adapter won't redraw/recreate the old items.
The solution is to simply refresh the adapter. However, there are two ways to go about this:
Add a new adapter every time and use myListView.invalidateViews(); or something similar [This is probably the easiest solution to implement, although probably not the best in the long run]
Change the dataset of the adapter and use notifyDataSetChanged() [on the adapter]
The latter option is a far better idea. You should use a single adapter and simply change its data over time. Once its dataset is changed, then tell the adapter that such a thing happened so it refreshes. However, you should read more here on all the different thoughts and processes about it, rather than take my opinion on it.
Edit:
There's apparently some very nicely, thought out answers around. Here's another one, that tells you more specifically about the differences between these two:
Is there any difference between ListView.invalidateViews() and Adapter.notifyDataSetChanged()?
Edit2:
With the onClickListener in mind, invalidateViews() will most likely not work, as it'll probably still draw the old views to "finish" the click (ie, draw the highlighting).
Changing the data directly inside a single adapter and using Adapter.notifyDataSetChanged() is your best bet, as it'll know to redraw everything from a single adapter and use only the current data defined by this single adapter.
Best to leave the data specifics (and defining what to draw based off of that data) up to what actually knows the data, rather than a higher up container that knows nothing specific about the actual data.

Hard/Fast fling using the swipe to dismiss library and a ContentProvider shows the wrong item

I have been developing an app that has a listview in which items may be removed by the user.
Now I have been trying to use the swipe to dismiss library in my project, by Roman Nurik: https://github.com/romannurik/Android-SwipeToDismiss.
I've successfully implemented a button which removes a row (click), however I am unable to use the swipe to dismiss functionality of the library (swipe). This is all because of the canDismiss check I need to do.
I have a cursor (see ContentProvider and LoaderCallbacks) which I was trying to iterate over and use to determine if a row can be dismissed. However this does not seem to work, 'cause when I fling fast/hard it displays the second to last row twice (it's normal position and the last position) and it does the same thing for the first and second rows.
Has anyone ever done something similar? And how did you solve this issue?
My code:
Cursor cursor = (Cursor) mAdapter.getItem(position);
if (cursor.getInt(Card.CARD_REMOVABLE_COLUMN_INDEX) == 1) {
return true;
}
But everytime I try to use the cursor, the issue seems to appear.

Alright, I guess there is no good solution, other than fetching the required information from the view(s) itself. Unlike with web development, getting the information from the database all the time, is not an option.
I guess you could get the information from the viewtag if you would so desire. I've done something different, using the position I get from the library, I lookup the row in the listview, and check if certain views are visible (every row can be removable, hence they all have the same header(s), I check if a header is visible or not, and handle this).

Multiple TextViews update very slowly

I have a Service that sends an Intent to my Activity every 0.1 seconds. I use it to update a custom implementation of a Chronometer. Here everything goes right. The problem comes when I want to update 14 TextView I have in a TableView inside a Fragment in my Activity. Here the app is very slow.
The method in my Activity where it receives the Intent from the Service:
private BroadcastReceiver broadcastReceiver = new BroadcastReceiver() {
#Override
public void onReceive(Context context, Intent intent) {
long milis = intent.getLongExtra("milis",0);
if( mFragment != null)
mFragment.Update(milis);
}
};
The code inside the Fragment where I update the TextViews:
public void actualizarTiempoJuego(long milis){
// Se recuperan los tiempos acumulados y se aumenta la cantidad pasada como parámetro
for(int i=0;i<7;++i) {
long mCurrentMilis1 = mVectorMilis1.get(i);
long mCurrentMilis2 = mVectorMilis2.get(i);
TextView1 t1 = mListaTitularLayoutLocal.get(i);
TextView1 t2 = mListaTitularLayoutVisitante.get(i);
t1.setText(String.value(milis + mCurrentMilis1));
t2.setText(String.value(milis + mCurrentMilis2));
}
}
Am I doing anything wrong, or is it just that I'm trying to do something very complex in terms of efficiency?

#Sherif brings up a good point about hidden alpha values that bog down your application a lot.
Depending on your platform you may also want to check
<application android:hardwareAccelerated="true"... />
Another thing you can look into that may help performance is not firing off all those Intents. Once you start firing intents you are getting the system involved and depending on how they are getting resolved it may take some extra time.
For this issue I like to use Handlers. They are more light weight than intent.
You may also want to look at AsyncTask. This is basically like a thread, but also gives hooks that run on the UI Thread so you can perform both perform a background operation and update the UI without have to post runnables.
EDIT: Lastly, you can always run your layouts through the layoutopt tool. I was personally told by Romain Guy himself that if your drawing too slow, than you need to draw less. Just check out a screenshot (from a less than ideal view tree, but well within the max) from the profiling tool. You can see how much of the resources view drawing takes up. It's very important to keep this as lean as possible if you want your app to be responsive.
EDIT: It is no longer called layoutopt, it's called lint. Check your ~/android-sdk/tools/

I have once faced a situation where a fragment was really slow.
I am just predicting that your fragment has some kind of alpha and it is drawn on a 'heavy' activity.
The conclusion is that each time you are setting the text of a textview your whole view hierarchy is being invalidated.
It seems that fragments have this flaw. Anyway, use some layout instead of the fragment and check if it remains 'slow'.
ADDITION: A wrap_content textview will cause much more delay after a setText than a fill_parent textview.

You're likely running into slowdowns due to layout management with TableLayout and TextView. Every time you update text in one of those, a large amount of view measuring has to take place in order to put the characters in the right place on the screen. You should really just profile the app yourself using Traceview to find out. More information at: http://developer.android.com/tools/debugging/debugging-tracing.html
I've had the exact same issue you're seeing with the same type of layout (Fragment > TableLayout > Multiple TextViews). One way to test if your TableLayout/TextView setup is to blame is simply replace all that with a single TextView. That will probably run pretty well. Then put your 14 views into a FrameLayout or RelativeLayout. Even if they all overlap, you should still get decent performance, because it's the complexity of the TableLayout view measurements that's really causing slowdown.

As someone said you can use HardwareAccelerated but this is not a great solution, you will waste ram and cpu if you can't solve it in a different way. A solution probably more safety is to reduce the number of TextView. Try to reduce 14 to 7 and it will go twice faster. Usually is hard to do it but if you put the objects in a strategy position a pair of TextView one above other can be together if you make a TextView with two lines. And don't forget that findViewById is so expensive, if you will use a view object often find it one time and hold its reference.

Benchmarks are always useful for determining where slowness actually comes from, but I feel pretty confident suggesting that sending an Intent is probably much slower than updating 14 TextViews. Sending 10 Intents per second is a sign that you're Doing It Wrong (TM). This is just isn't what they're for.
Am I doing anything wrong, or is it just that I'm trying to do something very complex in terms of efficiency?
Updating 14 TextViews per second isn't inherently complex; you should be able to easily achieve this with a more appropriate application design. ASyncTask or Handler come to mind as possible tools, but it's hard to know what's best without knowing more about exactly what you're trying to do.

You can try to declare vars outside the loop :
public void actualizarTiempoJuego(long milis){
// Se recuperan los tiempos acumulados y se
// aumenta la cantidad pasada como parámetro
long mCurrentMilis1;
long mCurrentMilis2;
TextView1 t1;
TextView1 t2;
for(int i=0;i<7;++i) {
mCurrentMilis1 = mVectorMilis1.get(i);
mCurrentMilis2 = mVectorMilis2.get(i);
t1 = mListaTitularLayoutLocal.get(i);
t2 = mListaTitularLayoutVisitante.get(i);
t1.setText(String.value(milis + mCurrentMilis1));
t2.setText(String.value(milis + mCurrentMilis2));
}
}
And to setText() with mixed type, you can try setText("" + milis + mCurrentMilis2);