hello, Kai!

how can I help you today?

Hello Mark!

By answering some questions, I hope?

I can try!

no promises!

:-)

No pressure

I have actually been fighting to implement a Dialog with DialogFragment :D

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

I ended up doing it with a callback that I would re-set in onCreateView by grabbing the DialogFragment with findViewByTag(...).

And I wondered if there is a "modern" way to do it.

I guess I do not understand the scenario. What is the callback for?

To get the "onPositiveButton" into the calling Fragment.

OK, so your concern is: how do you get results from the DialogFragment to the Fragment that displayed it?

The result sharing was done with a ViewModel. It was the submit/ok event that I needed somehow.

I tried with LiveData but couldn't get it to work.

LiveData on its own, since it is a value holder, is not great for events that you want to consume exactly once, not once per configuration change

And had the feeling that I misused LiveData for an event there and shouldn't do that.

the original solution, and the one that I profile in a couple of spots in books, is the "single live event" pattern

https://wares.commonsware.com/app/internal/book... for example

this is an somewhat-officially-sanctioned hack for using LiveData for events (in that Google engineers first proposed it)

if you are using Kotlin, you could use a BroadcastChannel for this sort of thing, and my slow-in-coming *Elements of Kotlin Coroutines* update will explore that a bit

in a Java app, though, I'd use the single live event pattern, as the least-bad option

Is that in Exploring Jetpack too?

possibly, give me a minute to hunt around...

hmmm... perhaps not

yet another thing to consider covering there...

Ok. That's the one I am currently reading and I just wondered if I missed it.

But I do have access to Exploring Android too ;-)

callbacks can work, but you need to be careful that both fragments are talking to the right other fragment, after a configuration change

and a viewmodel holding a reference to a fragment is architecturally icky

Yes. And I really don't like the extra setup stage and stuff

I actually hold the reference to the parent Fragment in my DialogFragment

let me take a question from Roberto, and I will return to you in a bit

sure

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

Hello Mark, how is going?, I'm implementing an ObjectRepository / NetworkBoundResource following Google's Guide to app architecture (https://developer.android.com/jetpack/docs/guide)

In the guide they implement this NetworkBoundResource which takes care of fetching objects from network and updating database. It's used by the repository.

I know it's not part of your books and this may not be a good question but perhaps you can give some guidance

The question is

that I would like to avoid using MediatorLiveData in the NetworkBoundResource and avoid callbacks hell

Are you expliring the use of coroutines for cases like this in your books/examples?

r/expliring/exploring

yes, at least to an extent

my take on the ever-popular to-do app -- the subject of *Exploring Android* -- uses coroutines for all the repository/data source stuff

at the viewmodel, those get adapted to LiveData for consumption by the UI layer

Great, that's exactly what I want to do

however, there, the focus is on the Room-based local data source

my only network bit is more of an import operation than an ongoing sync

mainly because I *really* don't want to have to maintain a Web service and accounts and stuff for that book :-)

haha, makes sense. Ok. I'll check that example

in *Elements of Kotlin Coroutines*, particularly the upcoming long-awaited 0.2, I'll be exploring this a bit more

and I have some Retrofit examples here and there, though in those cases mostly without a local database

I'm actually reading the Elements of Kotlin Coroutines version is published, I'm quite enjoying it. You made me remember the DLL version issues... that was very deep and forgotten on my memory :D

yeah, fun times (not)

the only example that I can think of that uses both is the weather app in the current *Elements of Kotlin Coroutines* that grabs weather forecasts from the US National Weather Service and inserts them into a Room database, plus displays the Room contents in a RecyclerView

that's in the hands-on tutorial appendix

but all of that is still fairly trivial in scope

Ohh.. that's interesting. I'll check that too

It might be what I need because I think I know what I want to do... just need to fill some conceptual gaps and know how to wire everything

Do you have an estimated date new version of Elements of Kotlin Coroutines new version?

hopefully a bit less than a month

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

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

Great, thanks Mark

Do you have (an) example(s) of a "wizard" in any of your books?

you mean a sequential series of screens, with forward/back options? then no, sorry

Yes, that is what I mean.

if you mean a dude with a long pointed beard and a hat with moons and stars on it, then no, sorry

There seems to be no "canonical" version out there.

:-)

Neither? Huh.

you'll find some referred to as "steppers", a name which I assume comes from some other platform

but yeah, Google never published one and I am not aware of a single "go-to" implementation

I think there should totally be a bearded dude in one of your books somewhere.

I'd have to hire an illustrator -- my drawing skills are... ummm... lousy

You said in the last office hours that you use them sometimes, so I was wondering.

I haven't needed one in about 18 months, and I forget if we used a library or just some fragments for that one

Is it an uncommon use case?

looking at the roadmap for my current client, we'll probably be needing one for a revised "onboarding" experience in the coming months

it's not uncommon, but the precise presentation usually varies

which then raises the issue: what exactly is the library going to do for you?

You mean what I try to achieve?

There is a "start a new task" thing in our app, which requires several pieces of input from the user.

it's more that I suspect that a lot of places can't use a library because the library implements one look-and-feel and their designer wants something else

if you subtract out the navigation elements of the wizard (forward/back, perhaps dot indicators for place in the sequence), there really isn't a lot to a wizard

Oh ok. So one would do something with ViewPager2 and possibly Navigation?

classically, a ViewPager would be a common base

I haven't yet had a need for ViewPager2, and I don't know how it would blend with Navigation (or if that's even practical)

so it might be either ViewPager2 (with pages per wizard step) or Navigation (with plain fragments per wizard step but using Navigation to step between them)

the modern take on a wizard implementation is something I'm likely to need to chase down here soonish, but I haven't had to yet

Okay

let me take another one from Roberto, and I'll come back to you afterward

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

Roberto: if you come up with another question, let me know!

in the meantime...

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

I think I do :)

I was tempted to do a ViewModelFactory to be able to pass parameters to the constructor of a ViewModel and wondered if you end up with lots of ViewModels and ViewModelFactories in a normal app.

I only have so much experience with "normal apps", so I can't really answer that

I have two ViewModels so far and wanted to do that for both (ended up having a "initializeIfNotInizialied(...)" method on one).

also, if you use a dependency inversion framework (Dagger, Koin, etc.), you often wind up creating ViewModels differently

the DI framework basically has the factory, either "out of the box" or via some glue code that you create

Mark, no questions, thanks for your help. I'm already reading the examples you mentioned.

Roberto: OK, sounds good!

Kai: so my guess is that relatively few projects implement a lot of factories, because projects that big probably are using some form of DI

So once I start using dependency inversion I will probably not stumble over the "parameterized ViewModel" problem so much anymore?

it's more that you'll get it for free (more or less) as part of DI, at least for injectable stuff

I see. So kinda looking forward to start learning about and using DI

my client projects have been using Dagger, and it's the heavyweight industrial-strength solution

In the meantime I guess I'll just initialize my ViewModels with a method if I really need initialization

yeah, particularly in a Java-centric project, until you want to climb Mount Dagger, your choices are annoying factories or skipping that sort of initialization

Google is supposed to be coming out with some Dagger improvements to help with usability, which will be interesting

Is such a way of initialization a code small or does it have any big downsides that you can think of?

in Kotlin, particularly for smaller projects, Koin is very nice

the biggest challenge probably is in configuration changes

if the data you are supplying is immutable, the fact that you call the method a couple of times may not matter

I actually is in my case.

if the data that you are supplying is mutable, though, now you have a problem, as the viewmodel needs to know whether to use the value it has or the value you are re-handing it

Ok

in your case, then, so long as that method is idempotent (you can call it N times without issue), you should be OK

Another question if I may?

fire away!

We have a "Session" object in our app, which holds a couple of caches, a connection and such. I wondered if that would be a Repository in modern app development.

Repository as the green box in "Android Architecture" by google

one or more repositories, yes

Sorry, orange Box

I guess in a bigger app one would end up with more than one repository?

the projects that I have worked on with repositories tend to have several, based on the data they work with

Divided by the kind of data that they hold?

right

having a single massive repository becomes a testability nightmare

Could you give a quick example on the data?

I figured. It's really tempting to have a "god repository" (as it is to have a god session object).

gods have a tendency to fling lightning bolts through your codebase

anyway... suppose we were creating an online bookstore, named after a major river

having one repository handle books and orders and bookmarks/favorites and customer profile data and all that would be too much

you would wind up with thousands upon thousands of lines of code in a single class

it doesn't have to be "one repository per entity", but it's closer to that than "one repository per app"

So you would have a repository for each

I would be leaning in that direction

but, for example, suppose that the app had favorites and history

from a UI standpoint, those might be presented a lot differently, but in terms of data storage, they probably are very similar

so, having those in one repository might be reasonable, particularly if there are operations that affect both types simultaneously

Would a repository often be a singleton?

hah, I just commented on that very topic a couple of hours ago on Stack Overflow

"Repositories, where used, are almost always singletons. However, ideally, they are managed by a dependency inversion framework (Dagger, Koin, etc.) rather than being ordinary static Java fields, Kotlin object, etc. That way, the consumers of the repositories can use mocks or fakes in testing. The repository itself then often delegates to "data store" objects for saving things to files, databases, the Web service, etc. The repository handles details of converting between models used by the main app and the objects needed by those data stores (e.g., Room entities, Retrofit types)."

Link pls :D

Thanks.

So much to learn

yep

Can be quite overwhelming

I remember when I first taught a week-long Android course, back in 2009, and how much ground I could cover (maps! audio/video playback! WebView!)

things got complicated in the intervening decade

it's almost like people are expecting their apps to be well-written or something

Not on my watch!

ummmm....

;-)

LOL

anyway, that's a wrap for today's chat

the next one is Thursday in the 8:30am US Eastern slot

Have a good time everyone

see ya!