Android dagger 2 github

Dagger 2.40.4

Bug Fixes

Fix #3075: Fixes an issue where we were not deferring processing for a generated type in Kotlin source (745d30c)

Assets

Dagger 2.40.3

Dagger bug fixes

• Fixes #3065: Fixes an issue caused by our XProcessing migration (to support KSP). For now, we’ve replaced all problematic usages of XElement#getName() with XElements#getSimpleName(XElement) which ensures we use the old javac simple name.

Assets

Dagger 2.40.2

Dagger Bug Fixes

• Fix #2997, #3032: Fixed issue with @BindsInstance parameters when bound types are from compiled dependencies. (ec1a98c).

Hilt New features

• Add convenient overloads for Kotlin users of EntryPointAccessors (6e1f0ea)
• @AliasOf now accepts multiple scope annotations. (aa92b9e)

Hilt Bug Fixes

• Fix #3006:Sort dependencies in ComponentTreeDeps manually to give consistent output when doing incremental processing. (93f04ae)

Assets

Dagger 2.40.1

Bug Fixes

• Fix an AGP 7.2 incompatibility issue in the Hilt Gradle Plugin due to AGP breaking their API when cleaning up a deprecated type. (ed677ba)
• Fix #2986 — An issue in the Dagger processor where it would crash due to a bad initialization. (608bcba)

Assets

Dagger 2.40

What’s New in Hilt

New Changes

• Flip the runtime flag default so that the fix is off and remove the compiler option for the Fragment.getContext() fix to make it easier to roll out the fix. This does not change the current default behavior of having the fix be off. (1c24b97, e61ff72)
• Turn ON enableAggregatingTask by default in Hilt (90ea6a6)

Bug fixes

• EarlyEntryPoints#get() will now throw if there are no @EarlyEntryPoint annotated interfaces. (b5ef01c)
• Avoid using UAST implementation classes in Lint checkers. (44e1f05)
• Fix an issue where @OptionalInject activity/fragment classes could not be used with non-Hilt ViewModels. (8ef08fa)

Assets

Dagger 2.39.1

Hilt bug fixes

• Fix #2834: Hilt processor now checks the correct «names» property when getting values from Kotlin @Suppress annotations. (db21d3f)
• Fix #2904: Change toImmutableSet to use DaggerStreams rather than Guava. (43a7fe1)

Assets

Dagger 2.39

What’s new in Hilt

New breaking changes

• The compiler flag shareTestComponents now defaults to true. This may significantly improve test compilation time for large projects, but is a breaking change for some tests due to changed visibility requirements. See Hilt’s flags documentation for details. (7e09cee)
• Hilt compiler flags are now strictly verified. Invalid flags will no longer compile. (742ba95)

Bug fixes

• Fix #2779: Dagger no longer requires the additional google repository mentioned in the Dagger 2.28 release notes. (01cf47b)
• There is now a runtime flag to control the Fragment.getContext() fix submitted in #2620. This allows enabling or disabling the fix without a compiler flag in order to permit a staged rollout. (c3f613f)
• Fix #2789: Fixes issue with using EarlyEntryPoints being dropped when using enableAggregatingTask (38db196)
• Fix a remote cache miss due to @Input parameter in ASM transform. (2f50035)

Assets

Dagger 2.38.1

Hilt bug fixes

• Fix #2784. Fix an issue with AGP 7.0+ where the Gradle plugin bytecode transform was not applied to non-test code. This affected all @AndroidEntryPoint and @HiltAndroidApp classes that did not directly themselves extend from the Hilt-generated base class and meant that Hilt was not actually applied to those classes. (666df50)
• Fix #2762. Fix an incompatibility with AGP 7.0.0-beta05 and 7.0.0-rc01 (09087db)

Dagger bug fixes

• Fix #2765. Properly handle Kotlin metadata when shading dependencies. (ef7e7a1)

Assets

Dagger 2.38

What’s New in Dagger

New breaking changes

Add the Google Maven repository for KSP artifacts

As part of necessary changes in order to eventually support running Dagger as a KSP processor, Dagger now has a dependency on the KSP artifacts. These artifacts are available from the Google Maven repository, so this may break users who currently do not use this repository for other dependencies. The Google Maven repository is available at https://maven.google.com.

Adding the repository in Gradle

In your build.gradle file, add google() in repositories .

Adding the repository in Bazel

If using the repository list from our workspace_defs.bzl , then no change is needed.

Otherwise, pass «https://maven.google.com» to your usage of maven_install .

Adding the repository in Maven

Add the repository in your pom.xml file like the following:

Bug Fixes

• Fix #2576. Check and give a better error message when a user added method has a name that is a java reserved keyword. (436ac2e)
• Fix #2575. Check and give a better error message when a user added method has the same method signature as generated factory methods. (6971d00)
• Fix #2570. De-dupe assisted parameter names and field names to avoid a case where generated code may have naming conflicts. #2570 (3d93625)
• Fix #2710. Allow Dagger-defined map keys (like ClassKey and StringKey ) to be placed on fields in order to support Hilt’s @BindValueIntoMap. (7af40df)
• Errors for requesting bindings from the wrong component now include the component name for each binding along the dependency path for easier debugging. (2335e0f)

What’s New in Hilt

This release fixes an incompatibility in the Hilt Gradle Plugin with AGP 7.0-beta04 and 7.1-alpha03. However, with this fix the HiltGradlePlugin will not work with alpha/beta versions of AGP 7.0 and 7.1 older than the versions previously mentioned. This fixes #2700. (be2f89a)

Bug Fixes

• Fix #2710. Allow Dagger-defined map keys (like ClassKey and StringKey ) to be placed on fields in order to support Hilt’s @BindValueIntoMap. (7af40df)
• Fix #2695. Fix an issue where enableAggregatingTask would not correctly generate Hilt classes when compiling in a dev environment with Windows OS. (a7c3c9e)
• Fix #2672. Fix cast errors when getApplicationContext() is overridden. (4b695ae)

Assets

Dagger 2.37

What’s New in Dagger

Bug Fixes

• Fix #1079: Added an automatic module name to the com.google.dagger:dagger artifact to improve Java 9 compatibility. (cb30885)
• Removed the com.google.dagger:dagger-android-jarimpl artifact. This was an internal-only artifact, so its removal should not affect users. (6da2e7e)

What’s New in Hilt

Build performance improvements for Gradle

There’s a new flag, enableAggregatingTask , supported by the Hilt Gradle plugin that allows Hilt to perform classpath aggregation in a dedicated Gradle task. This allows Hilt’s annotation processors to be “isolating” so that they are only invoked when necessary. This reduces incremental compilation times by reducing how often an incremental change causes a rebuild of the Dagger components. For details on how to enable this flag see https://dagger.dev/hilt/gradle-setup#aggregating-task.

Note that the default for enableAggregatingTask is currently false , but it will be changed to true in an upcoming release, so please try to enable this flag and report any issues.

Also, note that enableAggregatingTask will automatically enable sharing test components , so please read the caveats for enabling that flag as well.

Finally, enableAggregatingTask replaces enableExperimentalClasspathAggregation which will be removed in an upcoming release. Please replace any usages of enableExperimentalClasspathAggregation with enableAggregatingTask .

Источник

Android dagger 2 github

Android Dagger 2 Tutorial

This guide explains how to use Dagger 2 in Android. I will go through the simple setup, explain what the dependency graphs are and how to provide custom annotations.

You can find the final code in my GitHub repository:

I use Android Studio 3 Canary 7 in this tutorial.

In this tutorial we will use the following libraries:

Create two productFlavors which we’ll use later to show, how Dagger can improve injection based on external settings.

The resulting build.gradle can be found here:

Since we use the annotationProcessor, be sure to activate «Annotation Processing» in Android Studio.

This guide is all about Dagger. To show you some advantages which come with dependency injection, I created some fake app model. We will have a LemmingsRepository, which loads Lemmings from somewhere. We will also have a Lemming model, which stores the lemming data.

A simple pojo which stores data of a lemming in a class.

A repository is a source of data. You can provide an interface of a repository and implement as many repositories as you want.

This example is incomplete and does not provide ways to handle asynchronous datasources as REST endpoints.

If you want to know more about repositories and how to implement them correctly, have a look at my other guide:

We will implement two repositories:

The Repository is a base interface which allows implementing classes to define the model and id class. It provides the usual CRUD operations.

The LemmingRepository defines the datatypes of the model and id generics.

The LemmingCacheRepository implements the LemmingRepository and stores the lemming data in memory. Again — don’t expect that this implementation is good or working — it is just an example.

The counter part to the cache repository is the LemmingRestRepository, which communicates with a rest api.

Dagger uses components and modules. A components combines modules into a set of dependency providers. Each module knows how to provide certain dependencies. Components should be used per domain and have defined lifecycles.

Let’s start to prepare the dependency graph. But what is the dependency graph? Dagger has no predefined structure and inheritance rules. You as a developer can decide which components depend on other components, what dependencies live during a component’s lifetime and which should be recreated each injection.

This is how the components depend on each other. The AppComponents creates singletons and app-wide dependencies. The LemmingComponents provides dependencies for the lemming domain.

This class is used during injection to decide if some injection results use online or offline features. It will be used later during the AppComponent creation.

The AppComponent uses two modules:

The AppModule provides the application context and the ApplicationConfig, which are both stored as a singleton in the AppComponent. To allow other components which depend on the AppComponent to access the ApplicationConfig and the LemmingRepository in this component, we have to define two methods:

• ApplicationConfig config()
• LemmingRepository lemmingRepository()

If we wouldn’t define the methods, the LemmingComponent would receive new instances of both components. This would be a problem for the ApplicationConfig, because we need to have the same information in all classes.

The inject method describes, who is allowed to receive dependencies from this component. In this case, only the DaggerApplication can be injected.

The AppModule provides the application context, DaggerApplication and the ApplicationConfig. Each of them are provided as a singleton. The @Singleton annotation is the same as the one in the AppComponent. If the component’s annotation and the provides annotation match, the created object is treated as a singleton in this component. If you leave out the annotation in the provide methods, every time when there is an injection the module creates a new instance of the class.

The repository module decides, which repository will be injected. In our case we have a boolean flag in our config, which marks, if the online mode is enabled or not. The ApplicationConfig is injected by dagger. Since this module is used in the AppComponent, it receives the singleton config object provided by the AppModule above.

The DaggerApplication class prepares the Dagger dependency graph. It initializes the AppComponent and decides, if the app should use online features or not. If another component depends on this AppComponent, it can receive the created AppComponent through:

The AppComponent uses two modules, which need to be created during the component creation:

After we’ve prepared our AppComponent, we can start building other domain components. The LemmingComponent provides all dependencies required in the lemming domain of this app.

As you can see, we’ve marked this component as ActivityScoped. Since we depend on a Singleton-scoped component (AppComponent), Dagger forces us to create a new annotation with a weaker scope. Dagger can detect by itself, which annotations are weaker than others and builds an internal graph based on this information.

Each scope annotation looks like this and the only thing that differs is the name of the annotation.

Let’s head back to the LemmingComponent. This component uses one module — the ActivityModule and allows the LemmingActivity to be injected by this component.

The ActivityModule provides a String method to show in an exemplary way, how you can decide which object to return based on app settings. In our out of the question useful example, we return «Online» or «Offline» based in the isOnlineAllowed() method in the ApplicationConfig.

A new annotation is introduced here

Dagger decides which method to call when injecting by its return type. If you have two methods with the same return type, you have to name them by adding a @Named annotation. In the class, which receives the injected objects, you need to add @Named() to the @Inject annotation to tell Dagger what to inject.

We inject two object into this activity

The LemmingRepository is provided by the AppModule in the AppComponent. The mTitleSuffix String comes from the ActivityModule in the LemmingComponent. Since the LemmingComponent depends in the AppComponent and the AppComponent allows the LemmingComponent to access the LemmingRepository, we receive the same instance as stored in the AppComponent.

The creation of the LemmingComponent looks like the creation of the AppComponent in the DaggerApplication class. Since we depend on the AppComponent, we have to get it from the DaggerApplication class.

Start the app in one of the two flavors. If you pick the online flavor, the activity will print «LemmingRestRepository» and the title will be «Dagger2 — Online».

Switch to the offline flavor. The app should now show «LemmingCacheRepository» and «Dagger2 — Offline».

I went through a quick example to show you how to use Dagger 2. The guide explained the dependency graph and scopes, how to create singletons and what is required to allow components to use dependencies from other components.

This guide picked created a case, where to product flavors needed different behaviour in some cases. Dagger had to decide, if it used the offline or online implementation of the LemmingRepository during injection and which String to return for the title in the ActivityModule.

Dependency injection is a good way to get rid of the singleton antipattern. When required, you can easily manipulate what is being injected in the providing methods and do not have to copy & paste big if-else constructs into classes. Classes do not need to know where «things» come from and how to get them anymore.

About

Tutorial to get started with Dagger 2 and Android

Источник