hello, Jeff!

how can I help you today?

mark, nice to see you.

Jeff: you can see me? I thought my webcam was covered... :-)

and hello, Roberto!

figuratively lol

Jeff: you got here first, so... do you have a question?

I want to learn proper mvvm pattern in my app. should i read exploring android or android architecture components. I noticed chapters on viewmodel in both.

I do not cover MVVM specifically, but I do cover the Jetpack ViewModel class and related supporting classes

or do you just talk about the viewmodel and not mvvm pattern

*Android's Architecture Components* is a first-generation book, so it uses Java and the older Android Support Library classes

all else being equal, you are better off with *Exploring Android*, as it is newer, shows the Jetpack/AndroidX classes, and shows both Java and Kotlin

but yes, I talk about ViewModel and not MVVM

my samples are more MVI-ish

I've been reading AAC, how are your examples different from MVVM? For example, I noticed you also use models persisted in room and activity as a view. Your activity contains a viewmodel. Can you explain why it does not follow mvvm

I would phrase it more as: I am not expert on all the various GUI architecture patterns

so I make no claims about whether my code strictly follows any particular pattern

sure thanks

besides, from what I can tell, different people have different takes on what exactly MVVM really means

so I try to stay out of those fights

I'm here to show you how to use the SDK and its classes to get stuff done :-)

let me take a question from Roberto, and I'll come back to you in a bit

ok

Roberto: your turn! how can I help you today?

Mark, greetings from New Zealand, I'm returning back to the subscription after a couple of years of pause. I've been following your job, big fan here.

My question is a bit similar :)

thanks for the kind words! and good morning! :-)

so, your question is: where do I cover MVVM?

I got an app following MVVM, with Pagination Library and the Repository using database as single source of truth

Just as Google's Pagination Code Labs covers

is this using Room?

Yes, it is

And this is the codelab https://codelabs.developers.google.com/codelabs...

Most of project's I've seen implement something similar here

which covers the basic cases: updates from network and offline support

my doubt is what happens when updates comes from UI

and I'm looking for the patterns that I could be following

This is a tricky question... but I thought the chat would be the way because rather than a question it may be a conversation/discussion

I guess I am uncertain what your concern is -- if it with respect to the Paging support, it should be just a matter of calling the appropriate DAO functions to manipulate the database, and you should get fresh data automatically

and your viewmodel would probably call functions on the repository to cause those database changes

Even if the data updates comes from UI events?, such as a swipe to delete event on UI?

sure

my take on the classic to-do app takes that basic approach, minus the paging (because if you have that many to-do items, you probably don't have time to read my books...)

Yes... I remember these. Are you using polling in any example?

no, it's all pushed from Room

Unfortunately, I've to poll the backend to see if data has changed on server side

And that's creating me race conditions

ah, sorry, I misunderstood your scenario

Oh nothing to apologise.. it's a bit complex

the big decision, AFAIK, is what is the system of record -- earlier, you said that is the database

that implies that your UI changes still change the database, and you are doing something to arrange to also update your backend, plus find out if the backend has changed data

Exactly. That's the problem.

by "race conditions", what do you mean? is this something low-level like a deadlock, or something higher-level like two parties updating the same data?

Yeah, race conditions may be missused there. I'm talking about data inconsistency

well, if the local database is the single source of truth, then that implies that the server loses

if that would be a problem, then the server is really the source of truth, and the local database is a cache

you can certainly try to get elaborate, with data-merging algorithms (think git), depending on your needs

Alright. Makes sense. Any litearature discussing this scenarios? is "synchronization pattern" the key words here?

you're mentioning data-merging algorithms. I guess my problem is I don't know the name of my problem :)

then I cannot take advantage of existing literature

:)

synchronization, in this context, tends to be the data-merging approach, where you're trying to "have your cake and eat it too" and have both copies by systems of record

personally, I haven't had to work with that sort of scenario in years, so my terminology is somewhat dated

and it's a tough nut to crack, unless you are using some system designed around that problem (e.g., Couchbase)

pretty much everything I've had to do in recent years has either had the server as the system of record (with a local cache, perhaps) or considered the server to simply be a place for backups

so "data synchronization" is a fine term, but I can't really point you in the direction of current literature on the topic

The problem I've to solve is pretty much the same as todo list

being updates from different source and server is not able to do updates by push

let me take another question from Jeff, and I'll swing back to you shortly

Sure, thank you very much Mark.

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

yes. which datasource should i use for the new pagination library in jetpack if I have using an api taking in an offset and limit, returning a Single type from RxJava?

I pretty much failed in all my attempts to get Paging to work, other than when Room returns the DataSource.Factory, so my advice is going to be limited

offset and limit sounds like a PositionalDataSource, though

your offset and limit map to loadSize and startPosition in PositionalDataSource.LoadRangeParams

however, I forgot that PositionalDataSource needs a countable data set, and I don't know if you know the data size

in that case, you would need to disable placeholders if you still want to use PositionalDataSource

the Paging library and I didn't get along, so I don't have an example of your scenario to show you, unfortunately :-(

but, that was back when Paging first came out, and I just haven't had a need to get back into it beyond Room since then

let me take another question from Roberto, and I will come back to you in a bit

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

https://medium.com/@antobeslie25/android-recycl... discusses using a PositionalDataSource. It seems you load data using a function returning List<Model>. I have a a Single<List<Model>, so it sounds like I would subscribe to that Single inside the loadData method

(Jeff: there are probably recipes for dealing with RxJava for this sort of Web service API and mapping that into Paging -- subscribing in loadData() would make me nervous, in terms of when you would dispose of the subscription)

yes, I am just trying to find a proper example

here, they have their DataSource.Factory take a CompositeDisposable in its constructor, which would be one way of dealing with my concerns over when to clean up the subscription

Roberto: if you have another question, chime in!

Mark, no questions atm, I'm on the same issue as before. I don't know if there's anything else to talk about that.

"being updates from different source and server is not able to do updates by push" -- unless the server can tell you what data changed by some means, I don't see how you can consider the local database to be a source of truth

if either of you have another question, go right ahead!

suppose I use an endless scroll listener instead. What is considered good practice for restoring a paginated list? If I am on page 20, do I persist pages 1-20 and restore them from a database? Or do I simply make a network requestagain?

that probably depends on the network cost (big bandwidth vs. small) and the expected usage pattern (lots of scrolling vs. not much)

not much scrolling suggests just an LRU memory cache to me

lots of scrolling and small bandwidth would lead me to just making the network request again, perhaps with some in-memory caching

lots of scrolling and large bandwidth suggests some amount of on-disk caching

"unless the server can tell you what data changed by some means, I don't see how you can consider the local database to be a source of truth" Alright, then you'd use database just as cache and Network would be the only source of truth then?

why use memory instead of persisting? I read we should not use bundle memory in this case because bundles are designed to store small amounts of information, not pages

Roberto: yes, because I don't know how you could keep the local database up to date other than by clobbering it with what the server has

Jeff: I wasn't referring to bundles, but rather caching in the repository layer

ok. how do I know when it is ok to save and restore a list using a bundle. I tried it using long lists and it was never an issue

Mark: thank you very much. This was a very insightful conversation, I may return back with more questions on this subject.

technically, you don't know it is a problem until you crash

Roberto: sounds good!

Jeff: my general rule of thumb is that that saved instance state and Intents should be small

a few KB, fine

tens of KB, maybe

100s of KB, you're eventually going to crash

ok cool

I appreciate it; talk to you later mark

sure!

BTW, both of you might be interested in caching solutions like Store: https://github.com/dropbox/Store

(though it's now Kotlin-centric, and I'm not sure whether you are using Kotlin yet)

and that's a wrap for today's chat

the transcript will go up on https://commonsware.com/office-hours/ shortly

the next chat is Thursday at 4pm US Eastern (sorry Roberto, not very NZ-friendly!)

have a pleasant day, and stay healthy!