I'm trying to prevent my ViewPager's PagerAdapter from destroying Views it already loaded once.
If I understood it correctly, the method ViewPager.setOffscreenPageLimit(1) will create and cache a page on each side of the selected view.
This is okay for me, except for the part that if I for example jump to page 5, pages 4 and 5 will be created and cached, but pages 0 and 1 will be destroyed.
I've tried commenting out everything in my pager's destroyItem() method, and caching in a HashMap the views created in instantiateItem(), and returning them as-is if they are found on the HashMap.
This seems to be working OK, but I'm not sure if there are any downsides to doing that this way, apart from the higher memory usage, which is hopefully not a problem here.
My app is actually an application framework and I'm going to leave that decision to the final developer, leaving ViewPager's default behavior in case he/she doesn't want to apply this caching behaviour. Some clients are pretty unreasonable and they have a huge number of views in everypage. I've tried to convince them to work their way around in different pages since Android's View creation is costly, but as I said, they're unreasonable.
Do you guys know of any good way to do this?
Related
I have a RecyclerView (1.2.1), with a List adapter, and ViewHolder, backed by a Room PagingSource. There's about 700 items on the list. The paging seems to work fine, and I've flattened my View hierarchy as much as I can.
Upon initially loading the recycler view, everything seems fine. Paging works, everything seems snappy. onCreateViewHolder in my adapter is called 14 times, and initially 5 are visible on the screen.
Slower scrolling is fine (it does call onCreateViewHolder more often than I expected, but there's no jank).
The problem comes when rapidly flinging through the list. After 3-5 fast flings, it appears to decide that it needs to have more cached view holders, and makes many, many calls to onCreateViewHolder - this method is clocking in at ~5ms, but there's just too many of them, and the scrolling stops. It appears to call onCreateViewHolder ~700 times - the same as the number of items on the list, like it's not recycling the views at all.
At that point, sometimes the app will recover, and at that point everything is smooth and it doesn't appear to need to create more ViewHolders. Sometimes however I will get the ANR dialog.
I've tried tweaking the recyclerView.recycledViewPool.setMaxRecycledViews(), but this doesn't appear to to increase the recycledViewCount until after the mass onCreateViewHolder calls.
Is there anything I can do to resolve this? Make the fling speed slower? Tune the view holder recycling somehow so that it doesn't go nuts and try and create so many at once?
I don't think I can get the layout inflation any better, given my design and data constraints. And even if I could, it's still creating waaay too many to be able to get them done in under 16ms!
In my situation, I needed to do 2 things. First and foremost, I needed to adjust my paging configuration. My prefetchDistance was too small in relation to my page size! This got rid of the ANR - no more mass creation of ViewHolders!
The recyclerView would still pause scrolling when loading a page (especially towards the end). I added a loadStateFlow collector that handles showing a loading indicator so that the user knows there's more data coming.
I have activity with two tabs. Both tab uses different fragments. When a particular event occur like user click on item, I am opening another fragment in same activity.
I know how to add fragment dynamically and I also know how to animate it.
Here, how I added fragment to frameLayout in my activity:
transaction.setCustomAnimations(R.animator.object_slide_in_up, R.animator.activity_hold)
transaction.add(R.id.flSellerHome, fragment)
transaction.commit()
Everything works fine in emulator and newer phones. I have tested with emulator with api 25, it works fine now flickering occur, When I am testing it with real device with api 23 it flicker little, so it doesn't affect, after then when I tested it with api 19, it flickers too much.
So my question is any best practise for doing animation.
Notes
My third fragment which is dynamically added contains recylerview with around 20 items from local db, and I also done db fatching in background thread.
No loads on main thread. recyclerview is also simple with one Image and three texts.
Image is also loaded using Glide and also I have override function of glide**
any help is appreciated..
I found problem is with recyclerview data updation.
I am loading data in background thread, but when notifying recyclerview, it stucks for small amout of time.
So what I have done is. I have delayed data load for same amount of time which is for animation.
I don't know it is good idea or bad idea. But it is too late for my project so I used this workaround.
I wanted to write comment to your answer, but I dont have enough rep, but I want try to advice you something, so sorry for this.
I am loading data in background thread, but when notifying recyclerview, it stucks for small amout of time.
Try to start loading, which you did, after click and show simple ProgressBar, and when data is loaded, hide progress bar, set info to your fragment and then show fragment. Then you will have all data wich you need in fragment when it is attached and can put it (data) to your adapter.
It have to look good.
If it occurs only for API 19 and lower, it may be a lack of performance from the device.
Maybe the problem do not come from Fragments and Animations, but from another functionality which slow down the UI thread. By functionality, I mean the way your fragments communicate together. Do they share a huge amount of data ? Or heavyweight datas ? If so, you should use Async Tasks or Threads.
Good luck !
I have a mix of 10-15 custom views and fragments to be shown in a vertical list. I am not sure if RecyclerView has any advantage in scenarios where all views are dissimilar. RecyclerView seems to add lot of boiler-plate code, and I think the only advantage I would get is easier enter/exit animation.
My custom views/fragment also make web-service call on being created. We don't cache web-requests for business reasons. My understanding is that RecyclerView would trigger these web-service calls on each binding, resulting in redundant calls and visible latency. Comparatively ScrollView should load the views once, and it keeps them all in memory, avoiding multiple calls.
Is my understanding correct ? I need some help understanding performance implications with ScrollViews, in the given scenario.
ScrollView
With a ScrollView, all of its subviews will be created at once, regardless of visibility on screen. If using a ScrollView for your solution, you'll probably want to "listen" for when its subviews become visible to update their content, using placeholders initially. You could also build something that will fetch the content in a background thread. This may get more complex than you want very quickly.
RecyclerView
A RecyclerView provides the advantage of deferring creation of child views until they become visible automatically, and can re-use child views with common layouts.
By using different "item view types" for each of your children, you'll disable the "recycling" part of RecyclerView, but still get the benefit of deferring the creation of views until they are scrolled into view.
RecyclerViews do provide a fairly structured pattern for you to work with via the Adapter and ViewHolders. Though not personally familiar with it, RecyclerView also has a RecyclerView.ViewCacheExtension which is intended to give the developer control over caching of views.
Overall, the advantage of late binding (don't create and load views that might never be viewed) and the flexibility of the RecyclerView will probably yield good results for you.
First of all you have to decide what you are using View or Fragment or maybe both. Don't compare View with Fragment there is a common misconception about these two, they are not similar, actually a Fragment is close to an Activity in terms of architecture and implementation.
Second, can you reuse some of these View/Fragment, if yes, then RecycleView can help you a lot.
After you decided about the topics above:
My understanding is that RecyclerView would trigger these web-service
calls on each binding
No, this is not true, the binding method is called whenever a new item is displayed (reused or newly created), you can implement adapter to perform the web API only once on an item, this is your choice.
I always go for RecycleView/ListView whenever possible, it helps to reduce the memory footprint and can reduce the implementation. In some cases, where there is no huge memory usage on views and I can't reuse some of the implementation, then I go for ScrollView, but I think twice before implementing it.
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 noticed today that the PagerAdapter gets called a large amount times. I counted 393 when scrolling pages slowly. I saw this question but it didn't really provide me with a good answer.
Is this normal behaviour
If so, why is it that the getCount method is called so often?
Just to be clear, I am looking for a more extensive answer then the one in the provided question.
I do also realize that I need to keep it as fast and that I have no control over how it is called, but that is not the question here.
As you concluded it is used a lot in onTouchEvent. OnTouchEvent is called whenever you interact with the screen, meaning touch move and release events. Moving just one pixel would result in a potential call to this method.
There is not much more to explain, it is just the way it is implemented. Usually adapter.getCount is implemented with something like List.getSize or Cursor.getCount. And has almost zero overhead. If this is a problem, optimize you ListAdapter.getCount method, cache the count or something like that. Only do complex stuff in there when needed and cache the result until it becomes invalid.