https://kotlinlang.org logo
#android
Title
# android
c

codeslubber

05/19/2017, 3:52 PM
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?
m

maciekjanusz

05/19/2017, 3:57 PM
codeslubber: dagger or dagger2?
anyhow, ALL scopes are custom
c

codeslubber

05/19/2017, 3:59 PM
yeah I was going to look at 2..
m

maciekjanusz

05/19/2017, 4:01 PM
scope is directly related to the component
it's the component which manages instances and scope annotations help maintain coherence around those
so, if you want to have an activity scope (speaking abstractly), you need to make sure that one activity holds one component
any
@ActivityScope
annotation will just enable the annotation processor to make sure the setup is correct
so to say
it gets more complicated with subcomponents and dependent components - think of those as a hierarchy of components
top-level component has to have a different scope than its children subcomponents
c

codeslubber

05/19/2017, 4:11 PM
@maciekjanusz you know what a wizard is right?
multi-panel flow of data collection?
m

maciekjanusz

05/19/2017, 4:11 PM
yup I know what you mean
c

codeslubber

05/19/2017, 4:11 PM
reading some more of the docs
looks like I should create a custom scope
for that…
m

maciekjanusz

05/19/2017, 4:12 PM
like I've said ALL scopes are custom
👍 1
you don't have anything such as predefined activity scope
which works automatically for android activities
dagger2 is not even an android specific library, it's an implementation of java JSR-330 dependency injection standard
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)
line
.getAppComponent()
obtains the application component, which has the
@Singleton
scope
line
.plus(new SplashActivityModule(this))
creates a new
ActivityComponent
which is a subcomponent of
AppComponent
with added
SplashActivityModule
finally,
.inject(this);
happens, which injects the activity object with dependencies from the
ActivityComponent
and
AppComponent
as well
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
c

codeslubber

05/19/2017, 4:23 PM
cool thanks @maciekjanusz
m

maciekjanusz

05/19/2017, 4:23 PM
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.
c

christiangruber

05/20/2017, 12:43 AM
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.
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.
☝️ 1
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.
c

codeslubber

05/20/2017, 1:47 AM
Thanks.
2 Views