11/17 milestone2#1
Conversation
| * This class implements a [RecyclerView] [ListAdapter] which uses Data Binding to present [List] | ||
| * data, including computing diffs between lists. | ||
| */ | ||
| class MeteorsListAdapter() : ListAdapter<MeteorData, MeteorsListAdapter.MeteorsViewHolder>(DiffCallback) { |
There was a problem hiding this comment.
Why did you choose a ListAdapter over a RecyclerViewAdapter?
There was a problem hiding this comment.
Why did you choose a ListAdapter over a RecyclerViewAdapter?
ListAdapter is just an extension of RecyclerView.Adapter . Its computes diffs between Lists on a background thread with AsyncListDiff.
Recyclerview.Adapter: best if the list is static
ListAdapter: best if the list is dynamic
So, I personally vote for ListAdapter.
There was a problem hiding this comment.
But your list is not dynamic. You get the API response (which is the list) which then doesn't change over time. The only diff in the list states is the list is empty (before the API call is finished), or the list is full (which is it's final state). ListAdapters should be used in situations with dynamic content, like search results. Consider the case where the user types a word, and the research results (in a list view) change slightly with every character that's added. In that case ta list adapter (with a diff calculation) is a good option, because it makes no sense to replace the entire list every time. In your case however, the diff calculation makes no sense:, as there are only 2 states: empty list or full list.
| card_view:cardCornerRadius="2dp"> | ||
|
|
||
| <RelativeLayout | ||
| <LinearLayout |
There was a problem hiding this comment.
Please use a ConstraintLayout.
There was a problem hiding this comment.
Please use a ConstraintLayout.
Is this because there is a notable performance benefit by using ConstraintLayout? This is because ConstraintLayout allows you to build complex layouts without having to nest View and ViewGroup elements on the basic foundation understanding that each phase within the view drawing process requires a top-down traversal of the view tree, therefore, the more views you embed within each other (or nest) into the view hierarchy, the more time and computation power it takes for the device to draw the views.
There was a problem hiding this comment.
Correct. Also, once you get used to developing with ConstraintLayouts, they will make your head hurt less, as you don't have to think about all the nested layers - only about an item and the relationship & alignment it has with its parent and siblings.
2 participants
main branch is the same with the milestone1 so start to merge from milestone 2