Purpose of proxyProvide in Dagger 2 generated code

Question

I have this Dagger module. I want to understand the generated code so I can verify that my Dagger configuration is optimal.

@Module
public class TypefaceModule {

    @Provides @Singleton @Named("Roboto Light")
    static Typeface provideRobotoLight(AssetManager assets) {
        return Typeface.createFromAsset(assets, "fonts/Roboto-Light.ttf");
    }

}

Here's the generated code (Dagger 2.14.1):

public final class TypefaceModule_ProvideRobotoLightFactory implements Factory<Typeface> {
  private final Provider<AssetManager> assetsProvider;

  public TypefaceModule_ProvideRobotoLightFactory(Provider<AssetManager> assetsProvider) {
    this.assetsProvider = assetsProvider;
  }

  @Override
  public Typeface get() {
    return Preconditions.checkNotNull(
        TypefaceModule.provideRobotoLight(assetsProvider.get()),
        "Cannot return null from a non-@Nullable @Provides method");
  }

  public static TypefaceModule_ProvideRobotoLightFactory create(
      Provider<AssetManager> assetsProvider) {
    return new TypefaceModule_ProvideRobotoLightFactory(assetsProvider);
  }

  public static Typeface proxyProvideRobotoLight(AssetManager assets) {
    return Preconditions.checkNotNull(
        TypefaceModule.provideRobotoLight(assets),
        "Cannot return null from a non-@Nullable @Provides method");
  }
}

There are two functions which do almost the same thing: the instance method get(), and the static method proxyProvideRobotoLight().

Why has Dagger generated two versions of this code, which both call the module's provide() method statically? Can't one call the other?

(Incidentally, I do realise that I no longer need to bundle fonts in my app assets. That's not the question here.)

Answer 1

First off: Dagger generates this code ahead-of-time so that in a modularized build, you get better build performance. Because of that, we don't know which (or both, or neither) that you will need, so we generate both just in case, and assume that Proguard will be able to strip whatever is unused.

So what are both actually doing?

The first (the get() method) is invoked when the binding that this factory represents is requested as a Provider<T>. That can happen either directly, or if the binding is scoped, or a few other scenarios.

The second case is what we call inlining. Suppose you have a @Provides method in a module, and you have a method on your @Component that returns that type. The most ideal code to generate is something like:

@Override
public YourBinding y() {
  return YourModule.yourProvidesMethod();
}

The thing is, that provides method may not be accessible from the same package as your component, so we generate this "proxy" method which gives Dagger the right accessibility. It also makes accessible all of the parameters to that method, erasing them to Object if necessary. And if they do get erased (think of this like generic type erasure), we need to then insert the casts to the correct types inside the proxy method.

The Provider.get() implementation doesn't need that, because there, all of the types should are accessible by the code that invokes it.

So to sum up - we want to generate both versions, hopefully you should only use one, and Proguard should clean up the other.

Hope that helps!