Hi Mark!

hello, Suleyman!

how can I help you today?

I have small question about ViewModels and Fragments.

I have a Parent Fragment with a TabLayout that hosts 3 Child Fragments. I am using Room + ViewModel + LiveData to save the UI data through app termination and configuration change. I have one Entity object that has all the data for the 3 Child Fragments. My question is, would it be better to register an observer in my Parent Fragment and then just pass all the relevant to data to Child Fragments through bundles, or is it better to decompose my Entity class into smaller pieces and register observers in each Child Fragment?

I don't have a really good way to answer your question

though I am somewhat surprised your answer isn't just to keep using ViewModel

fragments can share a ViewModel with their parent

(hello, Graeme! I will be with you shortly!)

Hello

Suleyman: so, when the entity changes, or you get a new entity, publish that through a shared ViewModel, one that all three child fragments share

Right, I wasn't sure performance wise if a Bundle would be better. But you are right, I'll share a ViewModel

Thanks for the help Mark, I just needed clarification from someone :)

if you also need separate ViewModels per tab fragment, you can do that too -- you are not limited to a single ViewModel per activity/fragment

you can have one ViewModel that represents the shared environment for the entire activity, and separate ViewModels as needed for individual fragments

let me take a question from Graeme, and I'll be back with you in a bit

Graeme: your turn! do you have a question?

of course :)

I'm working on the new Paging Library, and struggling a bit with creating a custom DataSource and DataSource.Factory

yeah, that's an icky area

Most of the examples are pushing the fact that you can get a DataSource automatically from Room database, which is pretty awesome, or I think will be when the Arch components mature some more, but yeah, like you say, it's a bit icky. :)

now that Paging has gone final for 1.0.0, I'll try to spend more time on this scenario in "Android's Architecture Components"

I've played with this some already, so I might be able to help -- what is your specific concern?

Florina Muntenescu has put out a great new video overview of the Paging Lib a week and a half ago, and at the 1:30 timestamp, there's a great slide about the flexibility of a DataSource: https://youtu.be/QVMqCRs0BNA?t=90

I love the open-ended "any other source" :-)

So specific question: I'm trying to create the DataSource which just hits the network, and while I think I'm on the right track there, I'm struggling to get the whole architecture setup. The sample PagingLibraryWithNetwork example is a bit overwhelming with the complexity of the Repository pattern it implements.

Do you know any good examples that show the Repository pattern more simply?

with Paging? not off the top of my head

or rather, not with custom Paging implementations

plenty of Room ones

okay, I could work around that... What's a super example out there that shows the repository pattern set up well for a Room database?

I had one in "Android's Architecture Components", though I pulled it for the most recent update, pending a rewrite

(Long story short: I would like to get our app to the point where we are backed by a room database as well, but for now we need JUST the network stuff. So if I do the Repository pattern correctly now, then theoretically, I should be able to slip a Room DB into the mix at a later date)

hehe, I have the 0.8 version of that book still. ;)

you can see the PagedMVI sample at https://github.com/commonsguy/cw-androidarch/tr...

in my case, it's actually a semi-custom paging implementation, due to some limitations of the Architecture Components at the time

part of the rewrite is to clean all that up, now that Paging shipped a 1.0.0 that fixed some of my issues

Great. I'll take some time right now to go check out the PagedMVI sample.

just plain Room+paging is also seen in the chapter on Paging itself, with the RoomPaging sample: https://github.com/commonsguy/cw-androidarch/tr...

there I didn't put a repository facade around the RoomDatabase and its DAO, but that's not really much of an issue

really, a repository is just your own custom API, offering some reactive means of getting at data, and hiding implementation details

And prod you a bit... please explore the custom DataSource stuff in more detail! A sample that loads from a giant text file would be really helpful for demonstrating the "any other source" thing that Florina mentions! ;)

doing a local non-relational store as a paging sample... interesting...

that's actually likely to be a bit complicated

but, I'll add it to my to-do list

Yeah... I love the new Android Architecture Ccomponents, they really represent a maturing of the platform, but we're on the sharp part of the cutting edge here, and I'm getting a bit cut. ;)

understood

let me take another question from Suleyman, and I'll return to you in a while

Suleyman: back to you! do you have another question?

Cool, thanks, chat more in a bit, if I have questions about PavingMVI

That's pretty much it, I just wasn't sure performance wise, if having several ViewModels affects that. I know it may be stupid but I am very paranoid when it comes to that :)

there shouldn't be a material impact on performance

the I/O or whatever you are doing will be where the performance problems arise

whether changing your data storage approach (one entity vs. decomposed entities) would help with I/O, I can't say

but once the stuff is in memory, exactly how you shuttle it around between Java objects isn't likely to have a performance impact

so, use something that is convenient and comfortable

Thanks, that's exactly what I was worried about

Then I'll experiment :)

Thanks for your help Mark, that's it for me :)

OK

Graeme: back to you! do you have another question?

OK, if either of you come up with a question, chime in

heh, yeah, I can see why the PagedMVI sample was pulled, the API has changed a lot since then

:)

yup

and I didn't have time for a rewrite then

All Factories, and no more Providers!

sorry

Okay, thanks for your help Mark, good luck with the next version!

ciao!

thanks, and have a pleasant day!

You too!