Hello

hello, Kai!

how can I help you today?

When using Koin, why would you have several Koin modules? What is the advantage?

well, I haven't needed it personally, as my Koin projects tend to be small

I think one scenario is for reloading the module

for example, suppose you have a bunch of stuff going through DI that is tied to a user account

and you want to support logout and login

after a user logs out and logs in, you need to "reset" all those injected elements to reflect the new user account

but, not everything is necessarily tied to that

so, you could have two modules, one that gets reloaded on logout/login, and one that does not

at least, I think this is one of the scenarios

I have only scratched the surface of Koin in my own work

Ok. What did you use instead?

well, my customer projects tend to use Dagger

Dagger2 I guess?

yeah, sorry -- the original Dagger is long since deprecated IIRC

I tend to drop the number

I have to watch out for that with RxJava, though, as both 2 and 3 are still relevant

So you guess that Koin modules are "organisational units" to be able to do something on several injected classes but not others?

that is my gut instinct

but, again, I have not used multiple modules yet

I tried googling but didn't find anything

It's just that almost every example that is not trivial uses several modules.

¯\_(ツ)_/¯

Another question I have is how you feel about all this "auto generation" that is going on, for example for View Binding, Views, Jetpack Navigation etc.

I'm not sure what "Views" means in this context

Navigation has two tiers of code generation: standard R stuff for the navigation resource type, and SafeArgs

both are going to fade out, being replaced by Kotlin DSLs (for fragments and for Jetpack Compose)

That was supposed to be part of view binding.

ah, OK

view binding is better than many alternatives (e.g., Kotlin synthetic accessors), though it too is on the chopping block long-term, as Compose starts to eliminate the use of layout resources

The reason I ask is that it makes me a bit uncomfortable. It feels like there is no control and too much "magic".

oh, well, *that* aspect of matters is not going away

And sometimes classes are not there and I need to re-gradle or rebuild and be lucky.

And Android Studio suggest the wrong classes to import and so on.

code generation is a major element of modern development, though

annotation processors are code generators

R is code generated

Compose is powered by compiler magic

and so on

So I just need to accept that there is magic

to an extent, yeah

IMHO, this stuff is great for newcomers, great for experts, and is less great for the middle tier

newcomers have less to learn to get going

experts can get more done with less syntactic overhead

At least when developing Android. But I guess "magic" also applies to a lot of other areas

yes

in many respects, "magic" is a line that you draw

once upon a time, compiled programming languages were magic

then, virtual machine-based languages were magic

each language has its own stuff that is magic compared to other popular languages at the time

and so on

different developers will adapt to newer forms of magic at different rates

and that varies both by developer and by form of magic

in other words, "it is what it is"

So you think with time we will grow used to it?

yes, for most developers and most forms of magic

I hope I can do that.

bear in mind that it may be that "do an end-around" the magic by switching to something completely different

your thoughts on Android app development magic will be less relevant if you switch to, say, Web service development

But isn't there a lot of magic as well?

yes... but you might not perceive it as magic

it will just be "this is how it works"

where "magic" starts to be a problem is when you know what came before and are trying to figure out how the new stuff equates to what came before

I think that "magic" becomes a problem when things stop working ;-)

that's the "middle-tier" developer that I mentioned earlier, and they are the ones at biggest risk of stumbling over magic

to an extent, but that is as much a question of tooling as magic

(Or when I need to change something that happens inside this magic)

and as a newcomer to some new environment, you will not (yet) be in position to change something that happens inside the magic

So I am a middle-tier, as I have legacy Java and possibly want to move to modern-Kotlin.

right, and some aspects of the changing Android development ecosystem may be magic

and buggy tools will make that magic be aggravating, but with time, bugs get fixed

So I just need to trust that and learn to use it.

pretty much, yeah

And stretch my frustration limit.

that too

you could try yoga, or herbal tea, or something :-)

lulz

What is your secret?

I mean, I vent a *lot*

How?

sometimes, that is via the issue tracker

sometimes, that is via blog posts

(occasionally, both)

I relate to Doctor Banner in that and programming can make it worse. I oftentimes swear and sometimes scream.

sometimes, I vent via snide comments that I make in books that I write

sometimes, I vent via snide comments that I make in Stack Overflow answers

now, most of that is not about the magic, though some of that is magic-related bugs

and, where I can, I try to help others deal with the magic, via those books and blog posts and Stack Overflow answers and stuff

magic-relateds Bugs :D

Maybe I should write a blog too.

I usually vent to ppl around me.

and if they're willing to absorb it, there is nothing wrong with that

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

Have a good time

you too!