Building an infinitely scrollable calendar-like view in Android

Question

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.

Puck

Answer 1

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

Firewarden

I think you understand my dilemma, and I'm on the same page as you are. There is nothing out there that does exactly this. The "infinite" scrolling examples out there are merely concerned with loading more items, and that's not the problem for me - as you point out so eloquently. I still feel that, of the choices out there that are available right now, RecyclerView with the layoutmanager and the itemdecorations are probably the best option before attempting to change the way ViewGroups work on Android. Thanks for the input. – Puck

You could look at source code for Google's calendar and see how they did it -- I updated my answer. I'd like to have something more generic that can scroll bi-directionally for more than just dates. – Firewarden

Clear explanation.. I hope Android UI team build a UI component for infinite item adapter with relative data model. – Tanh

By the way Google Calendar uses a ListView - that repo link is awesome.! – Thicken

Answer 2

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

Candlepin

I think you missunderstood my goal a little bit, that's my fault since I should have included a sketch of what I'm trying to figure out. But thanks for the feedback. – Puck