Is there a significant performance gain to binding classes? For example, should I bind the following dependency (as opposed to just letting it get discovered at runtime), for performance purposes?

@ContextSingleton
public class MaterialDialogBuilderFactory {
  private final Activity activity;

  @Inject
  public MaterialDialogBuilderFactory(Activity activity) {
    this.activity = activity;
  }

  public MaterialDialog.Builder get() {
    return new MaterialDialog.Builder(activity);
  }
}

javax-inject/javax-inject#31

Just add a param to smoothie application module by overloading the constructor, then pass the param to the provider.

If we don't do that, it's not possible later on to change the name of the @Inject SharedPrefs instance.

This is HIGH priority for MGA, it blocks QA's automated tests.

When doing a Gradle sync the following error is produced. It doesn't seem to prevent building and compilation though.

Error:The modules 'toothpick', 'toothpick-parent' point to same directory in the file system.
Each module has to have a unique path.

The wiki page for factory and member injector setup incorrectly passes a FactoryRegistry to MemberInjectorRegistryLocator.setRootRegistry

This commit violated checkstyle. It should fall under the ConstantName checkstlye module, but since it is not final it expects the first character to be lowercase (Name 'INJECTION_TARGETS_PER_GETTER_METHOD' must match pattern '^[a-z][a-zA-Z0-9]*$'.)

Broken line in commit

TP crashes on @singleton annotated methods (when migrating from Dagger 2 for instance).

The methods should not crash and the annotation processor should simply return an error.

Using the bind method is a good way of saying this class implements this interface for this scope.

My suggestion though is to allow developers to use an annotation on the concrete class instead of the bind method if they like, e.g.:

@Implements(scope="scope_name")
public class SomeClass {}

Advantages is that it is easier to find, as bind can be anywhere in the code, but with the annotation you know exactly where to find it.

Disadvantage is that it is very static (compile time), might be hard to read if it implements for multiple different scopes

Registries are not always required anymore:

Caused by: toothpick.registries.NoFactoryFoundException: No factory could be found for class com.groupon.merchant.auth.cloud.CloudAccount. Check that registries are properly setup with annotation processor arguments, or use annotations correctly in this class.

regarding wiki https://github.com/stephanenicolas/toothpick/wiki/Modules-&-Bindings#binding-overrides-in-children-scopes

- Scope S0 : IFoo.class --> Foo.class
+ Scope S0 : IFoo.class --> Foo1.class
  \
   \
  Scope S1 : IFoo.class --> Foo2.class
    \  
     \
    Scope S2

OR

- Toothpick.inject(a, s0); // => a.foo is an instance of Foo1
+ Toothpick.inject(a, s0); // => a.foo is an instance of Foo
Toothpick.inject(a, s1); // => a.foo is an instance of Foo2
Toothpick.inject(a, s2); // => a.foo is an instance of Foo2

which is correct ? or current one is true ?

I have a class MainActivity (which is an Activity). It has injected members, but it itself is never injected anywhere, yet in the generated code there is a Factory implementation for it:

public final class MainActivity$$Factory implements Factory<MainActivity> {
  private MemberInjector<MainActivity> memberInjector = new com.staticbloc.location.mock.activity.MainActivity$$MemberInjector();

  @Override
  public MainActivity createInstance(Scope scope) {
    scope = getTargetScope(scope);
    MainActivity mainActivity = new MainActivity();
    memberInjector.inject(mainActivity, scope);
    return mainActivity;
  }

  @Override
  public Scope getTargetScope(Scope scope) {
    return scope;
  }

  @Override
  public boolean hasScopeAnnotation() {
    return false;
  }

  @Override
  public boolean hasScopeInstancesAnnotation() {
    return false;
  }
}

This also happens when using a FactoryRegistry:

public final class FactoryRegistry extends AbstractFactoryRegistry {
  public FactoryRegistry() {
    addChildRegistry(new toothpick.smoothie.FactoryRegistry());
  }

  public <T> Factory<T> getFactory(Class<T> clazz) {
    switch(clazz.getName().replace('$','.')) {
      case ("com.staticbloc.location.mock.activity.MainActivity"):
      return (Factory<T>) new com.staticbloc.location.mock.activity.MainActivity$$Factory();
      default:
      return getFactoryInChildrenRegistries(clazz);
    }
  }
}

or it doesn't make sense to me.

https://github.com/stephanenicolas/toothpick/wiki/Factories-and-Member-Injectors

For

public class Foo {
  @Inject void m(Bar bar) {...}
}

Shouldn't the code be:

//a Member Injector
public final class Foo$$MemberInjector implements  MemberInjector<Foo> {
  @Override
  public void inject(Foo foo, Scope s) {
    Bar bar = s.getInstance(Bar.class);
    foo.m(bar);
  }
}

Your variable names and examples still suck. <3

First line of https://github.com/stephanenicolas/toothpick/wiki/Factory-and-Member-Injector-registries should link to https://github.com/stephanenicolas/toothpick/wiki/Factories-and-Member-Injectors

Following the same naming convention as the other subprojects:

• toothpick-compiler
• toothpick-runtime
• ...

Also consider removing the prefix "Smoothie" form Android specific Modules.

The example showing how to setup registries when the app depends on libraries that use Toothpick could probably be improved by presenting the setup for an app that uses smoothie.

Unused local variable inside Factories that can make CI findbug hooks complain:

public AndroidAccountIntents createInstance(Scope scope) {
     scope = getTargetScope(scope);
     AndroidAccountIntents androidAccountIntents = new AndroidAccountIntents();
     return androidAccountIntents;
}

Only happens when scope is not used. Can we avoid that?

We don't allow to bind implementations which contain "scope annotations".

For instance, the following is forbidden:

interface A {
    ...
}

@Singleton
class B implements A {
    ...
}

class XModule extends Module {
    public ModuleWithNamedBindings() {
        bind(A.class).to(B.class);
    }
}

However, it seems a valid use case...

Should we allow it?

However, not all cases are valid (that's why it is not allowed right now)...

I would like to have a dependency (for example, a configured instance of OkHttpClient) declared in a module added to an application-wide scope. I would then like to have other modules that are added to more narrow scopes use that dependency to instantiate other dependencies (for example, a Retrofit api implementation configured to use the OkHttpClient). Can I inject dependencies into modules? Or do I need to create some kind of wrapper or factory class that gets the parent dependency injected?

When migration our german app @grpn, the TP runtime dependency is added via:

    compile 'com.github.stephanenicolas.toothpick:toothpick-runtime:1.0.0-RC2'

and it didn't seem to add the TP dependency to the app, we had to add:

    compile 'com.github.stephanenicolas.toothpick:toothpick:1.0.0-RC2'

which should not be needed.

But this is strange as TP runtime pom file: http://search.maven.org/#artifactdetails%7Ccom.github.stephanenicolas.toothpick%7Ctoothpick-runtime%7C1.0.0-RC2%7Cjar

states

<dependency>
      <groupId>com.github.stephanenicolas.toothpick</groupId>
      <artifactId>toothpick-generated-core</artifactId>
      <version>1.0.0-RC2</version>
      <scope>compile</scope>
    </dependency>

and TP generated code pom: http://search.maven.org/#artifactdetails%7Ccom.github.stephanenicolas.toothpick%7Ctoothpick-generated-core%7C1.0.0-RC2%7Cjar

states

<dependency>
      <groupId>com.github.stephanenicolas.toothpick</groupId>
      <artifactId>toothpick</artifactId>
      <version>1.0.0-RC2</version>
      <scope>compile</scope>
    </dependency>

so, why doesn't toothpick get added to the project ?

https://github.com/stephanenicolas/toothpick/wiki/Scopes#scopes-instances-creation-and-injections

Foo class? setQurtz()?

Plz use something more "real" and use it everywhere in the docs.

Due to gradle using alphabetical ordering of modules, smoothie gets compiled first.
There is no way to do it differently, we should move smoothie to its own repo, this will create serious issues sooner or later.

Codewise :

• increase test coverage to 99% + (currently 95%)
• add cycle detection at runtime
• add debug and prod mode ^
• create GH readme
• create useful wiki
• prepare article for announcement
• fix maven publishing
• release to central
• ask for external reviews

As graph roots don't need to be injected, they don't need a factory, thus an empty constructor is not needed (for android: activities, fragments, views, ...).

We display several compilation warnings that make it difficult to see real problems or warning:

.../../DealListItemView.java:32: warning: 
The class ....DealListItemView has injected fields but has no injected constructor, 
and no public default constructor. Toothpick can't create a factory for it.
public class DealListItemView extends RelativeLayout {

When migration our german app @grpn, @dpreussler found the following issue:

public packageX.A     contains @Inject members (has member injector)
       / \   (extends)
        |
public packageY.B      NOT contains @Inject member (no member injector)
       / \
        |
package packageY.C      contains @Inject members (has member injector)

The generated memberInjector class for packageX.A will call the member injector class of packageY.C. Therefore, It fails.

MemberInjector<C> superMemberInjector = new packageY.C$$MemberInjector();

I know the documentation says that this is not supported, but I'm wondering if there is any workaround to simulate this. I cannot find any DI solution for Android that supports injecting a generic type like this:

public class MyActivity<P extends BasePresenter> extends Activity {
    @Inject
    P presenter;
}

Thank you!

when using JDK 7 (tested with "1.7.0_51", "1.7.0_80")
the apk build does not contain classes, when starting:

java.lang.RuntimeException: Unable to instantiate application com.groupon.merchant.MerchantApplication: java.lang.ClassNotFoundException: Didn't find class "com.groupon.merchant.MerchantApplication" on path: DexPathList[[zip file "/data/app/com.groupon.redemption-1/base.apk"],nativeLibraryDirectories=[/data/app/com.groupon.redemption-1/lib/x86, /vendor/lib, /system/lib]]

In https://github.com/stephanenicolas/toothpick/wiki/Factories-and-Member-Injectors there is a nice example of the Factory TP creates:

//a simplified Factory
public final class Foo$$Factory implements Factory<Foo> {
  @Override
  public Foo createInstance() {
    return new Foo();
  }
}

but there is no example of what an optimistic Factory might look like. I wanted to see that while reading.

Should we crash? Or simple do nothing?
For example, common top class that always call it.

Right now:

throw new RuntimeException

Trying out toothpick and it looks really promising!

I stumbled on a issue in wiki in Setting up bindings in a scope:

Instead of bind(IFoo.class).to(new Foo());, it should be bind(IFoo.class).toInstance(new Foo());

Keep on doing the good work!

I have a class:

@ActivitySingleton
public class MapFragmentProvider implements Provider<SupportMapFragment> {
  @Override
  public SupportMapFragment get() {
    return SupportMapFragment.newInstance();
  }
}

Where ActivitySingleton is:

@Scope
@Documented
@Retention(RUNTIME)
public @interface ActivitySingleton {
}

But no Factory is being created for it unless I add an @Inject constructor.

Click on Configurations (https://github.com/stephanenicolas/toothpick/wiki/Configurations)

@stephanenicolas wtf

After the merge of
#121
(which has been included in RC6)

we will still have to retain at runtime the qualifier and the scope annotations:

• scope annotations are checked by the development configuration to ensure that a scoped class (annotated with a scope annotation) is not bound explicitely by a module (of a different scope). The workaround could be, in this configuration, to use the factory as it contains this information at compile time.
• qualifiers annotations are checked when used in toothpick.config.Binding#withName(java.lang.Class) . This could also be included inside a configuration. In this case, we don't generate any meta-information at compile time for qualifier classes and we cannot rely on compile time to do the check without it...

As a reminder: we want to get rid of runtime retentions as they fill in the first dex and every class using them as well...

In a class using a dependency that is generics such as:

public class DaoGoodsBrowseByCategory extends GrouponBaseDao<GoodsBrowseByCategory> {

    @Inject
    public DaoGoodsBrowseByCategory(ConnectionSource connectionSource, DatabaseTableConfig tableConfig) throws SQLException {
        super(connectionSource, tableConfig);
    }

where DatabaseTableConfig is

public class DatabaseTableConfig<T>

TP then generates the following Factory

public final class DaoGoodsBrowseByCategory$$Factory implements Factory<DaoGoodsBrowseByCategory> {
  @Override
  public DaoGoodsBrowseByCategory createInstance(Scope scope) {
    scope = getTargetScope(scope);
    ConnectionSource param1 = scope.getInstance(ConnectionSource.class);
    DatabaseTableConfig<T> param2 = scope.getInstance(DatabaseTableConfig.class);
    DaoGoodsBrowseByCategory daoGoodsBrowseByCategory = new DaoGoodsBrowseByCategory(param1, param2);
    return daoGoodsBrowseByCategory;
  }

We should just strip off the <T> of DatabaseTableConfig<T> param2 = scope.getInstance(DatabaseTableConfig.class);

We need to investigate this:

reflection free config accepts provider/implementation to be scoped, but reflection config does not.
the former would accept to scope via an annotation a provider/implementation and bind it, the second does not.

• Presenter annotation in RX MVP sample should be defined outside of Rx MVP Activity. It gives the feeling right now that the scope has to be defined and is linked in the activity.

There are some issues regarding the Methods Injects, overrides and inheritance:

class A {
    @Inject C c;

    @Inject
    public void init() {
        .
    }
}

class B extends A {
    @Inject D d;

    @Override
    public void init() {
        .
    }
}

1) Initialization should use the order: First inject @Inject annotated fields, then call @Inject annotated methods.

However, for the example if we inject B, the order is:

C (A field) -> init (B METHOD) -> D (B field)

Which is wrong. Inside its init method, B can assume all fields are injected, and this didn't happen yet.

2) If B was like this:

class B extends A {
    @Override
    public void init() {
        .
    }
}

The member injector would not be generated, but we need it. We could add @Injectto init, but @Override is not mandatory and if it is omitted, init would be called twice during initialization.

3) Let's imaging now a slightly different example:

class A {
    @Inject C c;

    public void init() {
        .
    }
}

class B extends A {
    @Inject D d;

    @Override
    @Inject
    public void init() {
        .
    }
}

Will init be called when injecting B using its member injector?

For Android applications ToothPick will be commonly used in Activities and Fragments in the following way:

SampleActivity.java

public class SampleActivity extends Activity {

   @Inject ContextNamer contextNamer;

   @Override
   protected void onCreate(Bundle savedInstanceState) {
      scope = Toothpick.openScopes(getApplication(), this);
      scope.installModules(new SmoothieActivityModule(this));
      super.onCreate(savedInstanceState);
      Toothpick.inject(this, scope);

      // ... do something
   }

   // ... more stuff

   @Override
   protected void onDestroy() {
      Toothpick.closeScope(this);
      super.onDestroy();
   }

   // ... more stuff
}

*SampleFragment.java

public class SampleFragment extends Fragment {

   @Inject ContextNamer contextNamer;

   @Override
   public void onCreate(Bundle savedInstanceState) {
      scope = Toothpick.openScopes(getActivity().getApplication(), getActivity(), this);
      scope.installModules(new SmoothieFragmentModule(this));
      super.onCreate(savedInstanceState);
      Toothpick.inject(this, scope);

      // ... do something
   }

   // ... more stuff

   @Override
   protected void onDestroy() {
      Toothpick.closeScope(this);
      super.onDestroy();
   }

   // ... more stuff
}

I have noticed that these two calls will be a constant in every project that uses TP:

// Activity
scope = Toothpick.openScopes(getApplication(), this);
// Fragment
scope = Toothpick.openScopes(getActivity().getApplication(), getActivity(), this);

Would it make sense to have a util ToothPick class for Android that masks this? For instance:

public class ToothpickAndroidUtils {

   public static Scope openActivityScope(Activity activity) {
      final Scope scope = Toothpick.openScopes(activity.getApplication(), activity);
      scope.installModules(new SmoothieActivityModule(activity));
      return scope;
   }

   public static Scope openActivityScope(Activity activity, Object... names) {
      final Scope scope = Toothpick.openScopes(activity.getApplication(), activity, names);
      scope.installModules(new SmoothieActivityModule(activity));
      return scope;
   }

   public static Scope openFragmentScope(Fragment fragment) {
      final Scope scope = Toothpick.openScopes(fragment.getActivity().getApplication(), fragment.getActivity(), fragment);
      scope.installModules(new SmoothieFragmentModule(fragment));
      return scope;
   }

   public static Scope openFragmentScope(Fragment fragment, Object... names) {
      final Scope scope = Toothpick.openScopes(fragment.getActivity().getApplication(), fragment.getActivity(), fragment, names);
      scope.installModules(new SmoothieFragmentModule(fragment));
      return scope;
   }
}

Some classes are generated in the last round, so they are not processed.

Example:

[ERROR] [system.err] warning: File for type 'toothpick.data.FooWithProvider$$MemberInjector' 
created in the last round will not be subject to annotation processing.

Is this a bug? I am just skimming through the code.

Lazies and Providers injected through constructors or methods are wrongly generated for Factories and Member Injectors. Wrong type parameter:

public class A {
    @Inject
    public A(@Lazy<B> b) {
        ...
    }

    @Inject
    public void init(@Provider<C> c) {
        ...
    }
}

Generates:

// Code generated for Lazy (Factory and Member Injector)
Lazy<T> param1 = scope.getLazy(B.class)

// Code generated for Provider (Factory and Member Injector)
Provider<T> param1 = scope.getProvider(C.class)

It should generate something like:

Lazy<B> param1 = scope.getLazy(B.class)
Provider<C> param1 = scope.getProvider(C.class)

At https://github.com/stephanenicolas/toothpick/wiki/Scopes#scopes-instances-creation-and-injections

a binding : is way to express that a class Foo is associated to an implementation Bar, which we denote Foo --> Bar. It means that writing @Inject Foo a; will return a Bar.

First time I read I was trying to associate with the Bar in the first example. After the second time I read it I noticed they have nothing to do. What about:

a binding : is way to express that a class Class is associated to an instance Instance, which we denote Class --> Instance. It means that writing @Inject Class a; will return an Instance.

or use an example with a real life scenario.

One of the main gains of TP is speed.
However, the reflection free configuration seems to be just an alternative.

Should we update the documentation to encourage its usage more?

When Lazies don't include the type parameter, we just get an internal exception (OutOfIndex...):

@Inject Lazy lazy;
@Inject Provider provider;

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
    at com.sun.tools.javac.util.List.get(List.java:476)
    at toothpick.compiler.common.ToothpickProcessor.getKindParameter(ToothpickProcessor.java:422)
    at toothpick.compiler.common.ToothpickProcessor.getInjectedType(ToothpickProcessor.java:277)
...

We should throw a proper error instead.

Use case:
We want to inject a Stub inside the ToothPickTestModule in a "nice way".
If we use @mock from the mocking library, the mock is created by it.

Possible solutions:

• Create annotation @Stub. Any field that contains that annotation will be bound but not injected by the mocking library.
• Create TP own @mock annotation, we wouldn't need to change more code. It could we be used when want the object to be bound inside the ToothPickTestModule but it won't be recognized by the mocking library.

Tp should not try to produce a factory for a class it doesn't compile. Otherwise multiple compilation units would create the same factories, which leads to a complex exclusion chain in all compilation units .

Is it just me, or do the com.example.smoothie.MemberInjectorRegistry and com.example.smoothie.FactoryRegistry classes in SimpleApp not exist?

Singleton is processed and we create relaxed factories in case it is annotating a class.

But it's not the case for custom scope annotations (like context singleton). I don't think we can actually do that without saying that the annotation processor should intercept every annotation, which is considered a bad practice. Maybe we can have a look at Dagger 2 and see how they deal with this as they also have custom scopes working well.

Interesting!
https://github.com/stephanenicolas/toothpick/wiki/Factories-and-Member-Injectors

Is it just a performance issue or things might be broken?
Is there a way to detect and log a warning?

rename everywhere, in code and doc. I think we will have to checkout the wiki locally and fix all typos, the source code will be easier to refactor.