Events page should be infinite paged list

[tasomaniac]

Chapter's Event page currently only shows the future and past events within 3 months. When we scroll to the bottom it should infinitely load the past events of a chapter.

Hub APIs supports paging.

[lucasxas]

Is it anyone working on this? I might give it a go this weekend!
I'm thinking 20 items per page, loading more as soon as you get to the bottom of the page.

Any other recommendations on how to approach this issue, @tasomaniac? :)

[friedger]

@lucasxas Hereby, it is assigned to you :-)

There are more information about the hub API:

• https://hub.gdgx.io/developers/api
• Document API features hub#85

You can also think about a different way to deal with past and future events, maybe have two tabs or at least a header/break inbetween.

[tasomaniac]

👍 we also have in progress label. We are trying to use it when we start working on an issue.

Let's split past and future events into 2 lists. Currently it is just a sorting.

[lucasxas]

Any reason why we still using ListView/GridView?

I think it could be easier to just use RecyclerView + LinearLayout instead of ListView, and RecyclerView + GridLayout instead of GridView.

That would also make it easier if we want to implement pagination on Fragments that extend from GDGListFragments.

Any thoughts?

[friedger]

I didn't really get the advantages. But go ahead and use recycler views.
On 11 Jun 2016 07:49, "Lucas Xavier" notifications@github.com wrote:

Any reason why we still using ListView/GridView?

I think it could be easier to just use RecyclerView + LinearLayout instead
of ListView, and RecyclerView + GridLayout instead of GridView.

That would also make it easier if we want to implement pagination on
Fragments that extend from GDGListFragments.

Any thoughts?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#557 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABYcWWTMBCh27ow5dFf2OuaMG4yvipBJks5qKkxigaJpZM4HZs6f
.

[lucasxas]

The issue is that the AdapterView doesn't have a ScrollListener. But I guess I could still use ListView & GridViews and check if the mList is one of those two types.

[tasomaniac]

We currently have GDGListFragment and GdgRecyclerView actually. ListFragment uses GridView and lists are just grids with 1 column.
I introduced the RecyclerView one by just copying and adjusting our ListFragment. Because at that point I really didn't want to change the behavior. I am not happy with it.

You can use anything that is suitable.

For paging, you don't need a scroll listener, when the last item in the adapter is created or binded, you can initialize it.
Althought this library is retired, it is still stable and work really well with AdapterViews

[lucasxas]

I got away changing the AdapterView to AbsListView, which ListView and GridView extends, what do you think @tasomaniac ?

Also, I'm using this approach https://github.com/codepath/android_guides/wiki/Endless-Scrolling-with-AdapterViews for the 'Infinite' Scrolling. It works pretty well and if you want to implement the same behaviour in any fragment that extend from GDGListFragment you just need to override one method.

The work is pretty much done now, I'm just doing on the header/break in between past and future events. :)

[lucasxas]

I can implement the basic logic for the GDGRecyclerFragment as well. So if we decide to move the Events page to a RecyclerView it would be easy peasy.

[friedger]

Do you have already some code pushed somewhere
On 12 Jun 2016 6:10 a.m., "Lucas Xavier" notifications@github.com wrote:

I can implement the basic logic for the GDGRecyclerFragment as well. So if
we decide to move the Events page to a RecyclerView it would be easy peasy.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#557 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABYcWYeMHWm81a73uuDadpOOFPfpBzR4ks5qK4aYgaJpZM4HZs6f
.

[tasomaniac]

@lucasxas Looking forward to see the PR.
My only concern is that the methods described in the wiki you gave seems complicated. There are a lot of computations going on. Whereas loading additional pages when the last item's viewholder in the adapter is binded is much easier.

[lucasxas]

Yeah here @friedger https://github.com/lucasxas/frisbee/tree/feature/infinite_scroll

[lucasxas]

Did any of you had a chance to try it? :)

I was playing with it yesterday and it performs well. Also I don't see a need for adding a header for upcoming and past events, as our Views already show 'PAST' when is necessary.

What do you think?

[tasomaniac]

I think that separation can go into a separate issue. Instead of the
current past indicators, we want to have 2 separate sections.

I didn't look at your fork. If you are satisfied with it, can you open a
pull Request?

On Wed, Jun 15, 2016, 11:51 Lucas Xavier notifications@github.com wrote:

Did any of you had a chance to try it? :)

I was playing with it yesterday and it performs well. Also I don't see a
need for adding a header for upcoming and past events, as our Views already
show 'PAST' when is necessary.

What do you think?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#557 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAuly7AnQb6QqzSLwesauvlqNiCMOhwVks5qL8sNgaJpZM4HZs6f
.

[tasomaniac]

Fixed in #647