Hello

hello, Kai!

how can I help you today?

I have a question about the "diceware" example from "Exploring Jetpack"

do you literally mean Diceware? or DiceLight? or DiceKoin?

In that example, the Motor executes a "generate()" function in an exectutor

(I have a few variations on the diceware sample)

I think I mean Diceware

so, you are referring to https://gitlab.com/commonsguy/cw-jetpack-java/-...

Exactly

we are doing I/O (either reading a document or reading an asset), so we want a background thread somewhere

in this case, I put the background thread in the motor

in other examples, I will use other approaches

I wanted to know if that is good design. It feels like it should rather be done in the repository itself.

all else being equal, I would put the threading in the repository

however, my options for doing that in Java suck

Why not just have the executor in the repository?

how will the motor get the results?

we'd need some form of callback

which means the repository needs to track that callback, deal with cases where the motor gets cleared before the results are complete, etc.

That would be something like RXJava I guess.

right

if I were in a pure Java project, and I needed to do this, I would use RxJava

however, I desperately want to avoid RxJava in this book

With good reason ;-)

what I might do, perhaps for Version 1.1 of this book, is try something like a Future

And I guess you didn't wanna use a LiveData at that point because using LiveData in the repository is bad for testability?

I'm not a fan of LiveData in a repository, though I think I have an example of that in the book too

LiveData is really for delivery of results to the main application thread

and it is annoying to work beyond fairly simple scenarios

so, using it for "last mile" delivery of results to the UI layer is fine

but I'd rather steer clear of it until that point

You do have an example in the book and I was wondering about that.

on the whole, the Kotlin examples are far closer to "best practices", because I can use coroutines

I mean an example where you have LiveData in the repository.

Ook

the Java examples are more like "how can I get the point across without a ton of extraneous crap?"

That is good to know, as I follow them somewhat closely

(even though that "crap" is not truly extraneous if you were doing this for real)

on the whole, my book examples aim for "not horrible" with respect to architecture

and the Kotlin ones tend to be "eh, not too shabby"

but I will try a different approach for the Diceware sample in Version 1.1, later this year, to get the thread out of the motor

How will you try to do it?

(As I have literally that in my personal app atm)

(The thread in the motor, I mean)

I'll see about having the repository return a Future

that at least is incrementally cleaner than a callback

the repository would then use something like FutureTask with its own executor

But if I wanted to do it best practice I should probably follow one of your examples that use RXJava, right?

hopefully nothing in *Elements of Android Jetpack* is using RxJava, unless I have really screwed up

I have RxJava examples in some first-generation books

though they have their own issues with respect to age and architecture

for a personal project... unless you are giving yourself some deadline, I'd focus on learning Kotlin and coroutines

IIRC, the project at your job is a pure-Java project, but ideally your personal experiments are aiming to improve your career prospects -- right now, I'd put Kotlin higher on the importance list than RxJava, though both are good to learn

Kotlin is on the upswing, while RxJava is not (mostly from people switching to coroutines with Kotlin work)

or, as Wayne Gretzky put it, "skate to where the puck is going"

but, if you're sure that you want to stick with Java, learning RxJava is a reasonable step

it's just a fairly big step

Yes, the example about RXJava is from "Architecture Components" iirc

And the reason I am still using Java even in my personal project(s) is because I don't wanna do too much at the same time

And I want the things I learn in my personal project(s) to be applicable to work as well, preferably.

you will then need to decide if RxJava is "too much"

My personal project is part "modern android", part trying things I could use at work to make things a bit better there.

Is there no RXJava basics that are not THAT hard and that will carry you quite a bit?

Like the amount of RXJava used in "Architecture Components"? (I haven't looked at the whole book, just some snippets of it)

we often talk in terms of Pareto-style outcomes ("20% of the complexity solves 80% of the problems")

RxJava is not that gentle

ideally, when adopting a technology, trivial things are trivial and complex things are complex

with RxJava, trivial things are not as trivial as they should be, and complex things are "OMG"

though it is still better than most Java alternatives

just because once you get into the framework and get things set up, incremental improvements often require just incremental changes

I have a chapter on RxJava in *The Busy Coder's Guide to Android Development* that serves as an introduction

that focuses on RxJava in isolation, not from an architecture standpoint, but it introduces the major concepts (schedulers, operators, subscriptions, disposables)

so, I'm not saying "avoid RxJava" -- I am saying "bear in mind that RxJava isn't a walk in the park"

So I'll really have to decide if I want to learn RXJava. It would be a shame to spend a considerable amount of time on it, just to never touch it again.

if you think that your work project might adopt RxJava and you want to play with it in advance, great!

right

Even though I hope that the basic ideas will still be there in the future, maybe just in another form.

agreed: the other way to look at your RxJava experiments is to consider them "getting your feet wet" with reactive programming

How well can RXJava be debugged btw?

that depends on the type of bug, I guess

I rarely run into problems with RxJava itself

Because that is one thing I like about "low level no magic" solutions: You can look into them.

and breakpoints, Log.e(), etc. work normally

I am thinking about trying to understand why something doesn't work the way I thought it should.

if you mean stepping through the RxJava code in a debugger, oy

Which should be fairly often with something as hard as RXJava

yeah, that's a significant pain point

Well, I can decide to have a go at it and see how far I'll come :D

And I guess there is no good alternative if my workplace doesn't want to switch to Kotlin?

to put it in some perspective, I'm not bad with RxJava, but complex RxJava "chains" might still take me a day to get working correctly

there's nothing with the power or brand recognition of RxJava

Right now we use Loaders and AsyncTask left right and center

AsyncTask is officially deprecated, once you raise your compileSdkVersion to 30 (or 'android-R' for the next few weeks)

I have never liked Loader outside of very narrow use cases (e.g., CursorLoader and a ContentProvider), and even that is largely toast given modern architecture patterns

the Future framework (Future, FutureTask, ListenableFuture, etc.) is the lightweight reactive API baked into Java

but that dumps the threading itself on your lap, handling only the reactive delivery of results

LiveData is the next level up, handling part of the threading for you (getting results to the main application thread)

(also: built-in lifecycle awareness)

after that, in terms of things that you will see developers use, you're into RxJava or coroutines

I'm sure that there are other options out there, but they aren't very widely used

so, I recommend reading that RxJava chapter in *The Busy Coders' Guide to Android Development*, then making decisions after that

in terms of résumé fodder, saying that you have some experience with RxJava beats *not* saying it :-)

Hehe

But you're right, in terms of résumé fodder it's best to know Kotlin and Coroutines.

those have longer-term value

I guess we'll have to move away from Java in the long run, if we want to stay "modern".

in the end, it will become a matter of recruiting: will developers elect to not work for your firm if they feel that they will become stagnant?

this does not mean that you have to adopt every new technology that comes down the pike

but, once "the writing is on the wall", you need to have a plan to move forward

I have a talk coming up on Jetpack Compose, where that is the theme: given that this is likely to be a "the writing is on the wall" technology in 3 years, what steps might you take today?

What does "writing on the wall" mean?

oh, sorry

as I used it here, consider it to mean "it is clear to become dominant"

Ok

Thanks for your input today :D

you're welcome!

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

next one is Thursday at 7:30pm US Eastern

have a pleasant day, and stay healthy!

Have a good time