android / architecture-components-samples

Samples for Android Architecture Components.
https://d.android.com/arch
Apache License 2.0
23.4k stars 8.29k forks source link

There is no PagingWithNetworkSample Java demo. #329

Closed easyandroid-cc closed 4 years ago

easyandroid-cc commented 6 years ago

There is no PagingWithNetworkSample Java demo.

Raykud commented 6 years ago

I'm agree with this. Even though Kotlin is a good language I belive there is plenty of people that have not learned Kotlin yet and therefore a Java example is a MUST.

cgpllx commented 6 years ago

I need a Java demo

Zhuinden commented 6 years ago

@cgpllx or you need to learn to read Kotlin 😄

shaycormac commented 6 years ago

please give us a java demo, ok?

Seddiks commented 6 years ago

I want Java example please

Zhuinden commented 6 years ago

Honestly, what people need is better Kotlin tutorials.

TonyTangAndroid commented 5 years ago

@Zhuinden

I had shared the same thought with you when I knew Paging Library was released and given a Kotlin example. I was really excited and I did not mind at all that it was written in Kotlin. How difficult it could be?

But my recent experience has changed this thought. Kotlin is a really cool language providing a lot of features and flexibilities, which is exactly the problems in this specific paging library sample app. And it is NOT that difficult to understand and to learn. However, to reach the same comfortable level as Java, not only one needs good tutorials, which there are many in community, but also requires that he or she uses Kotlin in the daily work. Only through this way, we could have the confidence that when something goes wrong, we would know where to find the root cause. Otherwise, we could probably be misled by the uncertainty of a total different dimension of knowledge, which is the very case in PagingWithNetworkSample app.

For anyone who could confidently say that he understands how this app works requires the following skillset :

  1. Room
  2. LiveData
  3. MutableLiveData and Transformation such as Map and SwitchMap
  4. ViewModel
  5. Pagination
  6. Kotlin

For the first 4 points, which are all new concept in Android Development, it is not a big challenge to find a simple samples to learn and get a fairly good understanding about it. Because the interaction between these concepts are in a reasonable manner. However, when we are to enter a world of Kotlin and Pagination, it is so wild that I find it so hard to grasp the code.

Taking data class Listing in this paging sample app as an example.

Before this sample code base, I have never run into a reasonable use case that you could put a Runnable and other mutable data into a data class, which is equivalently a AutoValue class in java world. And this Runnable could be triggered in a total different place rather than where it is originated, which is DataSource. This could be a simple code smell in PROD code base. You would not want to chase around your code to know what it has been done eventually.

Second assuming that you have reasonable understanding of Kotlin, there are still so many things you have to be aware in Paging Sample library.

1, The trigger of UI update does not reside in Activity or Fragment, but it is residing a DataSource class. This makes it difficult to manage the view state transformation if there is any other view.

2, In any case there is a network error in retrieving new data, you have to refer to the callback that is returned by a callback in PositionalDataSource. And this callback could be invalidated at any moment if you refresh the RecyclerView, which invalidates the datasource. And the callback could only be called once for each time when the paging callback is triggered. Otherwise it will crash the app. This means that we need to introduce another state manager to manage the callback state. The Kotlin implementation here seems to be easy, but if you try it in Java, you would be surprised how troublesome it is and you code could become so ugly that you feel an urge to reevaluate the option of using Paging library to support Pagination.

3, And there are so many code that you really need to push yourself hard to understand why, for example, in PostsAdapter, I understand that the following code is to manage the footer at the bottom of RecyclerView. But if you try to understand why it has to be implemented like this, good luck.

fun setNetworkState(newNetworkState: NetworkState?) { val previousState = this.networkState val hadExtraRow = hasExtraRow() this.networkState = newNetworkState val hasExtraRow = hasExtraRow() if (hadExtraRow != hasExtraRow) { if (hadExtraRow) { notifyItemRemoved(super.getItemCount()) } else { notifyItemInserted(super.getItemCount()) } } else if (hasExtraRow && previousState != newNetworkState) { notifyItemChanged(itemCount - 1) } }

Why we do not attach a default footer at the very beginning to make our code simpler? It turns out that it will introduce other RecyclerView issues like this.

4, The sample code UI did not behave nicely. On its initial loading, it shows the footer and refreshing indicator at the same time. Ideally, or in most PROD google app, there should be another full screen view of representing loading, network error and empty list. Combine the footer status, there should be at least the following seven states :

  1. Initial Loading,
  2. Initial Loading Failed with retry button.
  3. Initial Loading with empty result,
  4. Loading More,
  5. Loading More Failed with retry button.
  6. No More data
  7. Refreshing
  8. Refreshing Failed

All of these states could be transformed into different version. To manage such state is another challenge.

I realize that this sample app does not take the responsibility of providing sample code with PROD level quality. And all of these challenges would be still existed if the code sample is written in Java. But given this is a sample app to promote the library, rather than Kotlin language, the more complicated it is, the more value it will add to if it is written in Java. And it will also help the author of this library to get a better understanding the usability of such API.

(Please excuse me for the outcry of this paging library. It is just painful to accept the fact that the API actually has been designed properly, it is missing proper sample app that stops the library from spreading the popularity. Such pain is similar like your goods have been delivered from one thousands miles away into a local store that is one mile away from your residence but you have never been instructed how to pick it up and eventually the goods lose the value.)

Zhuinden commented 5 years ago

I don't think it's poor, it actually makes a lot of sense; the trickery comes in that DataSource is very abstract and has 3 different types out of which there are two fairly distinct scenarios.

The example is pretty complex, I realized that when I was making a talk's slides based on it.

You can check out the slides here: https://www.slideshare.net/GaborVaradi3/paging-like-a-pro

I believe if you read through the slides, you will understand the GithubBrowserSample.

The talk itself is actually available in Hungarian somewhere but I really doubt you'd find it helpful :smile:

TonyTangAndroid commented 5 years ago

@Zhuinden Thank you for the slides link. I actually come across it the other day when I was starting the journey of learning Paging Library. It has been helpful. Thank you for sharing it.

In regarding to the Paging API design, I agree that it is good. It is only as complicated as it needs to be. And I do not believe that I could come out a better solution if it is up to me. What is missing is the Java Example of paging library.

A good news to me is that after I raged this comments here last night, I figured out everything. I am in a comfortable position of writing a full feature paging library in Java. I will post it here once I conclude the example, which could be expected in a week.

TonyTangAndroid commented 5 years ago

For those who are expecting the Java sample, just for a quick update here. Obviously, I overestimated how much time that I could squeeze to work on the sample and underestimated the effort that I need to invest to get the paging sample Java version done properly. I will try to target the sample app this weekend and post the link here.

shadowdogg commented 5 years ago

For those who are expecting the Java sample, just for a quick update here. Obviously, I overestimated how much time that I could squeeze to work on the sample and underestimated the effort that I need to invest to get the paging sample Java version done properly. I will try to target the sample app this weekend and post the link here.

Any luck on publishing it Tony?

I also think it is ridiculous Google is not showing enough Java stuff. Get off your high horse and appreciate that getting developers to get the best from the language they know is more important than your ideology. I learnt Java because I can use it outside of Android development too.

Zhuinden commented 5 years ago

I learnt Java because I can use it outside of Android development too.

Kotlin is also supported by Spring Framework 5.0+ with first-party Kotlin support and Kotlin-friendly APIs - which lets you do backend development.

dlam commented 4 years ago

There are samples in Java for both RX and Guava / LiveData on http://d.android.com/paging3 now!

TonyTangAndroid commented 2 years ago

I know that this issue has been closed, thought I did not find anything Java sample at http://d.android.com/paging3.

Anyway, after spending two full days restlessly (30 hours or so), I finally have written a proper Page 3 java demo for me and many more who are still feeling more comfortable in ramping up Paging 3 features set with Java languages. Here is the link : https://github.com/tzltdc/Paging3WrapperDemo. And the best part of it is that there has been extra effort invested in polishing the header & and the footer view, which is extreme hard than one would expect. In a nutshell, paging is hard, real hard. Do not step into this river unless your mentality is in good state to battle and slay the dragon. Otherwise, you might be eaten alive.