3

I wonder what scopes folowing two bindings have:

bind(PermissionManager.class).in(Singleton.class);

and 

bind(PermissionManager.class);

I have read the JavaDocs, they are as following. For Singleton:

/**
* Apply this to implementation classes when you want only one instance
* (per {@link Injector}) to be reused for all injections for that binding.
*
* @author crazybob@google.com (Bob Lee)
*/

For no scope:

/**
* No scope; the same as not applying any scope at all.  Each time the
* Injector obtains an instance of an object with "no scope", it injects this
* instance then immediately forgets it.  When the next request for the same
* binding arrives it will need to obtain the instance over again.
*
* <p>This exists only in case a class has been annotated with a scope
* annotation such as {@link Singleton @Singleton}, and you need to override
* this to "no scope" in your binding.
*
* @since 2.0
*/

What does this mean in practical terms? Are singletons per client or per JVM? For no scope, is every instance different?

Dmitry Chornyi
  • 1,821
  • 4
  • 25
  • 33

2 Answers2

3

In practical terms for Gin, the Singleton scope makes the most sense when considered per client instance, or even more accurately, per Ginjector instance. If you make the mistake of making two Ginjectors by GWT.createing an instance twice, you likely will have one 'singleton' per instance, since each Ginjector can only keep track of the instances it manages.

So each time your application loads, it will have its own singleton. If the user opens the same application twice in two different tabs, each will have its own singleton. You could consider each tab to be its own JVM, as it will have its own copy of all of the classes, and won't be able communicate, or call methods* on the other window.

For no scope, yes, by default each instance is different. When a type is @Injected, it will be a new instance there, but if you @Inject a Provider for a field, every time you call get() you can get a fresh instance. This can be helpful to get several newly injected instances easily.

Singletons make sense to use in two main cases

  • When the instance holds shared state that needs to be common across many injections - the most common case.
  • When the instance is expensive to create - on the server this is often done as a pool, so no more than X objects are created, but the expensive objects on the client tend to be views, with lots of widgets, and generally more than one is not required.

* It is possible to call methods on another window, but you need to use the browser's capabilities for this, by posting a message, not by just passing an object back and forth.

Colin Alworth
  • 17,801
  • 2
  • 26
  • 39
  • Thanks for the explanation. So in my case, I have a `PermissionManager` which will hold permissions per user. They should be common for all injections which are related to a user session (I don't care that much about multiple browser tabs). From what I understood, `@Singleton` is what I need, right? – Dmitry Chornyi Feb 26 '12 at 23:05
  • If it itself holds state (as opposed to reading from some other instance), then probably. You may find it to be convenient to use the `Provider` interface to let this be null before an instance is ready, and bind that provider as a singleton, but allow anything reading perms to ask that provider for a `PermissionManager`. (And if this were on the server, you might use @SessionScoped instead, and Guice would figure out how to keep it session specific.) There is more than one way to do this correctly, depending on your exact situation, and when you have data, how long it is valid for. – Colin Alworth Feb 27 '12 at 02:23
  • Oh, it is on the server, can't believe I forgot to mention this. Looks like `@SessionScoped` is what I need. – Dmitry Chornyi Feb 27 '12 at 17:32
  • You probably should change the question title/tags to point to Guice instead of Gin then, as Gin is on the client only. – Colin Alworth Feb 28 '12 at 14:30
2

Singletons are only created once by the top level Ginjector that you create (and for most applications, you only ever create one Ginjector).

Unscoped objects are created every time they are injected as a dependency into another object. So every instance will be different. You actually don't need to write bind(SomeClass.class) if you are not going to scope it (or do any of the other things that the binder DSL can let you do to a binding). Simply having the default constructor or adding @Inject to a constructor will let Gin be able to create it.

Generally, when you are using Guice or Gin you want to leave things unscoped unless you have a good reason not to. I would recommend reading over the Guice documentation about scopes.

ben_w
  • 736
  • 1
  • 6
  • 10