Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Migrate from RoboGuice 4 to Toothpick

Migrate from RoboGuice 4 to Toothpick

Internal workshop at groupon

stephanenicolas

July 27, 2016
Tweet

More Decks by stephanenicolas

Other Decks in Programming

Transcript

  1. Toothpick is a scope tree based Dependency Injection (DI) library

    for Java. It is a full-featured, runtime based, 
 but reflection free, implementation of JSR 330. Toothpick is faster than Dagger 1 or Dagger 2
 for a relatively small number of injections (<1K) 2
  2. Presentation plan 1. TP  scopes   2. Injec/ng  all  dependencies

     into  an  object   3. Ge9ng  an  instance/lazy/provider  of  a  class   4. Named  injec/ons     5. Lazies     6. ContextSingleton  and  why  you  should  not  use  it     7. Tes/ng  &  Mock Migrate to TP
  3. TP scopes In  Toothpick,  scopes  are:     • a

     place  to  define  bindings  (via  modules)   • a  place  to  recycle  injected  instances   Scopes  are  used  to:     • inject  dependencies  into  instances   • getInstance  of  classes Migrate to TP
  4. TP scope tree It’s a common practice to define a

    scope by context. In advanced uses cases, more scopes can be created. Scopes form a tree. Migrate to TP
  5. Before: RG.getInjector TP scopes are similar to injector in RG.


    In MGA, this is managed by the foundations classes. Migrate to TP
  6. openScope(s) methods need “the name” of the scope as a

    parameter. 
 If multiple scopes are open together, they form a hierarchy 
 and the leaf is returned. Opening and closing scopes in TP Migrate to TP
  7. Installing modules in TP Modules are very similar in RG

    and TP. 
 The main difference is that TP doesn’t need a configure method, you can declare bindings directly in the constructor of the modules. Migrate to TP
  8. Getting instance of classes: RG 4 This was equivalent to

    declare a field 
 @Inject ImageCacheWarmup imageCacheWarmup. RG would return a new instance or recycle a previous instance in the scope of the injector, depending on annotations of ImageCacheWarmup. Migrate to TP
  9. Getting instance of classes: TP Still equivalent to declare a

    field 
 @Inject ImageCacheWarmup imageCacheWarmup. TP will also return a new instance or recycle a previous instance in the scope of the injector, depending on annotations of ImageCacheWarmup. Migrate to TP
  10. Getting lazies/providers of classes: TP TP API also allows to

    easily get a provider or a lazy on a dependency. This is also equivalent to declaring a lazy / provider field. Migrate to TP
  11. Named injections Migrate to TP Named injections are simpler with

    TP. You don’t need to use Named. Before with RG After with TP
  12. Lazies: RG Migrate to TP You had to declared AND

    initialize Lazies with RG. 
 But it was pure boiler plate code.
  13. Lazies: TP Migrate to TP !!! TP makes Lazies simpler,

    just declare Lazies. Don’t forget to @Inject them !!!
  14. Avoid ContextSingleton Migrate to TP ContextSingleton is just NOT clear.

    
 You can create a singleton at the app level or at the activity level, depending on where the injection first happens. This easily creates leaks !
  15. Use Singleton or ActivitySingleton Migrate to TP Try your best

    to either use a real app singleton (and only use the application there) 
 OR an ActivitySingleton (and use the activity as a context)
  16. Testing and mocking: RG Migrate to TP You can inject

    test dependencies or mock the dependencies needed under test…
  17. Testing and mocking: TP Migrate to TP Nothing changed (for

    now). But you don’t need to reset the mocks anymore (weird cases are solved).
  18. Conclusion Migrate to TP TP  is  just:  beVer,  easier,  faster

     than  RG.     Dig into the TP wiki to get more insight on TP. TP   has   more   to   offer   than   RG:   scopes   spanning   mul/ple   ac/vi/es,   state   preserva/on  across  rota/ons,  etc.  We  will  slowly  use  these  features  in  the  app   over  next  releases…