second sample

[OyaCanli]

So up to now, we have been saying that we want another databinding sample with network connection. Let's discuss the details of it.
-Are we using NewsApi ?
-How do we deal with network request? Retrofit? Raw http request?
-How will be the structure? Will we again show a list of items in recyclerview and a detail page?
-Normally, it is not good practice to make network request from main activity. It would be better to put it in ViewModel or a singleton Repository. But shall we avoid those for simplicity?

[GretaGri]

My ideas to those questions:

• yes, we are going to use NewsAPI;
• maybe Retrofit could be simple enough?
• Could be the same. Thinking if there is any reason to change? Do we want to show something more?
• we could use ViewModel or Repository, I am not sure if we are going for simplicity or more for good practice:)

[rajtheinnovator]

@OyaCanli @GretaGri yes, we'd be using NewsApi for that purpose. Retrofit is good but as the focus here is to help people on Databinding mainly, so even simple http call is also fine. We've things implemented in simple form already in the first sample and so now we can have one example with best practice now. That's what I think here.

[OyaCanli]

I don't think retrofit is more complicated than making raw http request. But both are fine for me.
For a news app, I guess it makes sense to show articles in a list and then show individual articles in a details screen. Though, from the databinding perspective, its gonna have a similar structure to previous sample. The only interesting new think I can think of is to pass a boolean to the binding for differentiating loading states and using ternary operator to play with visibilities. And we'll use a binding adapter for loading images with Glide.
May be we can use a layout with include tag, in order to demonstrate how to reach a 'included' layout.
If we use a viewmodel, may be we can pass the viewmodel to databinding, instead of the item..

[rajtheinnovator]

@OyaCanli the use of included tag would be a nice addition here. For the ViewModel part, I'm not sure how you plan to do that because I've not done deep diving on this topic but I'm sure that you two have done enough research and so it must be something nice. So please go with what you find the best way there. For http request, I understand that, it's not easy itself but I've seen people working with it from beginning and so even if that's not easy, it look intuitive to them. Retrofit is really nice but people try it generally after already working with simple http request so maybe they'll find http request more natural to them 👍

[OyaCanli]

Ok @rajtheinnovator. Let's go with http request. Frankly, I had found myself the underlying mechanisms of http request complicated as well. But it was a chunk of code that we could copy paste and reuse, so it was easy in that sense.

I have been playing with viewmodels for a while, I'm comfortable with that. For passing the viewmodel to databinding vs passing directly the item, I'm not sure whichis better in fact. I guess it depends on case. I have seen both in google samples. I'll check them out again and compare. And we'll discuss it more as the project takes shape and we know more details.

[OyaCanli]

This sample is interesting: https://github.com/googlesamples/android-architecture/tree/todo-mvvm-databinding/todoapp/app/src

[OyaCanli]

One interesting thing is the implementation of BaseObservable to make the binding update itself. But I think we can do it with livedata as well. Once we decide the details of project structure, I'm voluntary to experiment with it.

[OyaCanli]

Looking at NewsApi, I see all articles have these attributes: source(name of journal), author, title, description, url(for the article), urlToImage, publishedAt, content.
For the list items, I guess we'll use titles, authors, images(thus image url), publishedAt, and may be also source. Description and content are long for list items. If we'll have a detail view for reading the article in app, we won't need article url. But we'll need description and content.
And if we'll have a detail view for in app reading, one question I'd ask is to whether it is better to parse all these data (including description and content) at once and then simply pass selected item to details screen, OR to exclude the description and content when parsing for the list and then parse whole contents only for the selected item in the details screen. (I mean, in order not to make a large unnecessary operation, since article contents can be very long)
But since this is only a sample, may be we simply limit the article numbers and don't worry about these details?

[OyaCanli]

@GretaGri @rajtheinnovator Shall we finalize the structure of the app and share tasks to begin working?
-Two fragments: one with list and one with details seems ok? (Have you read my concerns above)
-Shall we use a fix simple query, like 8 or 10 articles in a given topic(may be tech?)

@GretaGri Do you want to again design layouts and reuse them on kotlin version? Or do you want to do something else this time?

[OyaCanli]

I recognized that we need to use special escape characters for logical operators, like in here: https://github.com/OyaCanli/TrainInventory-Firebase/blob/master/app/src/main/res/layout/fragment_train_list.xml#L34
May be we can use it in our sample as well. We won't have empty state I guess, but we can add something for no network case.

[GretaGri]

I can work again with layouts and with Kotin codes.

[OyaCanli]

Ok, that sounds good @GretaGri.
I assume we'll have again a single activity with two fragments, one fragment with a list, one fragment with details?
Something different may be a loading indicator and no network image/message besides recyclerview.

[OyaCanli]

Shall we let you first make the layouts then @GretaGri ? Will you have time for that in the following days, for example? Otherwise I can make some parts without UI..

[GretaGri]

@OyaCanli I will try to work with it this weekend :) but you can start too on the parts that do not need layouts 💯

[OyaCanli]

Ok, great @GretaGri. Yeah, I was thinking the same. I can work on different parts. Since we'll be working on different files, it won't be difficult to merge. Is it ok @rajtheinnovator ?