I have an "infinite" recyclerview that every time the user scrolls to the bottom it loads more data.
I start with 5 items, and if i keep scrolling down i can have thousands of Objects added to the adapter's ArrayList.
What is the preferred way to manage this? Cause i assume that having an array of this size is not ideal!
Related
So I set out to do a simple interface with a search field, a couple of "tabs" that represent data categories and a CollectionView to show the data as the figure below
During development I noticed that when I set a tab that had more data, the loading would take a longer time (too long), and everything would kind of get stuck waiting for it to respond, so I started making some tests on how the CollectionView gets populated (via the ChildAdded event) and here are my findings
In most cases the CollectionView will load Childs that fit in the view (in my screenshot for example it would only load 4 children), and everytime you scroll it will load the appropriate number of items to fill the screen. This happened when the collection only had this types of ancestor Elements - ContentPage, Frame, RefreshView. ScrollView, TableView, Grid (if not set to Auto), HorizontalStackLayout, FlexLayout, toolkit:DockLayout
However there are other cases where all the childs are loaded right away, this happens when the CollectionView is the descendant of this types - ScrollView, VerticalStackLayout, StackLayout, AbsoluteLayout, Grid (when set to auto)
Does anyone have any idea why this happens?
Also is it possible to make it load a fixed number of Children each time, let's say instead of loading enough items to fill the View I want to load 10 items (note that loading the data incrementally with RemainingItemsThresholdReachedCommand for example, only loads the data into memory, and doesn't create a child item in the View)
Note this tests are not exhaustive and there can be other combinations of ancestors/configurations that have different results, and they where only done with Android emulator
I have a use case where I have a sidepanel containing Searchbox, Some MessageBoxes and two lists which get filtered when user searches for something.
The searchbox and messagebox occupies the fixed height but I want both the lists to occupy equal height and grow if the browser resizes.
Also would be nice to shrink the list if there are less items in one of the lists to give more room to the other one.
Here's what the UI looks like...
I'm currently trying to calculate the height and assigning the height to both the lists manually on browser resize event but I was wondering if there's a better way to do that.
Thanks in advance :)
Use a Stack component, specifying the grow attribute on the Stack.Items that wrap your lists.
https://github.com/microsoft/fluentui/blob/master/packages/office-ui-fabric-react/src/components/Stack/examples/Stack.Vertical.Grow.Example.tsx
I'm using performBatchUpdates: to insert a new section to my collection view. This comes with the default fade in animation that I'd like to keep. The item I'm inserting is always the last item, so I'd like to offset my collection view to the bottom to make it visible.
Right now I'm able to achieve this by using scrollRectToVisible: in the completion callback of the batch update method. However, by the time it scrolls, the fade in animation already happened out of frame.
I'd like for both to happen simultaneously. Is this possible?
One approach I've tried is pre-calculating the new size manually ahead of the updates and scrolling first, but then the cells get reused right on screen, appearing and disappearing, which is not ideal.
Any ideas?
Initially I was under the impression that it uses the table row slideup/down animations while inserting/deleting new rows but I doubt if it's doing that as it does it so fluidly even with thousands of items in the list (otherwise it would take a lot of time for the deletions/insertions to work).
Am I right in my assumption that it's simply attaching a new instance of the News list at the bottom of the screen, shrinking the above one while the one at the bottom expands to fill up space?
UPDATE:
Please see this video of what I mean: http://dl.dropbox.com/u/4960327/ReederAnim.mov
I can not tell you exactly how Silvio Rizzi made this, but as you see in the playback, a list view is added behind the shown list view, and the front list view fades out (.alpha = 0.0;) while the list view behind it expands its height per row.
When you desicate it frame by frame it becomes quite clear what he does, and it is really not that advanced. But I have to admit, with the white "milky" polished interface, it looks quite neat.
In addition, you can see that while animating, the background list view only renders the top 7 entries (hopefully calculated by dividing the view height with the average height of the cells shown) making the list view quick to load. Then afterwards, he can load an extended array of cells once you start scrolling, or in a background thread starting once the animation is complete.
Is it posible to use table view to show just one row of a big amount of elements? What I'm looking for is for some kind of horizontal list, like we have in XCode preferences or Aperture image list.
It would behave just like a one columnt table view, but instead of showing the elements vertically, it should be horizontally.
Can you point me to where should I start from?
If you're okay with Leopard-only, The new NSCollectionView supports horizontal display. Just set the collection view's number of rows to 1 in Interface Builder; it'll even handle the horizontal scroll bar for you. The IconCollection sample code provides a simple demonstration of how it works. It's bindings work similarly to a table view's, except instead of rows and columns, each object represented gets an 'item' (an object of type NSCollectionViewItem) that displays it, and those items will be laid out in a grid. The sample code above demonstrates how to set up these 'items' in Interface Builder, which is definitely the easiest way.
With a table view? No. If I'm understanding correctly what you want, in the past I've created my own NSView subclass for this type of control. Define a data source protocol similar to NSTableView, and in your NSView drawRect method, draw the elements in order one by one from left to right. You can either keep track of paging in your control, or put it in a scroll view and resize yourself whenever the number of items changes.
Usually this type of thing starts off pretty simple, and gets a bit complex once you start handling caching, paging, selection, mouse and keyboard input and so on. My advice, start as simple as possible and add new features one by one, only after you've finished the previous task.