databinding sample structure

[OyaCanli]

I thought of a sample app with possibly two screens: initial screen with a list of items(fed with a recyclerview adapter), and a second screen for item details.
Since we want to demonstrate a single concept in isolation in these basic samples, I guess we shouldn't be using network or database in this sample, right? Then we can use a hardcoded data source(may be your product-seller lists).
I think of using databinding exhaustively in this sample: Binding data, binding listeners, binding adapters.. A typical use case for BindingAdapter is when image is loaded with Glide. So I can add some images to items and demonstrate that. Or if you think we should exclude any external libraries, I can try to find another example for BindingAdapter. I also thought of importing a helper method to xml, just to demonstrate it. I don't know what yet.. So the idea is to demonstrate what we can do with databinding.

[rajtheinnovator]

That looks great, @OyaCanli . Yes, that'd be good to get started with product-seller list data to keep the sample, simple and isolated. And I think, Glide or Picasso is very commonly used and easier to understand so we can make use of that. That should not be considered a very big task for fellow developers. We can load images directly from drawable directory if we want to not make use of network resources.

I think we can do it in two parts. In one sample, we'll do one app which has different activities, each devoted to demonstrate the use of binding data, listeners and adapters separately and then in the other one, we can combine all of them together to give a practical use case example. There, we could also consider doing it with some apis like newsapi.org or we can do apis example in separate sample itself so that we'll be having three different samples at the end. What does that sound like? And any further details/suggestions you'd like to share, to finalize the structure of the sample?

[OyaCanli]

I'm not sure if I understood this part correctly:

one app which has different activities, each devoted to demonstrate the use of binding data, listeners and adapters separately

Do you mean like in one activity layout we only bind some data but not listeners, in the other activity we bind a click listener but not data etc.. ? Cause I feel like it would be weird.. If you're concerned about the comprehensibility of the sample, may be we should support with a written tutorial in parallel, which contains some gists and step-by-step explanations?

[rajtheinnovator]

@OyaCanli I've setup different branches with android projects. Now you can fork and clone the forked copy on your machine and get started with the development. We've two projects mainly. One which uses just the hardcoded data, like from seller-product list of the repository EnDataSource and the other in which you can use the NewsApi.org api to fetch real time data and give the example of more practical use case. However make sure that you don't push your api-key in the project files while commiting on Git.

[OyaCanli]

Hi @rajtheinnovator @GretaGri I made a pull request. I want to note a few things:
I first used a binding adapter for setting image to imageview without Glide. Then I added Glide, but I lefted other method in a commented out fashion, to show another alternative. Is it good like that, or we remıve it from there and we explain those details in a written tutorial?
Another thing: details images were cut out in centerCrop so I tried centerInside and it was better. But this was before I implemented Glide. After adding Glide, appearance changed. It seems that centerInside doesn't work or doesn't work properly with Glide. It was showing images extra small. I found a workaround like turning off default transformations, but not 100% percent happy with the result. Besides, I don't want to confuse readers with extra code.. So please take a look, and tell what you think is better.

[rajtheinnovator]

@OyaCanli the standard practice is that we should not have any unused or commented out code and so the best thing we can do is to remove those lines of codes. The reason is that, if some other developer come across the code, it can be confusing to them because they might not be knowing what was the purpose that code was left behind for. If we want to show different approaches of doing same things, maybe we can do it in two separate examples/fragments.

And for the other question, I think you can take a look at the following discussion and see if that can solve the issue: bumptech/glide#591 (comment)

And hey, after looking into the BindingAdapters, I think if you can explain the code comment in more details, we can leave the code there as it's not a lots of code so no need of creating a separate new sample for that. But that'd still be not-as-per-the-standard guidelines.

[rajtheinnovator]

@OyaCanli @GretaGri by the way, we can move it back to support library instead of androidX as per our discussion on Enpassio. What do you say?

[OyaCanli]

Or may be, we don't use Glide in the first sample, and we use it in the second(with network)? We'll have two samples anyway..

[rajtheinnovator]

Yeah, that'll solve the confusion. So we can have them in separate samples as you suggest. Please go with that, @OyaCanli 👍