Greetings once again.

hello, Paul!

how can I help you today?

Got a couple of questions. First one is a build issue with kapt.

Where is this supposed to be added?

if I had to guess, as a top-level closure in the Gradle script

Unfortunate that it is a guess. :-)

But easy enough to try.

I haven't seen that message, though depending on where/how it shows up, I might not be noticing it

you could just have kapt.includeCompileClasspath = false directly, as that is syntactically identical to the closure I pasted in

I'm using 5.5 beta Gradle plugin as it fixes an illegal state exception for the app I'm working on.

oh

yeah, that's 0.3.9 ahead of where I am right now :-)

I also see this: Annotation processors must be explicitly declared now. The following dependencies on the compile classpath are found to contain annotation processor. Please add them to the testAnnotationProcessor configuration.

Familiar to you?

I haven't seen that error message, but I ran into a problem that resembled it recently

though it would be testKapt, I think

Shall I try my next issue, recycler view.

um, sure!

ok, I am using a FAB button to trigger the network load of some Movie objects which I want to get added to the RecyclerView adapter. The recycler gets set up in a fragment. The FAB listener is in the main activity. How would you get the new data to the adapter cleanly?

why is the FAB listener in the activity, instead of the fragment?

er, instead of in the fragment?

I mean, you can keep it there, and have the activity call a method on the fragment, if you want

The setup was originally part of a Basic Activity courtesy of the Android Studio wizard which set it up with a CoordinatorLayout...

ph

er, oh

in terms of the data flow, though, I don't know what your overall architecture is

in the pattern that I have been using in *Exploring Android* and *Elements of Android Jetpack*, I would have the fragment ask its viewmodel for the data

the viewmodel would work with the repository to get the data on a background thread

the viewmodel would then emit the data, perhaps as part of a view-state, via LiveData

Flat for now. It basically uses your ToDo code but I threw out DataBinding. I think it sucks dead moose balls. :-)

yeah, I can understand that

I have not hooked up a viewmodel yet but I like the idea.

the fragment would observe the LiveData and update its adapter (e.g., call submitList())

I believe you cover this in the ToDo app. Correct?

yes

at least, in the *Exploring Android* one

That's the one.

see "Using a Unidirectional Data Flow"

Ok, I'll look at that code and use that approach.

and the two chapters after it

FWIW, I also cover the same pattern, with different apps, in the latest *Elements of Android Jetpack*

As for databinding, I followed your setup and tried to morph the code to my app. Debugging the result was worse than pulling teeth.

I used it mostly for adherence to the Jetpack philosophy

and, as it turns out, with Jetpack Compose, data binding is likely to be toast in the long term

Good to know about the Jetpack stuff. I have not yet consumed that book.

it's the second-generation replacement for the core chapters of *The Busy Coder's Guide to Android Development*

and the back 25% or so of the book all uses the unidirectional data flow pattern

though mostly sans fragments -- I only used fragments if the sample needed multiple screens

What is the background for this "universal data flow pattern" . Cannot say I've heard or seen much about it.

whoops, I meant unidirectional

basically, having immutable data flowing through the system, with clear points for where that data gets replaced, rather than updated in-place

I think that might have been me.

so, in the ToDo stuff, if you have gotten to the point where I start talking about "motors", my motor classes are engines of a unidirectional data flow

the UI (activity fragment) receives immutable view-states that it uses to populate the UI

the UI calls functions on the motor based on user input

Ah yes, now it is ringing a bell.

the motor does the work with the repository to actually affect real changes (database, network, etc.), then emits a fresh view-state

You had a very nice picture if memory serves.

IMHO, my diagrams aren't the prettiest, but yes, I think I have some diagrams

Although that could have been a blog post I chased down after reading the material.

I have more similar ones in *Elements of Android Jetpack*, in the "Adding Some Architecture" chapter

it's a pattern that has been gaining popularity, sometimes referred to as Model-View-Intent, an name that totally sucks in Android

Personally, I think all these MV* things are a dis-service.

it's definitely a fair bit of alphabet soup, and there's not a lot of agreement over the details of any one of the patterns

which is why I tried to steer away from those terms in these second-generation books

I do believe strongly in Clean Architecture, which to me means develop code that adhere's to good coding principles.

And keep projects small. Too often I see simple projects turn into behemoths, hence the need to add structure. I like to use many artifacts so that my app is small. Put all the smarts into libraries developed with IntelliJ rather than keeping everything Android aware.

fwiw.

there certainly are arguments in favor of that approach, though I think having a multi-module Studio project is a more common way of addressing the concerns

I'm going to get back to my code and follow up with your suggestions. Thanks and talk to you later.