I have a RecyclerView which contains one screen full of information per record. I want to restrict user to scroll single record at a time and like to visualize it as if user is viewing one page at a time.
The problem is, I have create a layout of full screen size, and can populate it with data as well. But, on scrolling it gives an effect of as if I am scrolling a role, and on fast swap, it jumps multiple records as well.
I was thinking of ViewPager, but as records size can vary, I don't know how to use it
I have no idea how to solve this problem, please help.
There is an alternative option, instead of using a recycler view you can use this library.
https://github.com/castorflex/VerticalViewPager
It's a view pager but it has an adapter that makes it Vertical, so in that way, you'll have that behavior that you want.
Related
Currently, I am exploring the option of displaying data from a database by swiping left to right and also allowing users add and remove data from any position in the data array.
I found out that there are 2 possible solutions to do this. One is a RecyclerView with horizontal scroll and the other is a ViewPager with a FragmentStatePagerAdapter .
Which is more efficient? In terms of Memory usage and Ease of implementation?
Thanks.
I would say they are comparable in terms of memory usage and ease of implementation. Where they differ most is in the interaction they provide to the user.
ViewPager is designed to show one item at a time. The visible item takes up full width of the ViewPager. You can only swipe one item at a time and scrolling always snaps to showing one item in the centre – you're never left in an in-between position partially showing two items.
RecyclerView with a horizontal layout manager on the other hand can have items of any width – you could be showing many items at once or you could have items wider that RecyclerView's width or you could match their widths to mimic ViewPager. You can freely scroll – you are not limited to one item width or RecyclerView's width, you can do a fling gesture to scroll big distances. And there's no snapping – when the scroll finishes there's no aligning items to the centre or any of the sides.
As you see there are a few differences. I would recommend you to choose your widget based on the UI you want to achieve. If you want ViewPager's behaviour (one item visible at a time, swipe limited to one item and snapping to show the full item) then go with a ViewPager. It's possible but not trivial to replicate this behaviour using a RecycleView. I would definitely say it is way more difficult to use RecyclerView if you want to make it behave like ViewPager. Conversely it's pretty much impossible to customise ViewPager's behaviour, so if that's not what you want then you definitely should use a RecyclerView.
In term of ease of implementation (this is just my own opinion),
ViewPager is good for displaying the list of data that is not required often add and remove since PagerAdapter can't notify each specific item that it is removed or added it can only call notifyDataSetChanged() which notify that all set of data has been changed. Therefore, it is hard to handle the animation when the item is added or removed.
While in RecyclerView, RecyclerView.Adapter has methods like notifyItemInserted(int position) or notifyItemRemoved(int position) to notify that specific the item is added or removed and, the animation when item is add or remove is already handle when you called those method.
Moreover, right now it is very easy for RecyclerView to mimic the ViewPager behavior by using SnapHelper. There is PagerSnapHelper, and the behavior of ViewPager can be obtained with just a few lines of code. You can contact me if you want the code.
There is no comparison between this two. basically in ViewPager you can scroll only one item at time (either left or right), and in RecyclerView you can scroll to any index. it all depends on your requirements how you want to use it. you need to develop fragments for ViewPages, one for each page. as in RecyclerView you will have a item which will be used by adapter. both of them are easy to implement. there are numerous examples on both of them, you can have a look and get started.
I understand we always use listview to display list of items instead of Scrollview. But I know we can do it with scrollview also. I understand that performance of list view is better than ScrollView when you want to display list of items. My question is there are any reason for that also? And why nobody use scrollview to display list of items? Please give me your opinion. Thank you.
I often use Scrollview for displaying a limit of items, this number rarely be changed on runtime, such as in a configuration page. Otherwise, ListView is for display a lot of items. Those items may be the same type such as a list of Students, Messages, etc.
ListView uses a concept of dequeueing that is removing view from the view hierarchy when they are not visible. For example if you have 20 items and only 10 are visible at a time.
The listview will remove the top 1st element when 11th element comes
into view using scrolling. This reduces memory load and gives smoother
performance. Battery consumption is major factor of phone these days
and no one wants a app that consumes all the phone battery.
Scrollview on the other hand keeps all the view added in it in the view heirarchy all the time therefore increased memory usage and performance issues when the number of views added are huge.
ScrollView is used to put different or same child views or layouts and the all can be scrolled.
ListView is used to put same child view or layout as multiple items. All these items are also scrollable.
A scrollview on the other hand is quite different. You add other views to a scrollview which allows you to have more elements than what would fit on screen. Say, for example, you wanted to have 50 buttons or a large chunk of text. By using a listview you have a container that is the size of the screen but allows the user to scroll up and down to see the other views.
I will need to create cards layout mimicking cards found in Google Now. To do so, I've used a RecyclerView and each row as both the header and item. Pretty skeptical with this approach however.
The problem I'm facing is to mimic the swiping behaviour. Swiping at the header will also move the entire card (header + items) together.
To do so, I managed to edit the SwipeDismissRecyclerViewTouchListener and the adapter to remove the affected items. But after that, the visual would get clunky whereby remaining items would have random empty spaces in between or height that does not match.
How and what is the correct way to approach this? Should I instead use another way to populate the cards?
I am creating layouts at run time using heavy data, and adding these layouts to a scroll view. After the view get created, its working fine. The problem here is, the data is very heavy and it takes more than a minute to create the screen, which is not so good user experience. I want to create layouts only for the part of screen that are visible, and rest I can create on scrolling the scroll view. Pls suggest how is that possible? Also, If someone has a better approach, Pls suggest.
You can start by creating only a set number of views each time[1], but always add a dummy 'loading' view at the end of the list if there are more views 'pending'. As soon as the user scrolls the ScrollView at the end of the list, start loading the next part of views on a background thread, and as soon as they are built, remove the dummy loading view, and add the new views into your container.
An other approach would be to start loading the next group of views, as soon as the previous group is done finish, but that might be a waste of resources.
An even better approach, is to combine those two methods described, and always have the next group of views being created, if the user is halfway done scrolling to the end
You can check how to know when the scrollview scrolls to the bottom here: Android: Detecting When ScrollView Hits Bottom
[1] Since you care about UX I would suggest that the number of rows should depending on the row's height and device max height. I.e. 4 views on a small device, 6 on a medium, 10 on a large.
So I have a screen that displays a grid (TableView where each TableRow is mostly TextViews) like a scorecard, with like 8 rows and 11 columns.
I'd like to add about 10 more rows to it, and keep it in a ScrollView. But I'm wondering if I should switch the whole thing to a ListView.
So assuming that half my grid is "off screen" is there a big performance (rendering time, memory usage) hit to just using the ScrollView? Or would I be better off going to a ListView?
Basically I just don't want the thing to lag when it displays the screen for the first time (or during scrolling).
Thanks.
I would use a ListView... It's so comfortable
With a ListView you can easily manage the selected rows. And with the right Adapter you can also write a very efficent List.
You can find a few examples in the Android API Demos
Using ListView and ListAdapter, there is a lot that is done under the hood to ensure that it is efficient, for example, the displayed list items are reused when scrolling rather than creating one for every item.
So yes, I would suggest using ListView along with ListAdapter.