So basically here is the setup I want and this is what I have. I currently have 2 adapters merged into 1 mergeAdapter to get the functionality of stories being the "header" of the app. Now the problem is they are all together inside a recycleview that's vertical. I need the first adapter to be inside the mergeAdapter but have a horizontal layout. I've asked around and it seems that I have to inflate the recycle view inside my header adapter and then use that as the layout, but I have no clear idea how to achieve this.
This is the response that I got:
"Technically it really is in theory "as simple as" inflating a layout that contains a RecyclerView as an item, and setting it up as an item view type. and getting the list to show into that item.
You really just need to create 2 adapters (if you go the MergeAdapter route), where one displays 1 item of a horizontal recycler view, and the other displays n items of the vertical list. Then put the two adapters in a MergeAdapter, now you don't even need to worry about item view types. That's what's thrown people off for almost a decade."
Edit:
To clarify, I have no idea how can adapters inflate anything other than view holders. And how can I inflate a recycle view and then use attach views to it, where do I even create it, how do I hold a reference to it in the adapter? I understand the concept behind it but I couldn't' find any examples that utilize this online so I've had no luck. Basically, if anyone can just describe the thought process behind it but a little bit more concrete, I cannot wrap my head around it atm.
Eg. You'd inflate the recycle view with inflater.inflate(R.id.recycleview) inside the init of the adapter and then store it in a variable to use in bindviewholder...
I have a rather complicated List with nested RecyclerViews. I get it that nested RecyclerViews aren't the best solution, but in my case it is one of few solutions that create structured code and meet the requirements. I have attached an image of the structure. You can take telegram as an example to improve your understanding of the structure. Basically I have an outer RecyclerView RV-1 with Items RV-1-Item and an inner RecyclerView RV-2 with Items RV-2-Item. So far so good, my problem is that the outer RecyclerView recycles views as intended, but if one of the RV-1-Items comes into view, all ViewHolders of RV-2 are created (That means that sometimes more than 100 ViewHolders are created). To sum it all up my question is how to force the inner RecyclerView RV-2 to recycle ViewHolders as well.
I know that the inner RecyclerView RV-2 has to have a hight of wrap_content because it depends in the count of the inner items, also i cannot set setHasFixedHeigth(true) (and I don't know if it would help) because during runtime new RV-2-Items can be added into RV-2. I also tried to set setNestedScrollingEnabled(false) on RV-2 because I read a lot about it online but it didn't help me either.
So basically this is how I configure
RV-1
layoutManager = LinearLayoutManager(context)
isNestedScrollingEnabled = false
RV-2
setHasFixedSize(true)
layoutManager = LinearLayoutManager(context).apply {
reverseLayout = true
}
In addition to that I have some ItemDecorators but they only create the space between the items, so they shouldn't have to do anything with the problem.
To sum it all up:
The outer RV-1 recycles it ViewHolders as intended but the inner RV-2 creates all ViewHolders at once, even if they are not on screen. I assume that this is the case because RV-2 has a height of wrap_content and when the layout_height need to be measured it needs to create all views. THE QUESTION: Is there a way to force RV-2 to recycle its views?
EDIT:
Also I am using a shared RecycledViewPool between all RV-2 RecyclerViews but that isn't really related to the problem, because even if the ViewHolders are shared between the RecyclerViews, an RV-2 RecyclerView shouldn't create ViewHolders that aren't visible when it is initialised.
EDIT 2:
A lot of comments and related questions say that two vertical nested RecyclerViews isn't a possible thing in android, in case all visitors of this question think the same my question is: How would you implement such a structure. It is obvious that I could make a single view which has a IM (Round Image View) and RV-2-Item and just make the IM invisible when it isn't needed. In my opinion this somehow makes the structure more complicated. Furthermore a requirement is that the IM on the left side of RV-1-Item must have the ability to move up and down in RV-1-Item, which is obviously easier with my current structure.
EDIT 3: (My last one I promise)
The Problem I have shown can be solved by using the approche I explain in my EDIT 2, even if it isn't the best solution it would work. But the issue is that I have an even more complex screen where this approche wouldn't work anymore because I have three nested RecyclerViews. I could get that number down to two with the approche of EDIT 2 but I would still be left with two nested RecyclerViews and I cannot think of a workaround that could solve the problem of the remaining two nested RecyclerViews. I attached an image of the even more complex screen which contains a the interface of the app with marked sections to help you to understand the structure.
(Not quite an answer to your specific question in solving "how to not get the RecyclerView to create all items at once", but something that most likely will fix your specific problem by not using nested recyclerviews at all)
I would suggest (in a quite similar way as already suggested in this answer), to flatten your feed into one recyclerview
(No matter how much you tweak your nested recyclerview architecture, imho it will never be as performant than having just one recyclerview, and as you don't need nested scrolling (I guess), just one recycler view should be your best option).
I would propose to not think of your feed in the way your data is structured, but in a way you want to show it and how it can be split into smaller items which are "look alikes" / consist of the same things.
From your screenshot I would see for example the following items / view types for each chat item:
Chat header (the thing with the icon and the text "New Group")
the user badge (the picture with the text "Jürgen")
a message item (one bubble of text, so e.g. in your screenshot at the bottom there would actually be 3 of those items, one for each message)
The section with the date and the action/reply items.
Those items are way smaller than a whole chat item, and therefore can be faster created / recycled.
For each of those items, create a view-type and a view-holder, and treat them as seperate recycler-view items.
The recyclerview will, when the getItemViewType method is correctly used, create / prepare the correct type of view for the position you need.
For this to work, the adapter needs to add some logic, as your data most likely will be structured something like
a list of chats, and each chat has a name and some messages to display
and we need it as
the first 6 elements are for the first chat, where the first position
is the header, the second the user badge, the next 3 items are message
items and then we need an action item.
So you basically need to calculate how many recyclerview items you will need to show each single chat-item, which could be a calculation along the lines:
1 chat header item + 1 user badge item + 3 message items + 1 action/reply item = 6
This calculation needs to be performed for each chat item of your data list separately.
So if you only have this single chat item in your list of data to display, you actually need to tell the adapter to create 6 items (by returning in this case 6 at getItemViewCount()).
Then, you need to tell the adapter using the getItemViewType(position: Int) function, at which position of the recyclerview which type of view the adapter needs to prepare.
So there you again need some logic to say that e.g. on position 0 the chat header for the first chat item should be, at position 1 the user badge for the first chat item, at position 2-4 message items should be, on position 5 the action item and at position 6 the chat header for the second chat should be and so on
(again, the logic then needs to be in place for all chat items, and it can get really messy / complicated, as to calculate each chat items view types for a position, e.g. all prior chat element view counts need to be recalculated, too (in order to know at which recycler-view position your current chat item starts)).
As this tends to blow your adapter up, I would suggest (if you don't already do so), to get some manager / delegate architecture in there.
So e.g. have a delegate for each view type, and a manager which calculates the number of recyclerview items / view types needed for each chat item.
Just for reference:
Some time ago we had a situation similar to yours
(a recycler-view with a design similar to a social media feed, which should show the first n comments in the feed and we displayed the comments for each feed item (which was a recyclerview item) with another recyclerview in the item) and also after some troubles with performance which we could not manage to resolve just flattened the recyclerview, and never had performance troubles again.
A lot of comments and related questions say that two vertical nested RecyclerViews isn't a possible thing in android
This is not true; whoever says this is not a thing has not done it and thinks it's not possible. It is possible, albeit with complications, side-effects, and most likely, the annoyance of your users when they tap around trying to scroll up/down and the wrong touch interceptor wins.
Why is this a problem?
On iOS, when you try to do something that the platform devs didn't think it was good, most people and other devs scream at you: don't fight the framework!!!.
On Android, we see the craziest Java (and now Kotlin) implementations of things that makes you wonder what are we -developers- learning at school and what are we teaching?! and yet nobody says anything (for the most part) :p
The truth is, you're trying to design a complicated user interaction and data transformation, and yet, your attempt is biased by trying to use the data "as you have it" (which implies dealing with these two different RV/Adapters), as opposed to do what one should do: transform the data for presentation.
This leads me to the next question:
How would you implement such a structure.
Well, for starters, I don't know how your data looks like, nor where it's coming from; I don't know what your users can do with your data, outside of the obvious scrolling.
I also don't know how your data wants to be presented, aside from your mock up.
But I do know the situation very well. A list of things, which also contain their own list of things.
Case: The List of List
It is doable; you can have a list and inside said list, have another list. I've done it. I've seen it done by others. I've used it. I also never liked the idea of having this "small" scrollable thing, fighting to see who scrolls first when I tap "the wrong place".
I would not do this. If the inner-list is big (say more than 3 items per outer item), I would not present it as scrollable content.
What I would do (considering the things I do not know about your problem) is to have a single list displaying all the content properly flattened.
This has a issue with your content:
What if the inner-lists are super long, wouldn't this cause them all to be displayed? YES, and that's why I wouldn't do it this way if the data (as you described) can have 100 items. An options is to display the 3 first items with a "more" link to now open the inner-list "full screen"; this is 10 times better than the nested list from a user's PoV and from the technical aspect of it.
Another alternative, is to keep this single long list (RV-1) and let users "expand" the list to launch another full-screen list depicting the contents of RV-2, in a separate window. This is even better.
The time you'll spend implementing this and getting rid of the mess of code you probably have right now, will make you wonder why didn't you suggest this in the first place.
If this is something you absolutely cannot do, then I cannot offer you much more advice, for now you're tied to unknown to me business/product rules. Ultimately, the price will be paid by the users of your app, when they have to scroll that nightmare :)
Take a Step Back
Let me be clear, I am not criticizing you or your solution; I'm merely pointing out that, in my experience, this "pattern" you have here is not a good user experience.
Format your data for presentation, not the other way around. Your data should be properly shaped so it can be properly presented with the tools you have.
You're fighting against the tools Android is giving you; you're giving a RecyclerView (and its adapter) a lot of new problems to deal with when it already has a lot going on.
Think about it: RecyclerViews have to do a lot of things; Adapters must also conform to a few interfaces, ensure things are dispatched as soon as possible, calculate Diffs (if using a ListAdapter<T,V>), etc. Activities/Fragments? They have a lot on their plates dealing with ... well "Android"; now you're asking all these components to also handle a complicated scenario of scrolling content, touch recognition, event handling, view inflation, etc.
All this, while expecting each view to take 16ms or less (to stay above 60 FPS scrolling speed, your view/viewHolder should not take more than 16ms to do all it needs.
Instead, I'm asking you to take a step back, grab the data you have, compose it, transform it, map it, and create the data structure that can better serve the components you have (a RV + Adapter + a simple View).
Good luck :)
I use this timehop stickyheader library to create sticky headers for my recyclerview: https://github.com/timehop/sticky-headers-recyclerview
I have noticed that if there is no items within a recyclerview, the ItemDecorations will not appear. I don't think this is specific for the library I'm using but it applies in general for cases where one is using decorations in an empty recyclerview.
Is there a way to force the recyclerview to display the decorations even though there is nothing in the recyclerview? I know I can add an empty view to the recyclerview and 'force' the decorations to appear but I prefer not to do that.
This is for those use cases when for example, you have an activity that displays an activity feed (like in Facebook where you can see who liked your comment etc) and you want to put a header on the top of that recyclerview that will always be sticky (a header that says "Activity Feed" for example). In the case when the data is still loading on the app, there will be an empty recyclerview so the header "Activity Feed" will not show up.
Short answer: No. Decorations are decorations on the items. If there are no items, there can be no decoration.
So what can you do?
As you already mentionend, a possible solution would be to add an empty view type to the recyclerView. Would be a fairly easy solution, and you could even style the whole empty page. But, you'd need to modify your adapter code, add some ifs and else and it would not really be reusable.
Second possibility, if you have a header like "Activity Feed" just do it like:
<LinearLayout orientation="vertical">
<TextView text="Header/>
<RecyclerView height="match_parent"/>
</LinearLayout>
The recyclerview will then always have that header on top. Those sticky decorations you linked are for the purpose of displaying group headers that change, I don't see why you need that.
Third, if those are not what you want, the last possible solution would be to just extend RecyclerView and add some empty state management yourself. If empty, then show the empty view. e.g. like HERE.
I´m developing an app in which I have a list of products, sometimes are a huge list and other times are only one or two items.
I read this items from a local database, right? ok, when I have about 20 o 30 items, I think the return is very slow, it takes one or two seconds rendering items and I need to know the best practices about that.
I have tested two ways:
The more tricky (I think), is creating views programmatically and adding to the scrollview as childs of the linearlayout inside.
The best for design: having an item-theme in a xml and inflating once by each item.
Is there a better way? I´m sure yes!
My items are a little bit complex:
image, name, category, provider, price, some buttons with "onclick" listeners, two little icons. Everything each item.
It is very important for me to speed up that process.
you can use listview and use the attr :
android:descendantFocusability=”blocksDescendants”
it can make your item widget respond some click or touch
My first thoughts on what you described are:
Create an xml layout for the listing
When you get the full list of items, store listing data somewhere
Inflate 5 (or 10 or whatever a reasonable amount of might be) listing layouts into the scroll view and use the data to fill them
Use a listener to check when the user has scrolled to the bottom of the scroll view... or halfway down or whatever you choose
Inflate the next set of items if they exist
This should prevent the slowdown and if you implement it correctly the user won't even know they aren't all loaded.
I think you need to implement a scroll view type to do this... do some searching for the scrollviewlistener.
It should be pretty straight forward.
I found the answer. Really cool.
I'm trying to tackle a problem that seemingly many Android developers have, which is how to intersperse lists with non-list data, in one big scrollable pane.
The model I have in mind is the screen for an individual app in the Market. You have a big description, a list of a few lazily loaded comments, and then some individual items that do different things, like visit the developer's web page, call them, etc. And then in between them all, are nice section headers.
Emulating this approach seems to be extremely hard. I've read enough SO answers and mailing list posts to know not to put a ListView inside of a ScrollView, but I want the same effect without using addHeader() and addFooter() with very complex header and footer views.
I've tried using a LinearLayout that I stock with views myself, but I can't get the pleasant click effects that default list items have (the orange background, white for long-click, etc.).
What do I do?
Take a look at my MergeAdapter, which is designed to handle scenarios like this.
Why not use a header? It's easy. Define the header contents in a separate layout. Your activity layout contains nothing but the ListView that you want at the bottom. No scroll view!
Then call
View headerView = getLayoutInflater().inflate(R.layout.header_layout, null);
ListView listView = (ListView) findViewById(R.id.my_list_view);
listView.addHeaderView(headerView, null, false);
It's crucial to call that form of addHeaderView so that the header is disabled. Otherwise, it can be selected, which looks totally weird.
Mark's example would work. basically you need an adapter with different view types. Another nice example is
http://jsharkey.org/blog/2008/08/18/separating-lists-with-headers-in-android-09/
which might work better than Mark's because you want to have separators and group things together.