In Android, I'm doing the new Jetpack compose and trying to figure out the equivalent of sharing a viewpool across recyclerviews.
If an app has multiple recyclerviews with similar content, then you can really speed up performance by sharing the same view pool across your recyclerviews. You can create a view pool, customize it, and then set it to each of the recyclerviews. This is something I'm used to doing.
In Jetpack Compose, instead of recycler view there is LazyColumn or LazyRow. How do I share the views or compositions across different lazy lists?
There's no such functionality available as of the current stable version, i.e., 1.1.1. You can, however, take a look at LazyLayout. It is currently available in the alpha versions of Compose, and can achieve what you require (AFAIK) if the layouts are close to each other. Basically, it will be a single Composable, which you handle the contents of, yourself. If the lists are right next to each other, just create a single LazyLayout, create two lists, add the same source to both, and you're all done. If you want to add some other Composables between lists, you'll need to merge those with this one, and render them inside the lazy layout. That's what the Compose team would likely go with, but you know... well actually you never know.
Related
I've been having fun digging into Jetpack Compose. Here I used Rows, Columns, and Spacers to build this screenshot. Is there a better-suited Composable I should try?
I couldn't get LazyVerticalGrid to place the jellyfish in its position. It wants to put it on the left beneath the black dog, which leaves a blank space and pushes the brown dogs onto their own line.
I also tried Accompanist's FlowRow, which draws the same arrangement as LazyVerticalGrid. It's also likely I'm not familiar enough with the API of either.
Later I want to learn drag & drop to reorder the items. Are there considerations to make as I'm setting up this widget to make life easier? In my head it seems like these individual Rows and Columns could get in my way, maybe it has no bearing though.
Thanks for any insights!
I made a custom Layout instead, which allows for measuring and placing content. 🤞🏽
Google jetpack compose pathway has a lesson on custom layout, but i think you can use a Lazy Grid, it makes it easy to work with grids.
Link android developers Lazy Grids
if you click the lazy vertical grid link you'll see that you can have multiple rows of items with different modifiers and number of grid cells.
I would love to give you a working example, so I will probably edit this soon.
I am trying to achive this:
First I tried by putting all my recyclerviews (with WRAP_CONTENT) inside a nestedscrollview. That worked, but the performance was awful. Then I tried to set a height for my recyclerviews, that was a lot better (especially the first gridlayout and the horizontal linearlayout loaded very fast), but still had the problem with the dynamic "category" part.
Now I am trying to put all my recyclerviews inside a single recyclerview with different viewtypes. Since that is a pretty big deal (I need to refactor a lot of code because I have diveded every area from the screenshot inside a single fragment and now I need to put all that code inside an adapter) I wanted to ask if I can actually expect any gain from this, because in the end its again a "nestedscrollview" (made by myself, but...). Or if there is some other "best practice" way to achive this layout.
Thank you
Edit:
As expected this didnt do the trick neither. When just the two first recyclerviews are added as viewtype it scrolls and loads smoothly. But as as soon as I try to add the category items (below the category), I notice a lag and especially when selecting multiple categories and scrolling fast up, there is noticable lag. I guess I will have to change my layout and move the category selection part inside a separate view, just need to come up with a user friendly solution. But its acutally quite dissapointing that, in my opinion such trivial task, laying out multiple tables, is such a pain in the ass on android.
I didn't manage to get it working with standard android stuff.
Now I am using epoxy from airbnb ,and I have converted all my views from nestedscrollview to the epoxy recyclerview. Its a great library, and airbnb use it too for all their views.
Nevertheless it's sad that the android dev team doesn't address this problem and provide a solution besides the info "don't nest multiple scrollviews(recyclerviews) that scroll into the same direction".
You can use Recyclerview in recyclerview.
https://irpdevelop.wordpress.com/2016/02/10/horizontal-recyclerview-inside-a-vertical-recyclerview/
And make sure to use multiple view types.
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.
I just would like to ask if these Layouts can hold fragment/multiple fragments. I base this on google play store.
Sorry for bad logic.
Yes, scroll views can hold multiple fragments.
However, managing the fragment stack gets tricky.
Because fragmentManager/ChildFragmentManager will only maintain stack for one container, if I am not wrong.
As long as you don't add them dynamically in run time,it is easy.
i.e. if the fragments are described in the scroll view from xml layout and you don't perform fragment transactions, you are all good.
I have dealt with the same issue, and cost me a lot of trouble but I did implement it. However, if you end up with such a requirement, you might be doing something wrong give other solutions a go and see if you can avoid this requirement.
NOTE : I don't think Google play uses fragments in Scroll Views.
What I see them do is have RecyclerViews within recycler views, if this is what you are talking about
i.e. There are Horizontal RecyclerViews within Vertical RecyclerViews.
In case you are not aware, RecyclerViews are the new version of listViews, they are more powerful and perform way better.
I suggest you don't use listViews, but use RecyclerViews instead.
I want to implement a schedule-like overview as List and as Grid View. Currently this works using a RecyclerView and swapping out the LayoutManager at Runtime. This works fine in general, but as soon as I tuned the grid cells to have a fixed height, I realised that the RecyclerView does not respect the wrap_content layout property and instead introduces whitespace between my grid items.
I then stumbled over more or less the same question for the linear LayoutManager and the third-party provided specialisations of the LayoutManager. A quick searched revealed nothing similar for the GridLayoutManager and I am beginning to suspect I am going down the wrong road:
Apart from the easy switching between layouts, there seems to be no reason for me to work with a recycler view:
I dont't require any special animation stuff.
My adapter returns a fixed list without loading more items on demand.
Actual recycling of items doesn't even take place.
So I am currently evaluating to simply switch to separate Fragments using an ordinary ListView and GridView. But this does feel a little like working against the intentions of Android ... After all, they introduced a single view that (in theory) should exactly do what I need.
Am I missing something obvious that could turn out to be painful when using those "legacy" Views to get the job done? Or are there maybe other, more specific Views that allow switching from linear to grid layouts apart from the RecyclerView?
If this should be of importance: I am using Xamarin.Android, not native Java. But I would be willing to port some code from Java to C#.
Follow this ticket:
https://code.google.com/p/android/issues/detail?id=74772
It is not merged yet but soon should be merged and WRAP_CONTENT support should be available in the next version (23.1.1+) or the one after.