I have fragment in my app that acts as a portal to link to other fragments. The way I implemented this is by simulating a click on the nav drawer, which already handles all the code for switching fragments.
NavigationDrawerAdapter.ViewHolder v = (NavigationDrawerAdapter.ViewHolder) mDrawerList.findViewHolderForAdapterPosition(i);
v.itemView.performClick();
However, I get an error when I try to simulate a click on an item that isn't visible on the RecyclerView's current state. I know this is because RecyclerView only keeps visible views in its array of ViewHolders, but I need the ability to simulate a click on views that aren't in that array.
Yes, I know, I should just refactor my code so that I'm not doing janky things like simulating user clicks on the nav drawer. However, in the interest of time, and an understanding that this nav drawer will never really get incredibly big, as long as there are no other really negative caveats other than memory issues, I think it's the best working solution for the current state of my code.
RecyclerView is intended to recycle Views. If you need to keep Views, use a ScrollView with a vertical LinearLayout.
You can probably scroll RecyclerView, wait for finishing and then simulate clicks. But anyway this whole thing seems wrong.
Have you considered NavigationView?
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 need a component that works like the picture below but I'm having trouble coming up with some kind of decent solution that works.
I want the list to have a center locked selection but being scrollable with the d-pad. This is for an application running on a TV so no need for touch scroll. So when pressing down on the remote d-pad the list will scroll and a new item will size up and the current selected one will size down and the new selection will still be in the middle.
I've tried doing this using a ListView that I extended and programmatically scrolling when pressing down or up. On scroll finished I called notifyDatasetChanged() on the ListView for re-inflating of the childs and in the ListViews adapters getView() I made the animation of the view located at the current selected position.
This is not optimal since I need to call notifyDatasetChanged(), which re-inflates all visible views, for the animation to apply. The UI becomes laggy when doing this and scrolling fast. It's also not possible to make som kind of compress animation when current selected item goes out of selection. There is also some trouble with the end items (read views) such the first or last in the list when doing animation of them, the may sometimes go out of screen.
I think that his must have been done before and maybe I'm missing it when searching for an answer.
Have anyone done something similar or do you have some suggestions of how this can be achieved? Maybe I'm just starting of with the wrong component here..
Regards,
Kristoffer
This has been bugging me for a few days now. I have a FrameLayout and one of the elements within the layout moves to reveal a menu. I can paste the code if requested, it's a bit long since it's my play code and I haven't used any styles. I digress...
When the user presses a particular button it calls a startAnimation on a custom LinearLayout which is layered on top of another stock LinearLayout. Pushing the button again will put the custom LinearLayout back to it's original location, thus hiding the menu.
I had to create a custom LinearLayout to override onAnimationEnd so the layout would stop and stay at the final animated position (I found this based on some other questions asked here on StackOverflow).
The problem arises when the user actually presses one of the visible menu items. One of the items, for example, sorts or reverse sorts the displayed list. It appears that right after I call notifyDataSetChanged on my BasicAdapter the screen redraws itself and my menu is hidden. I have no code that closes the menu, it's almost like the entire Activity is re-created or reset when the list is told to redraw.
I should also point out that I'm extending an Activity not a ListActivity. I'm targeting API 10 (Gingerbread, 2.3) and up.
If any one has any pointers, I would greatly appreciate it. I've been wracking my brain on this for days now and it's driving me crazy. Please let me know if I can provide any more info.
EDIT:
Here's the SO post about overriding the onAnimationEnd method.
Android TranslateAnimation resets after animation
Do you record which item's menu has been opened yourself? If not, then it means that you let the UI system do the remembering for you, which would mean that this information would be lost or rendered useless (since you have changed the item ordering), so all the items reverts to their initial states.
The solution is to associate the menu opened/closed state with each data in the list, then when the adapter's getView method is called, you can rebuild the correct UI state.
I find listView recycles its views too fast.
When my listView scrolls, views falls off the screen gets removed right away.
Each cell(row) has image loaded using universal-image-loader.
Views which fell off the screen has to reload the image when they comes back into visible area. (it shows the stub image for short time period and loads the correct image).
I definately need to keep the view recycling behavior, but can I modify the list view's behavior so that user won't notice constant reloading of images?(maybe I keep 2-3 times of # of views in a cache than a regular list view would)
Unfortunately the code for ListView and friends is horribly complicated by the fact that it's designed to scroll unevenly-sized items without knowing the height ahead of time. That makes it brutally difficult to run with anything but the default behavior. In addition, most of the methods you'd need access to, to easily customize the behavior are hidden or private. It would be a massive job to try and roll your own (across multiple platforms, subtleties of scrolling, flinging, dragging, scrolling, keyboard focus &c).
The best solution is probably to maintain an image cache that fills in lazily around the view positions that are active. Not neccesarily easy. But way easier that trying to mess with ListView.
A very useful API for this is ListView.setRecyclerListener(AbsListView.RecyclerListener listener), which gives you a hook to track which images are actively displayed.
I can suggest you to use a ScrollView instead of the list view. The ListView is designed to display a lot of data efficiently, that's why your off screen items are destroyed. In which concerns the scroll view, once loaded, you will be able to scroll up and down without recreating the off screen objects (because they ill not be destroyed).
See: http://developer.android.com/reference/android/widget/ScrollView.html
EDIT:
If it is mandatory for you to use the listView, you cluld take a look here: How do i prevent recycled ListView items from showing old content?
There is a posibility to override the listView getView method and keep more items not to be destroyed that the number the listView is keeping.
I have implemented a ViewPager in my app, and aside from the swipe paging, I have buttons for "Next" and "Back", with a simple onClick method with the only line being a setCurrentItem for the ViewPager.
While the paging animation is completely smooth during swiping, it is more or less instantaneous (just flips instead of scrolling) when I click Next or Back. There is no visible "scrolling" motion, or sometimes barely visible, however not even close to smooth. It does not hurt the usability of the app in any way, since the transition still happens immediately, but visually it looks a lot less appealing, and the user experience suffers.
Now, I suspect it has something to do with the app drawing the next View and therefore "skipping" the animation. My instantiateItem uses LayoutInflater and a simple switch statement to inflate each view (4 pages at most), and I am loading custom ListViews inside each case in the switch statement. The custom ListViews are at most 3 items long, with a TextView and an ImageView in each row (ImageView resource is 5kb in size). To me it seems this amount of objects should not be reason enough to slow down the paging animation.
Aside from that, I also have a custom background assigned to my app in styles.xml, and this is the background used through every activity (160kb in size).
Those are the only things that I think could be slowing down the app, since the onClick method contains only one line (setCurrentItem), so nothing aside from going to the next view is happening in the app, and the instantiateItem is the simplest implementation of the method possible that I know of.
Things I've tried:
Setting the ViewPager's setOffScreenPageLimit to 4, which I thought would pre-load the views and eliminate any loading in between paging, but in the end setting it to 0 seemed to make the thing slightly more likely to show at least a frame of animation
Optimizing the custom ListViews by using convertView to reuse old views, while it did result in more of the animation being shown, it still wasn't completely smooth, varying from "almost perfect animation" to "instant flip"
Removing the custom background, which together with the above two fixes lead to an almost good enough solution, but still resulted in flips every few steps.
The tinkering described above leads me to believe it has something to do with the views being loaded, but I've not found a good solution for pre-loading these to the desirable effect.
Knowing my newbie programming skills, I know there is a sure fire way to solve this without resorting to gimping the design of the app itself, but reading through the documentation, Stack Overflow questions, Googling for advice, I've just ran out of places to look to.
To sum up this probably too verbally descriptive post my main questions are:
Is there a way to ensure the animation of the ViewPager is executed smoothly? A separate thread perhaps? As I understand though, UI stuff should only be on the main thread, where it already is, and nothing else aside from the view loading is executed anywhere in the code when paging.
Should I be using a different way to load the pages? Would Fragments help?
Thank you for any advice.
ps. The lack of code is due to the methods in question being the most basic implementations possible, but I will provide the code if necessary.