Upload
saul-diaz-gonzalez
View
170
Download
2
Tags:
Embed Size (px)
Citation preview
@Module(
includes = RosieModule.class,
addsTo = {AndroidModule.class,
DrinkModule.class,
CodingModule.class
}
injects = FlipperFragment.class,
complete = true,
)
public class FlipperModule {
@Provides
@Named(“Tuenti”)
public FlipperInterface provideFlipper(Gintonic drink,
Trolling trolling, Android android) {
return new FlipperImpl(drink, trolling,
android);
}
}
public class FlipperFragment extends Fragment {
ObjectGraph graph;
@InjectFlipperInterface flipper;
@Overridepublic void onCreate(Bundle bundle) {
graph = ObjectGraph.create(new FlipperModule());graph.inject(this);FlipperInterface flipper2 = graph.get(Flipper.class);
}
IDSPISPOPD FOR SINGLETONS
@Singleton
● By definition, Singletons cannot be tested
● Provides same instance of class for Graph
● This instance is not static
Lazy<Flipper> lazyFlipper;
● Creates the instance on lazyFlipper.get()
● Returns always the same instance (d’oh)
● Always done in UIThread!
LAZY INITIALIZATIONS
PROVIDING INSTANCES
Provider<Flipper> flipperProvider;
● Can help building your own Flipper army
● Returns a different instance each time
@Module(
override = true;
injects = FlipperFragment.class,
complete = true,
)
public class FlipperTestModule {
@Provides
@Singleton
public FlipperInterface provideFlipper() {
return mock(FlipperInterface.class);
}
}
MOCKING INSTANCES
DYNAMIC (SCOPED) INJECTION
public ObjectGraph extend() {
return graph.plus(new ExtensionModule1(),
new ExtensionModule2());
}
STATIC INJECTION
● Reduce boilerplate and mantenibility by
annotating classes and constructions
● Compilation-validated graph
SCOPED INJECTION
● Using a SOLID approach, change
implementations on runtime
● Graph runtime, validated
● Risk of “BOOOOOOM”
CLASSIC EXAMPLE@Module(injects = LoginActivity.class,
addsTo = AppModule.class)// @author Antonio Leiva public class LoginModule {
private LoginView view;
public LoginModule(LoginView view) {this.view = view;
}
@Provides @Singleton public LoginView provideView() {return view;
}
@Provides @Singletonpublic LoginPresenter providePresenter(LoginView loginView,
LoginInteractor loginInteractor) {return new LoginPresenterImpl(loginView, loginInteractor);
}}
WHY STOPPING THERE?public class NoNfcModule() {
@Provides
public NfcInterfaceController provideNfcController() {
return new NullNfcController();
}
}
public class NfcModule() {
@Provides
public NfcInterfaceController provideNfcController(
NfcAdapter adapter) {
return new NfcController(adapter);
}
}
// This goes on Api15Module
@Provides
@Singleton
public StatusBarControllerInterface provideStatusBarControllerInterface() {
return new StatusBarAPI15Controller();
}
// This goes on Api19Module
@Provides
@Singleton
public StatusBarControllerInterface provideStatusBarControllerInterface() {
return new StatusBarAPI19Controller();
}
// This goes on Api21Module
@Provides
@Singleton
public StatusBarControllerInterface provideStatusBarControllerInterface() {
return new StatusBarAPI21Controller();
}
ONE MORE CUP OF ABUSEpublic class ActiveProfileModule() {
@Provides
public ProfilePresenterInterface provideProfilePres(...) {
return new
ActiveProfilePresenter(basePresenter,...);
}
}
public class RegularProfileModule() {
@Provides
public ProfilePresenterInterface provideProfilePres(...) {
return new
RegularProfilePresenter(basePresenter,...);
}
}