In my main-activity layout (RelativeLayout), I display three listviews of vertical orientation among other Buttons and Textviews. My problem is that when one of the listviews (the one on the left side of the screen) updates, the other two update too, causing poor UI performance.
I understand that RelativeLayout can be tricky in cases when the size of one view affects the positioning of the other (causing the other to redraw), so I have made sure that the positioning of the two listviews is not associated with the left listview's size.
I have also checked out tips on how to make listview redrawing more efficient, using ViewHolders etc, but I'd rather resolve this problem to it's core.
More details:
For the left listview's adapter I subclass the ArrayAdapter class.
For the other two listviews' adapters I use subclass the CursorAdapter class.
You are right RelativeLayout in the culprit, use some other view in plase of it, like LinearLayout with android:weightSum etc...
If you set android:layout_height="wrap_content" to your ListView, then system try to find the best size of each elements and call getView many times. There is no way to around that other than using android:layout_height="fill_parent"
http://www.androiddevelopersolutions.com/2013/07/android-listview-adapter-getview-called.html
custom listview adapter getView method being called multiple times, and in no coherent order
Try to use same adapter class for the better performance because the execution time differs on what sort of data your are going to display.
Related
I am dynamically adding around 150 linearlayouts to a scrollview in a grid-like layout. If I set the background resource to a drawable for each of them using setBackgroundResource(R.drawable.x), the scrollview shows extremely noticeable lag and choppiness, even though the drawable is a simple colour and border.
If I remove the call to setBackgroundResource, the scrollview is smooth again.
Is this expected to happen with so many views containing backgrounds? If so, how would I go about making a grid with custom backgrounds for each cell?
You're going to want to use a list view in your scroll, and you're going to want to use a ListAdapater:
http://developer.android.com/guide/topics/ui/layout/listview.html
http://developer.android.com/reference/android/widget/Adapter.html
Basically what's going on is you're loading a large number of images into memory, and the scroll view by default doesn't do a very good job of managing releasing and inflating these resources.
Using methods similar to the above, with some custom image management, I've managed to get thousands of views running smoothly on a scroll.
It seems like you're trying to create your own list view implementation so that you can set your own layouts for each row. I don't recommend doing this. Instead, use the default list view implementation provided by Android and instead of setting a default ArrayAdapter instance on the list view, subclass ArrayAdapter, override the getView method, and return your custom layout.
I highly recommend you check out this tutorial for a more thorough explanation:
http://www.ezzylearning.com/tutorial.aspx?tid=1763429
Everyone knows that GridView does not supports headers and footers like a ListView.
There is a few ways to implementing this:
Use a ListView and form columnt manually via ViewGroups. It not works for me, because it's require a lot of layout operations like measuring and layouting, and it's difficult to implement draw selector on top.
Use special adapter. It works fine with a footer: we should fill last cells with a Space and manually insert after them out footer with width that equals GridView width. But this not works with headers: although header is stretched, next cells float on it.
Use a GridLayout. GridLayout is good, but what about performance with 500-1000 cells? AdapterView supports caching and reusing Views, as far as I know, this is not possible with GridLayout.
Extend GridView and write custom class, that allows to draw a header before the grid content. It's difficult, but it's should work very fast. Let's try to figure out how to do this:
Measure the header. It's very simple, I have not questions about this.
Layout header in the top of the grid. We also should consider with scrolling position to allow move header with whole grid content, so my first question is: how to know where bottom border should be located while scrolling?
Layout whole grid content after the header. How to do that? I've newer do this before.
Dispatch draw to the header view too and resolve overscrolling effect if it's not work well.
Handle the scroll event and refresh header position.
So what you can suggest me? How to do header offset? Is it right to invoke relayouting with every scroll event?
I searched an answer on a same situation with a GridView (but for a FooterView).
I've read attentively your suggestions and some from other websites. I had the same reflexion. I found a simple way as your tip: "Use special adapter. It works fine with a footer..." and this answer by #RaulSoto helped me a lot. But when I tried to update my gridview, I had a NPE, because my footer was not like the layout of my items and I had a custom filter which recalculated the getCount() method, but without understand that another view was added.
Finally, I found only solution which works: a custom class.
Create your own class as you said: "Extend GridView and write custom class" but don't extend GridView. You should extend with ListView and measure the entire width, the column width and the number of columns. I think, it's less difficult that to extend GridView, calculate the height of the header view and move it as you move your gridview or refresh the header each time you handle a scroll event..
I searched to do it in this way and I took this little project on GitHub: HFGridView by Sergey Burish. It was exactly what I need, no more.
I only added a custom attrs file in my app and customize a bit his project to have the expected result (especially, it was to have one column in portrait, two in landscape mode, refering to the numColumns attribute in my layout).
And when I try, just for test, to add a HeaderView and refresh the content with adding new items, the header view stays at the top of my gridview list, without refreshing himself.
So, I think you should search to create your class as GridView extends ListView. Refer you to the HFGridView by SBurish, it is very simple to understand how it does.
Hope this helps you with your purpose.
I have a ViewPager that contains ImageViews downloaded from the net and it slides just fine when my ListView (in another separate layout) is not initialized.
But the problems start when my ListView is created. The ViewPager still "slides" but only slides about 1/4 of the way, lags, then loads the next ImageView correctly.
All of the network and bitmap operations are done using AsyncTask. I've also used the RemoteImageCache API from Singly API which works pretty well.
Any ideas as to why ViewPager's swipe is lagging?
The slow down was caused by the ListView calling getView more than necessary (more than 3x per item in my list).
According to this solution, the ListView's width and height must be given specific values and not wrap_content or else getView() will be called multiple times.
it's just because of list view scroll is conflict with view pager scroll..
if you want to know about this just set list view visibility gone don't remove code listView.setAdapter(adapter) then try view pager will slide properly.
Recently (2020), must be to implement a ViewHolder class to you get speed, or, refactoring with RecyclerView, it depends of the size of your list and the time that you have to execute this methods, like my software was already production stage, i preferred use ViewHolder class, the speed gain came to be 40%, sufficient to me, if you need the more speed, must be to use RecyclerView (refactoring your listview, edit .xml, your adapter, use Linear or Grid layout manager...).
I have an app which loads a boatload of images and displays them in a TableLayout which is inside a ScrollView. At run time I get the width of the layout parent and use that to determine how many images can go in each TableRow (all of the images are of a set size).
I'm concerned about memory issues when loading more and more images. I know ListView recycles its views but I don't know how to dynamically change number of views in each item. I am only aware of inflating XML which isn't going to change the number of views per item at run time.
So my question is what is easier - figuring out how to recycle views in my table by myself, or making a list's items change based on screen size? Just a link to a tutorial on how to do whichever is easier is good enough an answer for me.
I suggest you to use ListView with the ViewHolder approach (you can see it here: How to load the Listview "smoothly" in android).
The ListView, when scrolled, removes the views that are no more visible and gets the views that are about to become visible. This way, it's better than using a ScrollView and a TableLayout.
I'm making a GUI with two different parts. The first part (at the top) is composed of some banners, several fixed buttons. So I think using LinearLayout is the most straightforward way to implement. The second part is composed of several similar items grouped together which can be implemented by using ExpandableListView, I think.
However the problem is that the content exceeds the screen size. So I intend to put two of them into a ScrollView. I checked several sources, it seems that putting "ExpandableListView" inside a ScroolView is NOT possible, or not efficent, so I'm afraid...
Would you help to confirm if this is possible? efficient ?
If no, would you give me some recommendations for this layout design?
I'm indeed looking forward to your supports.
Sincerely.
If you have a fixed header at the top of a list, use ListView's header view feature.
Putting ListViews in ScrollViews fundamentally makes no sense and here is why:
ListView has one purpose: to efficiently display unbounded data sets. Since these can be extremely large (tens of thousands of items and more) you do not want to create a View for each item up front. Instead, ListView asks its Adapter for Views only for the items that currently fit in the ListView's measured space on screen. When an item's View is scrolled out of sight, ListView disconnects that View and hands it back to the adapter to fill out with new data and reuse to show other items. (This is the convertView parameter to an Adapter's getView method.)
ScrollView also has one purpose: to take a single child view and give it "infinite" vertical space to fit within. The user can then scroll up and down to see the full content.
Now given this, how many item Views would a ListView create for a 100,000 item Adapter if it had infinite height available to fill? :)
By putting a ListView inside a ScrollView you defeat ListView's key purpose. The parent ScrollView will give the ListView effectively infinite height to work with, but ListView wants to have a bounded height so that it can provide a limited window into a large data set.
Well Expandable List View itself has scrollable property by placing it in scroll view is really undesirable.As the both scroll would contradict and smooth scrolling can't be obtained in that case..
If we have any data to be shown prior or later to list...
Best way is to use header and footer view to list...
I recommend you use header and footer in your case.