I'm making sort of a news feed, that is displayed below a static menu. To avoid the news feed from being scrolled in the tiny bit of space that's left after the menu, I wanted to scroll both the menu and the newsfeed at the same time.
Now I'm realizing this with a LinearLayout, so it doesn't scroll itself like the listview. But my question is, is using a LinearLayout, which from what I know doesn't reuse views like a listView, bad practice? How likely am I to get into memory issues, since the news feed can have A LOT of views, and they all contain images.
Many thanks!
Apparently there is a pretty good chance for you to get an OutOfmemmoryexception in no time with this approach,If you want to go with re-using the views
I suggest you should go with the new RecyclerViews in Android,
Go here for a tutorial on recycler views
I don't know if this qualifies to be an answer. But if you are using a LinearLayout with a header view and a ListView inside it, then there are no issues. Since the main worry you have is the news feed which would be recycled by the ListView. Neglecting to use view recycling is asking for trouble, and will likely break after 50 or so (Android hates images).
As for the header that must disappear. I would avoid putting it as the first item in a ListView as suggested in the comments, and rather have it static in the LinearLayout. And use a view translation and/or transparency to hide it. This keeps the option availible to display the header at any point, regardless of the list's scroll.
Related
This is not a design question, I have the item designed. I am confused on how to pull it off.
I am tasked with designing a view for Android that has a view of a user's post and the comments under it. The post contains some extra information and widely different design from the comments, but all of them need to scroll in tandem, like a web page would (Oh, how I am spoiled by my years of web dev...).
My current solution is to nest a LinearLayout (at the top of the view to contain the user's post) and a RecyclerView (below the post to display the comments) inside a vertical ScrollView. The information is actually displayed, but the RecyclerView, of course, scrolls independently of the LinearLayout above it and ruins the functionality of the view.
I wish, if possible, to keep the RecyclerView in use
The best case scenario would be to have the LinearLayout with the post scroll a certain amount, and then the RecyclerView take over. However, I don't want to poison my codebase with 200+ ugly lines of code to achieve this, so if this is a laborious task to complete, I would rather look for alternatives.
The first thing to understand is: do you really need a RecyclerView, or even better, do you really need recycling?
If the answer is yes, the way to go is two different item types in the RecyclerView's Adapter (for more details, see here or here). This concept was already present in the ListView: the main difference is that RecyclerView enforce the use of the View Holder pattern. It is not so complex, and, more importantly, is the way the RecyclerView is supposed to solve that problem. Depending on your UI design, you may also want to have different view types for different types of comments (plain text, images, ...). Remember that, when the RecyclerView is included in a ScrollView, the recycling won't work, because all the items in it will be drawn at once to compute the height of the content of the parent ScrollView.
If the answer is no, then you could just create your views at runtime and add them to a parent LinearLayout in a ScrollView. It is really nothing more than a for loop.
A more fancy approach would be to use an ItemDecoration for the user's post, but I don't see any specific advantage in this case.
Do we get any benefits of implementing a ListView for which every item would have different layout? Would it be a better idea to put those items into ScrollView with LinearLayout instead?
Intuitively, it seems like using a ListView may still give better performance, though it might be negligible depending on the size of your content. Because the ListView inflates the views as it needs them, it seems like you might save some time by not parsing/rendering views that a user might never see. A long ScrollView with a bunch of views inside seems like it would take additional time when first launched, since the view hierarchy is more complex.
I do think Michael is mostly correct though, that the main advantage of a ListView is that views are reused, which saves on memory/processing. Unless you have a ton of content in the ScrollView, I suspect the performance difference is not significant, and will almost definitely be more complex -- in particular, having to create an adapter that knows how to create each view type for each row.
I don't understand why you may use ListView for this. Listview is a list of common data using the same layout if you click on it. Users depend on same/similar GUI patterns.
How about Sliding Tabs or the newer navigation drawer, link NavigationDrawer.
If you like sliding tabs, then I can give you more details.
Currently, I am having a ListView with different list item view for each row (Most cases Different).
I am having 6 different item layout, I will add more in future, and I will have only like 5-15 list items, some time may be less and may be many in other cases.
Some item views contains:
ViewPager
ListViews
ImageViews
Texviews
Gridviews
CAROUSEL
Webviews
As this is dynamically generated depends on data, I am facing following issues :
Scrolling Slowly (Some Times)
List Item height
Performance
Is RecyclerView the best solution in this case?
Without seeing your code to identify specific concerns, it's hard to address specific reasons why you are seeing such performance problems. Such as, are you properly using the ViewHolder paradigm? Or are you inappropriately loading stuff on the UI thread when it should be loaded on a background thread? Android has a small section talking about scrolling smoothly with a ListView you should check out. That aside,based on what you have mentioned so far...I think you major problem is design.
Problems
If your ViewPager is using a FragmentPagerAdapter...then that will definitely be causing a lot of overhead and performance drag.
ListView: You should never ever place a ListView within another ListView. This will cause all sorts of problems. Android does not like embedding two scrollable widgets that scroll the same direction. Even if this worked, it'll cause some major performance problems.
GridView: Same goes with the GridView. You should never ever place a GridView within another ListView. Even if this worked, it'll cause some major performance problems.
If you're ImageView is loading some large graphics, it should be on a background thread and not the UI thread. Else you'll get some slow performance
Carousel - I have no idea what API this is but if it scrolls vertically, then it's a no go.
WebViews are a very heavy weight object. I can definitely see this guy slowing things down, especially if it's loading a lot of content.
To build off what #Joffrey has said. There are some major concerns in your choice of UI. Based on what you are placing in this ListView tells me that you need to seriously rethink how to display your content to the user. Eg, try using a TableLayout or GridLayout instead of a GridView.
I´m facing the implementation of a View where I have to load perhaps almost 100 items in a list. I have a doubt in which maybe the best way to implement it.
I already know that ListView recycles the views and ScrollView keeps all in memory. The point is that I was thinking in apply paging to the Scrollview to avoid huge loading times when the app inflates all items.
Applications as Google+, Facebook, twitter or Linkedin, Do you think they use ListView?
Thanks
ListView is definitely the way to go. It's easier to use than ScrollView, and a paging system doesn't fit in with the style of android.
ListView is meant to create a list of varrying lengths based of an array of information. ScrollView is for having a (usually) set amount of children in the View (defined in the layout xml).
ListViews do not inflate all items, they inflate however many can fit on a page at a time. Your fastest option, with or without paging is a ListView. However, if each child is completeley different, then ScrollView is the way to go.
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.