hello Eric!

Mark!

how can I help you today?

(BTW, hello, Ivano -- I will be with you shortly!)

Eric: how can I help you today?

(OK)

What is the difference between a source of truth and a cache? Is the latter a temporary set of data

yes

for example, your Web service might be the "source of truth", but you hold onto a recent response in memory to save bandwidth and time, rather than re-requesting the data

caching is not an Android thing -- you see it all over computer programming: https://en.wikipedia.org/wiki/Cache_(computing)

Is Room considered a source of truth or a cache? I can use it to prevent an api call but it is stored in disk instead of memory due to persistence

a SQLite database managed by Room could be either

it all depends on how you use it

for a note-taking app that stores its notes purely in SQLite, SQLite is the source of truth

I guess what I'm getting at is when to decide to use a memory cache or a room db cache?

that's a several-hour discussion, tying in details like the particular purpose of the app, where and how data gets stored and moved around, etc.

actually, to be fair, it would only be several hours for a significant app -- the smaller the app, the shorter the architectural discussions

do you talk about it in any commonsware material? One consideration would be lifecycle of data, memory gets cleared once an app process is done. Another would be performance since we don't want to store something large like images in memory

"do you talk about it in any commonsware material?" -- no, because it is not really related to Android, any more than it is related to Windows or Firefox

your considerations are quite accurate, and that's why the details of what you cache and where depend a lot on the data, where it is coming from, and how you are using it

for example, caching a Room database in a Room database is kinda silly :-)

lol

OK

caching Web service responses in a Room database may or may not make sense, depending on the details

true

my books focus on Android first and foremost, so while I might talk about "this is how such-and-so caches data", I am not trying to teach the concepts of caching or the strategies for choosing what to cache when

sure no prob :)

let me take a question from Ivano, and I'll return to you shortly

well, I do not get the purpose of this flowOn operator, why `i should care about where to move the thread if I use coroutines that are going to solve this problem with the coroutine scopes and the withContext?https://kotlin.github.io/kotlinx.coroutines/kot...

flowOn() is merely a convenience

that is an euphemism to say that is a nonsense?

or maybe is for granular operations?

no, more that there are other ways of solving the same problem, such as having your collect() (or other terminal operator) be inside a withContext(...) {} lambda that sets the context

ok

I do not have other questions thanks Mark, I would go back to netflix

yeah, I can't compete with that

thanks && bye Eric

well, sometimes your Axotixl in klassbook

or the quotes to blowing in the wind are pretty funny

bye

I try to keep things light and unpronounceable

ahahah

OK, Eric, back to you! do you have another question?

byew

Can I use SharedPreferences to store an auth token? Instead of using android TokenManager

sure

usually, a token like that is represented as a string, or can be converted to and from a string

so, you can store it wherever you store a string

I guess what I'm asking is is it considered bad practice. Otherwise, why would google create TokenManager if SharedPrreferences alerady exists as part of Android

well, I can't tell you why Google does lots of crazy things

I can tell you that TokenManager is not very popular -- if I hear it mentioned once in a year, that was a banner year

(BTW, I'm assuming that you mean AccountManager)

AFAIK, Google had this theory of having centralized account management on the phone, and basically few developers bought into it, possibly due to "trust issues"

yes AccountManager

if I clear my app data, do both my SharedPrefs and my Room DB get cleared? What about if I uninstall my app? And if I update my app

clear app data: yes, all of internal storage for your app gets cleared

uninstall: same

update: nothing of your app's internal storage is touched

I'm not sure nothing gets touched on update. If an app adds a column to a room db table and a user installs an update their app will get that new column

the *update* is not doing that, strictly speaking

*your code* is doing that, if you happened to register a migration and the migration was needed

correct

why should somebody use external storage over internal storage?

mostly so the user can have independent access to the content, such as via a file manager

or via a USB cable

internal storage = only your app can access it (except for users who root their devices)

external storage = other apps may be able to access it, depending on circumstances

so if I am building a photo app I want to use external storage so I can upload my photos to my computer?

removable storage = oh, crap, the micro SD card popped out and now I can't find it on this dark carpet

if you are building a general-purpose camera app, you probably want the photos to be on external storage, specifically off of a suitable media directory

wait is external storage actually only available on removable storage? I thought it was also on your phone's disk partition

external storage = a part of the on-board flash that the user can independently access

what does on board flash mean sorry

removable storage = micro SD card, or sometimes a thumb drive

sorry, "on-board flash" is shorthand for "flash memory that is part of the core chips powering the device and cannot be removed without a soldering iron and a steady hand"

OK I see; I appreciat it