This question might seem common to you, But I didn't find any compelling answer, So I brig it up and hope you can help.
If we have a large number of items to show in a RecyclerView, And by large I mean really large like thousands (but not at the same time), Scrolling from first item to the other items will be a real pain because of many items we have to navigate.
Possible Solution: At first look maybe breaking items to smaller parts and use of a SeekBar or a group of Buttons (like page number buttons on stackoverflow questions page) in order to choose each part(page) to review seems like a not bad idea.
Question: I'm curious is there any better and clean way to achieve this? Did android predict any tools or solution for this type of issues or it's up to developer like the solution I mentioned before?
Any advice means a lot to me and I appreciate that.
What you are looking for is called pagination. Do not query for the entire 1000 records, query for first 20 and when recyclerView is scrolled to the bottom, query for next 20. It is standard way (in list or gridview too)
You must modify your service endpoints or database query to support this.
Related
I want to create 3 level RecyclerView like tree view in kotlin. Is there any tutorial and suggestions please let me know.
I already tried so many times with ExpandableListView and 3 RecyclerView, but didn't find any proper solution.
By a multi-level RecyclerView, do you mean a RecyclerView with paths to different lists that branch depending upon which item has been selected? If that's the case, I would honestly recommend using a single adapter to cycle through multiple lists depending upon user input.
If you have a root list containing two items, each of which opens up its own list with its own unique set of data, you can easily implement code that notifies the adapter of which item in the root list was selected. From there, the adapter can update and switch the view accordingly. This can be applied to series of lists ad nauseam if you so choose, though I can't say I would recommend this kind of method for incredibly complex webs of lists that interact with each other.
Like Ircover said in their comment, I don't think a tree is necessary in this situation either, if only because (1) as stated, it isn't really best practice to do so for the kind of application you're making, and (2) it may unnecessarily over-complicate whatever you're trying to achieve with these branching paths in the first place. If you're willing/able to provide more information about what you're trying to do here, that may help others help you more precisely than I can :)
Full disclosure here: the blog post linked above is not a direct match that will solve your problem - it pertains specifically to displaying different types of data sets (from data classes and what have you,) but employs code that shows how different sets of data can be switched between in a single RecyclerView. Even if it isn't a god-sent solution or is only halfway helpful in solving your problem, I think it can provide some useful information to you.
Maybe a slightly dated question but looking into the same concept and I located this page https://blog.usejournal.com/multi-level-expandable-recycler-view-e75cf1f4ac4b .
They have made a single adapter class to take care of all the navigation and so far seems to be the least complicated example of an expandable RecyclerView, though not in kotlin.
This is not a code problem, I interpret the guidelines as that being OK.
I've been researching a way of building an infinitely scrolling calendar-like view in Android, but I've reached an impasse.
Right now my dilemma is that most of the similar views available have their children placed relative each other in a recurring style. With this I mean:
item 4 comes after item 3, which comes after item 2, and there is constant padding/margin between all items.
What I need is a way to produce an infinitely long scrollable view that may, or may not, contain items. The items should be placed at variable positions within the view. The best way I can describe a similar looking view is a one-day calendar-like view that is infinitely scrollable.
So far my best two bets are using the new RecyclerView with a custom LayoutManager (this seems very complex and still not perfectly documented by Google though). I like this approach because, among other things, it is optimized for displaying large sets in a limited view.
My other solution would be to build a completely custom View. However, with that solution I loose the adapter unless I build a container view (which is probably more complex than building a layout manager).
How would you go about solving such a problem? Tips are appreciated, I don't need code examples, just ideas which path is the best to solve this problem.
Thanks.
Apologies if I've misunderstood the guidelines
Edit: How I resolved this problem
My first solution to use RecyclerView with a special Decorator seemed promising, but it remained a "hack" so we decided not to go for that solution since we were afraid of the complications that it would create down the line.
To solve the problem I went with a SurfaceView instead of an Adapter, this means having to rewrite all the adapter-functionality for my SurfaceView but it seemed to be the best way of solving this issue of very custom drawing and layout managing for my use-case.
It still would be nice to build a custom Viewgroup that can handle this kind of layout problems.
ListView and ListAdapter are based on a fixed list, so the current infinite-scrollers just keep adding more and more data to the end of the list.
But what you want is scroller similar to Google's Calendar app which has a bi-directional infinite scroller. The problem with using ListView and ListAdapter in this case is that if you add data to the front of the list, the index of any one item changes so that the list jumps.
If you really start thinking about this from the MVC perspective, you realize that ListAdapter does not provide a model that fits this need.
Instead of having absolute indexing (i.e. 1, 2, 3, 4, etc), what you really want is relative indexing, so instead of saying "Give me the item at index 42" you want to say "here's an item, give me the five items before it". Or you have something like a calendar date which is absolute; yet — unlike your device's memory — it has effectively no beginning or end, so what you really want here is a "window" into a section of that data.
A better data model for this would be a kind of double-ended queue that is partly a LRU cache. You place a limit on the number of items in the structure. Then as prior items are loaded (user is scrolling up) the items at back end are pushed off, and when subsequent items are added (user is scrolling down), items at the front are pushed off.
Also, you would have a threshold where if you got within a few items of of one edge of the structure, a "loadNext" or "loadPrevious" event would fire and invoke a callback that you set up to push more data onto the edge of the structure.
So once you've figured out that your model is completely different, you realize that even RecyclerView isn't going to help you here because it's tied to the absolute indexing model. You need some sort of custom ViewGroup subclass that recycles item views like a ListView, but can adapt to the double-ended queue. And when you search code repos for something like this, there's nothing out there.
Sounds like fun. I'll post a link when I get a project started. (Sadly, it won't be done in any timely manner to help you right now, sorry.)
Something that might help you a little sooner: look at Google's Calendar implementation and see how they did it: Google Calendar Git repo
What you may be searching for is a FragmentStatePagerAdapter , where you can implement a swiped view, meaning when the user (for example)swipes to the right, a completely new view is displayed.
Using a FragmentStatePagerAdapter , you can handle a huge amount of views without overflowing the memory, because this specific PagerAdapter only keeps the views' states and is explicitly meant to handle large sets of views.
Keeping your example of a calendar, you can implement swiped navigation between for example weeks and generate the week views on demand while only keeping for example the year and the week's number as identifiers.
There are plenty of online tutorials for Android, maybe you have a look at this one
I would like to know what is the best and most efficient way for both the user and developer(me) to display more than 100 items. Right now I have them all in a ExpandableListView. Every group carry's 11 child items(there are 10 groups). This is not being pulled from any database and is all static information(images textview's). I'm trying to design this so the user can get to information quickly. If anyone knows a better way to do this, please share.
So it sounds like you have a pretty simple set of data you wish to show the user. And seeing that you need to show 100 or such items, there's not many options when it comes to efficiency for both user and you.
ExpandableListView is def a good choice. It'll allow the user to select which portion of the data to view at a time. It's not hard to get one rolling either. Android provides a very basic SimpleExpandableListAdapter which is good for displaying static data. The most difficult part in working with it is assembling your data into the format it requires.
Another alternative is some sort of Tabbed display. Selecting each tab would load a new ListView of data. Basically the tabs here would be equivalent to the groups in the ExpandableListView. This could allow for showing more items within each grouping because the tabs would only span one row across the screen horizontally. You could implement different ways but here's a link which introduces and walks you through one. From the user perspective, this approach is merely a change in look and feel really...it's a bit more involved for the programmer to implement.
So I did some research and testing of using a listview in a scrollview, and as a lot of people may know this is supposedly bad to do, since they both scroll. It also means I can't show the complete listview as it will wrap to be smaller.
I have seen places which re change the height of the listview to fix this problem but again most people say that it isn't preferred.
What I would like to know though is what is the preferred way of making a nonscrollable listview like view? Basically I want the exact same as the listview but obviously non scrolled and the height based on its contents. I would prefer to work with the layout in as much XML as possible, and I would like to be able to send my array list to it to view on screen. Unfortunately either my search skills are quite dull, as I haven't been able to find anywhere that really explains the preferred method so I thought I would ask here.
Thanks for your help.
<>Clarification Information
I thought I would put this here in case it will help, first off I basically want to show an image, with a list of comments (each one has an author and a text) below it, the comments themselves are obtained from an array and can change. I want the whole page to be scrollable though so I can either view more comments or go back up to the image.
Using a RecyclerView and an adapter supporting multiple item types you could make a list which shows an image on top and several comments below it. Generally you'd have to check what item corresponds to each position - in your case on position 0 you have an image and in every other position you'd have a comment. Then in your adapter's onCreateViewHolder and onBindViewHolder you would check the item type and handle them differently.
You could take a look at this answer for a short example.
Let me know if you'd need any other details and/ or sample codes to get the idea. :)
I'm new to Android programming. I wonder how many items a ListView can store? I search in docs but they don't talk about this. What if I put a lot (maybe 10k) items into a ListAdapter, will it affect to the performance?
Cheers,
MK.
The ListView is virtualized in Android. Practically speaking, that means that there's no actual limit for the number of elements inside it. You can put millions of rows inside the list and it'll only allocate memory for the currently visible ones (or a few more tops).
Check out the dozens of tutorials regarding writing a custom Adapter class for an AdapterView (ListView extends that). Also check out the Google I/O 2010 session on ListViews; it's really useful: here
There's no limit as the ListView only renders items when they come into view, and so only cares about the data for the ListView when it comes to render the item (though it needs to know the quantity of items to render the scrollbar correctly)
The Google IO video really is great for learning about ListView
http://www.youtube.com/watch?v=wDBM6wVEO70
That said, I'd ask whether you SHOULD load that many, as clearly the user cannot look at them all and scrolling around a ListView with that many items will be very tedious. If it was me I'd be asking some questions:
Does the list need to show them ALL initially? Can it just show the most relevant set? The nearest/biggest/smallest/best/etc
Rather than load them all at once, can you load blocks in pages of items? So for example you load 10-100 initially, and when the user gets to the bottom show "Loading more..." with a progress spinning icon, and pull more in, then the user can choose how many to load, and how much scrolling they are prepared to do
Should you be building a UI to filter the items so there's never a need for them to look at 10,000?
More on ListView
http://www.softwarepassion.com/android-series-custom-listview-items-and-adapters/
http://developer.android.com/guide/topics/ui/binding.html
http://www.androidguys.com/2008/07/14/fancy-listviews-part-one/
Integer.MAX_VALUE since most of its functions will break as they rely on int position.
I created a ListView and used Integer.MAX_VALUE as the number returned to the adapter for the number of items in the list. This had no effect on the performance of the ListView even though it was holding about 2 billion items.
I think 10k will work :P
Check out my answer here to see in detail what I mean : How to create a closed (circular) ListView?
You have a memory limit (which is device specific). As long as you don't exhaust your memory limit, you can store as many items as you wish. There are ADT tools that you can use to monitor how much memory your application is using at any moment.