was just looking at Dagger, the scopes seem to lack something comparable to a conversation? Activity...

# android

[codeslubber]

was just looking at Dagger, the scopes seem to lack something comparable to a conversation? Activity scope is not great because the Activity is not remade each time, so for instance, a wizard would not work with that scope, correct?

[maciekjanusz]

codeslubber: dagger or dagger2?

[maciekjanusz]

anyhow, ALL scopes are custom

[codeslubber]

yeah I was going to look at 2..

[maciekjanusz]

scope is directly related to the component

[maciekjanusz]

it's the component which manages instances and scope annotations help maintain coherence around those

[maciekjanusz]

so, if you want to have an activity scope (speaking abstractly), you need to make sure that one activity holds one component

[maciekjanusz]

any @ActivityScope annotation will just enable the annotation processor to make sure the setup is correct

[maciekjanusz]

so to say

[maciekjanusz]

it gets more complicated with subcomponents and dependent components - think of those as a hierarchy of components

[maciekjanusz]

top-level component has to have a different scope than its children subcomponents

[codeslubber]

@maciekjanusz you know what a wizard is right?

[codeslubber]

multi-panel flow of data collection?

[maciekjanusz]

yup I know what you mean

[codeslubber]

reading some more of the docs

[codeslubber]

looks like I should create a custom scope

[codeslubber]

for that…

[maciekjanusz]

like I've said ALL scopes are custom

[maciekjanusz]

you don't have anything such as predefined activity scope

[maciekjanusz]

which works automatically for android activities

[maciekjanusz]

dagger2 is not even an android specific library, it's an implementation of java JSR-330 dependency injection standard

[maciekjanusz]

see this example https://github.com/frogermcs/GithubClient/blob/master/app/src/main/java/frogermcs/io/githubclient/ui/activity/SplashActivity.java#L74

[maciekjanusz]

the line GithubClientApplication.get(this) obtains the Application class object which is an 'entry point' for android apps (this object lives as long as the app process)

[maciekjanusz]

line .getAppComponent() obtains the application component, which has the @Singleton scope

[maciekjanusz]

line .plus(new SplashActivityModule(this)) creates a new ActivityComponent which is a subcomponent of AppComponent with added SplashActivityModule

[maciekjanusz]

this doesn't happen magically, but is declared here https://github.com/frogermcs/GithubClient/blob/master/app/src/main/java/frogermcs/io/githubclient/AppComponent.java#L24

[maciekjanusz]

finally, .inject(this); happens, which injects the activity object with dependencies from the ActivityComponent and AppComponent as well

[maciekjanusz]

if another activity does that also, all the dependencies from AppComponent will be shared, because there is only one AppComponent, and the ActivityComponent dependencies will not, as these are created separately for each activity

[codeslubber]

cool thanks @maciekjanusz

[maciekjanusz]

now, whether there's a scope annotaton with module @Provides method will determine if the component instance will create a new instance of a dependency each time it's needed, or whether it will be a singleton in this component scope.

[christiangruber]

Adding to Maciej above, you can reasonably add a scope for any particular lifetime for which you need to memoize an instance, and pretty easily if they're "concentric" lifetimes (e.g., application is "wider" than "activity"). So if you want a conversational scope, you add it in between application and activity. But you can do this with a variety of things. I've seen teams create "configuration" scopes, where they push a live configuration and after the activity is done, the new configuration is swapped in, wiht subsequent activities being recreated in the context of the new configs, etc.

[christiangruber]

The key, as Greg put it, is that dagger helps you manage lifetimes by generating the infrastructure, but you decide when to create/dispose of a given component that encapsulates that lifetime.

[christiangruber]

Then @Scope annotations attached to a component form a constraint meaning "the only things that can be memoized in this component are ones so annotated". Then you add the same scope to your @Provides and @Inject-able types which declares your intention for those classes. This lets the Dagger processor complain if you mixed up your modules.

[codeslubber]

Thanks.