Learning more about dagger and I want to sanity ch...

# dagger

[Colton Idle]

Learning more about dagger and I want to sanity check how plausible this sounds. I really want to simplify my app with dependencies and components/scopes.

I think I want to have 3 scopes defined.

1. Application scope
2. Logged In User scope
3. Logged Out User scope

So in my head I'll have 3 components
ApplicationComponent, LoggedInComponent, and LoggedOutComponent. How does that sound at a high level? I feel like it will solve 90% of my problems for me and it'll give me a chance to learn about scopes/components, provides/modules, and how to actually wire that up into my fragments/activities/all other classes.

[gildor]

Not sure that it’s the easiest case to learn scopes and componetnts

[gildor]

I would start from fragemtns/activities first

[gildor]

also if you just starting, are you try to learn vanilla dagger for Andorid or with Hilt? because those are quite different things in terms of approach for scoping

[David]

Yer, the way I learnt about scopes w/ backend Java was in terms of lifecycles…usually just 3; Singleton, Request, Session. Android has infamous lifecycle hooks that usually describe exactly what I want;

e.g “an object to live as long as an activity, surviving config change” => a Dagger un-scoped AAC VM dependency

e.g “an object living as long as my application” => a top level Dagger module @Singleton provided dependency or just something owned by android.app.Application will get you there.

e.g. “request scope” => a function param that you could just leave Dagger out of completely (the whole DI is pattern, not a library and all that) or if you wanted to then inject that in other functions then that’s got a snazzy name, Assisted Inject.

I’ve rarely found myself needing to write @LoggedInScope made famous by the Uber-Ribs example way back then. It was complicated and confused me.

[Colton Idle]

@gildor I'm trying to learn vanilla dagger as I think it will give me a better grasp on DI in general + demystify certain things in Hilt.

Now I'm just really lost. I thought the whole point of dagger is dependency injection + scoping, but it just seems like everyone wants to just scope things to an activity/VM or fragment/VM.

What about scoping across multiple activities? Like an entire user flow or something?

[gildor]

What about scoping across multiple activities

@Colton Idle You can do this, but problem that it’s not so easy not because of dagger, but because lifecycle of Android
Essentially, to have a scope between multiple activites it should be created and managed on Application level
So there is no issue to create subcomponent/component on application level for this particular scope, it just become a problem that you cannot use any activity/fragment/view dependencies in such approach, only application level + your scope

everyone wants to just scope things to an activity/VM or fragment/VM

It happens mostly because of 2 reasons
1. Hard to avoid limitation of android lifecycle, and most. natural and practical apporach is follow android components lifecycle
2. It require boilerplate code to create custom scopes (aka components/subcomponents for a scope), so usually amount of scopes limited, because first you need to register this scope and provide a way to access it on level of your activity/fragment/view model
Tho, approach with “Logged In User scope” is quite common and it usually subcomponent of application scope

[gildor]

demystify certain things in Hilt

What kind things? Hilt docs are explain philisophy and structure of it pretty well

[gildor]

@LoggedInScope made famous by the Uber-Ribs example way back then

it can be used not only with Ribs, also ribs is single-activity approach, so it doesn’t have issues with activities lifecycle
But also require quite a lot of boilerplate (which partially solved by code generators to generate those components)

[Colton Idle]

Interesting. Thanks for the info. I didn't know ribs made use of LoggedInScope. I just found it natural to have 3 scopes in the beginning because I can have:

1. App scope (share database, and okhttp)
2. Logged in (share CurrentUser, User Preferences, etc.)
3. Logged out (not really sure, but I guess It would be nice to have the separation of scopes so that I couldn't get an instance of a user while on a logged out activity/fragment)

[gildor]

in ribs not only logged in scope, there is everything is scoped

[gildor]

essentially all scopes above are app-level scopes

[gildor]

it’s possible to do, you just need a way to access them from your activity/fragment