Jun 2 | 3:50 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Jun 2 | 3:55 PM |
Suleyman | has entered the room |
Suleyman |
Hi Mark!
|
Mark M. |
hello, Suleyman!
|
Mark M. |
how can I help you today?
|
Suleyman |
I have small question about ViewModels and Fragments.
|
Suleyman |
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?
|
Mark M. |
I don't have a really good way to answer your question
|
Mark M. |
though I am somewhat surprised your answer isn't just to keep using ViewModel
|
Jun 2 | 4:00 PM |
Mark M. |
fragments can share a ViewModel with their parent
|
Graeme C. | has entered the room |
Mark M. |
(hello, Graeme! I will be with you shortly!)
|
Graeme C. |
Hello
|
Mark M. |
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
|
Suleyman |
Right, I wasn't sure performance wise if a Bundle would be better. But you are right, I'll share a ViewModel
|
Suleyman |
Thanks for the help Mark, I just needed clarification from someone :)
|
Mark M. |
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
|
Mark M. |
you can have one ViewModel that represents the shared environment for the entire activity, and separate ViewModels as needed for individual fragments
|
Mark M. |
let me take a question from Graeme, and I'll be back with you in a bit
|
Mark M. |
Graeme: your turn! do you have a question?
|
Suleyman |
of course :)
|
Graeme C. |
I'm working on the new Paging Library, and struggling a bit with creating a custom DataSource and DataSource.Factory
|
Mark M. |
yeah, that's an icky area
|
Jun 2 | 4:05 PM |
Graeme C. |
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. :)
|
Mark M. |
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"
|
Mark M. |
I've played with this some already, so I might be able to help -- what is your specific concern?
|
Graeme C. |
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
|
Mark M. |
I love the open-ended "any other source" :-)
|
Jun 2 | 4:10 PM |
Graeme C. |
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.
|
Graeme C. |
Do you know any good examples that show the Repository pattern more simply?
|
Mark M. |
with Paging? not off the top of my head
|
Mark M. |
or rather, not with custom Paging implementations
|
Mark M. |
plenty of Room ones
|
Graeme C. |
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?
|
Mark M. |
I had one in "Android's Architecture Components", though I pulled it for the most recent update, pending a rewrite
|
Graeme C. |
(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)
|
Graeme C. |
hehe, I have the 0.8 version of that book still. ;)
|
Mark M. |
you can see the PagedMVI sample at https://github.com/commonsguy/cw-androidarch/tr...
|
Mark M. |
in my case, it's actually a semi-custom paging implementation, due to some limitations of the Architecture Components at the time
|
Mark M. |
part of the rewrite is to clean all that up, now that Paging shipped a 1.0.0 that fixed some of my issues
|
Graeme C. |
Great. I'll take some time right now to go check out the PagedMVI sample.
|
Mark M. |
just plain Room+paging is also seen in the chapter on Paging itself, with the RoomPaging sample: https://github.com/commonsguy/cw-androidarch/tr...
|
Jun 2 | 4:15 PM |
Mark M. |
there I didn't put a repository facade around the RoomDatabase and its DAO, but that's not really much of an issue
|
Mark M. |
really, a repository is just your own custom API, offering some reactive means of getting at data, and hiding implementation details
|
Graeme C. |
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! ;)
|
Mark M. |
doing a local non-relational store as a paging sample... interesting...
|
Mark M. |
that's actually likely to be a bit complicated
|
Mark M. |
but, I'll add it to my to-do list
|
Graeme C. |
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. ;)
|
Mark M. |
understood
|
Mark M. |
let me take another question from Suleyman, and I'll return to you in a while
|
Mark M. |
Suleyman: back to you! do you have another question?
|
Graeme C. |
Cool, thanks, chat more in a bit, if I have questions about PavingMVI
|
Suleyman |
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 :)
|
Mark M. |
there shouldn't be a material impact on performance
|
Mark M. |
the I/O or whatever you are doing will be where the performance problems arise
|
Mark M. |
whether changing your data storage approach (one entity vs. decomposed entities) would help with I/O, I can't say
|
Jun 2 | 4:20 PM |
Mark M. |
but once the stuff is in memory, exactly how you shuttle it around between Java objects isn't likely to have a performance impact
|
Mark M. |
so, use something that is convenient and comfortable
|
Suleyman |
Thanks, that's exactly what I was worried about
|
Suleyman |
Then I'll experiment :)
|
Suleyman |
Thanks for your help Mark, that's it for me :)
|
Mark M. |
OK
|
Mark M. |
Graeme: back to you! do you have another question?
|
Jun 2 | 4:25 PM |
Mark M. |
OK, if either of you come up with a question, chime in
|
Jun 2 | 4:40 PM |
Suleyman | has left the room |
Jun 2 | 4:55 PM |
Graeme C. |
heh, yeah, I can see why the PagedMVI sample was pulled, the API has changed a lot since then
|
Graeme C. |
:)
|
Mark M. |
yup
|
Mark M. |
and I didn't have time for a rewrite then
|
Graeme C. |
All Factories, and no more Providers!
|
Mark M. |
sorry
|
Graeme C. |
Okay, thanks for your help Mark, good luck with the next version!
|
Graeme C. |
ciao!
|
Mark M. |
thanks, and have a pleasant day!
|
Graeme C. |
You too!
|
Graeme C. | has left the room |
Jun 2 | 5:00 PM |
Mark M. | turned off guest access |