hello, Benny!

how can I help you today?

Hi Mark

as I see on your eBook most of the time you use a fragment instead of a activity, is there any reason why?

well, that depends on which book you are referring to :-)

"Elements of Android Jetpack" and "Exploring Android" are the most fragment-focused

that is because that is Google's direction with Jetpack

particularly with the Navigation component

i am work with the busy coders guide

that book has fragments in some places, but a lot of the samples just use an activity

ok, so it is better to use a fragment instead of an activity?

for a large app, with lots of screens, it frequently is easier to have fewer activities and lots of fragments than it is to have lots of activities

that is particularly true with some of the more modern Android app development features, particularly ViewModel and the Navigation component

on the other hand, a little app with few screens may not need fragments

ok, I understand. But does fragments not have lifecycle problems sometimes?

¯\_(ツ)_/¯

there used to be more problems, but the library edition of fragments cleared up most of them

there may yet be other problems, but I have not encountered any recently

okay, i always worked with activitys before, maybe it is time to do it with fragments :)

would it be better for performance, or just for a better overview

mostly, it is simpler for passing data around

Intent extras have limits in terms of size and data type

ah, okay, I understand, this is a good point

so, for example, multiple fragments in an activity not only can have their own ViewModel objects for data that is purely their own, but they can share a common ViewModel -- that is impractical if they were multiple activities

if you combine that with things like LiveData, now inter-fragment communication can be much simpler while still remaining testable

and passing data between fragments has no practical limits, other than general memory consumption, which is why the Navigation component focuses on fragments as representing individual screens

sounds really good, do you cover this in the Elements of Android Jetpack book?

yes

okay, then i have to read this :)

i would have another two questions

go right ahead!

I work on a tracking app as a side project, i want to make an all the time tracking in the background, for now I use an normal Service as forgroundService for this. Do you have any tipp what I should use there?

by tracking, you mean GPS?

yes, GPS

a foreground service is the best option as far as I know

I read a little bit about JobService, would this maybe better then a service?

probably not, as background location access is restricted in the latest versions of Android

okay, I also have to say the foreground service looks really good for me for now

overall, foreground services let you do a lot of what you used to be able to do with background services, just at the price of having a notification around

let me take a question from Anshul, and I will be back with you shortly

Anshul: hi! welcome to the chat! do you have a question?

Hi Mark, yes, I am having trouble figuring out how to fit in the Recyclerview Adapter in the MVVM architecture. In general, what is the relationship between the VM, activity and the adapter, how the data flows and from where.

I do not claim to be an expert at MVVM

outside of my own take on MVI, I cannot really comment on how to apply particular Android stuff to particular GUI architecture patterns

ThatFor ex, the VM gets the data from the server, if the activity is just an observer, how do we populate the activity's recycler view, do we hold a reference of the viewmodel in both activity and adapter, or do we make activity as a mediator.

what I have seen done, if you are using data binding and are binding a viewmodel into the layout, is that the RecyclerView gets its data from a binding expression tied to a BindingAdapter

Sorry, I mis-typed some of it. I understand what you are trying to say with the MVI pattern

with MVI, your adapter data is part of the viewstate, where you are observing some stream of those states (e.g., LiveData)

in "Exploring Android", I will be showing getting the data from the viewstate to the ListAdapter just via a simple observer

and allowing ListAdapter to do its diffing work to update its rows as needed

if you prefer data binding, your LiveData<ViewState> can be bound to your layout, and data binding will set up its own observer

at which point, you can use a binding expression and a BindingAdapter to populate the RecyclerView

I don't think I have ever implemented a pure MVVM app, and so while I suspect there is some overlap between the VM in MVVM and a viewstate in MVI, I cannot be certain

this is why I try hard to avoid GUI architecture debates :-)

Ah, I see, I should check out exploring android, but what you are saying makes sense. And I guess if I have an in-mem cache in the viewmodel to store user's response to (clicking a recyclerview item), that would also be done via the binding adapter?

I think so, though I am far from certain

my update to "Exploring Android" that gets into the MVI architecture should be released on Monday, barring unforeseen problems

it also fills in the rest of the stuff that I needed to rework from Java to Kotlin and the Jetpack

let me take another question from Benny, and I will come back to you shortly

Benny: your turn! do you have another question?

My question is about SafeRoomdatabase, as I see the SafeHelperFactory.fromUser needs a Editable as password from the user, I think this is when the user should enter his own password, right?

Ah.. okay, sure!

yes -- if your passphrase is coming from something else (e.g., generated passphrase that you store encrypted using AndroidKeystore), then you would use the SafeHelperFactory constructor that takes a char[]

I have an update coming out sometime that adds a byte[] option as well, as SQLCipher now supports byte[] for passphrases

but, if you are getting the passphrase from the user in an EditText, use the fromUser() method

okay, this would be my question, so if I do not want to user to enter a password I should generated passphrase?

IMHO, the only two decent options are:

1. get a passphrase from the user

2. generate a passphrase, use that with SQLCipher, and save the generated passphrase in an encrypted file using the AndroidKeystore

2. sounds good for me, is there a example in the book for it?

that latter option allows you to tie in hardware encryption, plus possibly require user authentication (e.g., fingerprint, re-enter PIN)

there is a chapter on "Device Authentication" in *The Busy Coder's Guide* that goes through this, though my code there is *awful*

there is updated material on this in *Elements of Android Q*, in the context of some of Android Q's changes to the biometric APIs

thank you very much, i should have checked the book first :)

well, it's a big book :-)

yes, but very awesome as well :)

thanks!

thank you for your support

I am happy to be useful!

I have to leave now, thank you very much and have a nice day!

you too!