Configurations

Configuration class

The class toothpick.Configuration allows to change Toothpick internal behaviors.

Although this wiki page will detail some possible configurations, we invite developers to browse the javadoc of this class to get more details. The documentation is available on maven central and your IDE should let you browse it during edition of java source files.

Runtime Checks

Toothpick includes two main configurations: development and production.

Development contains runtime checks to detect cycles and invalid bindings. These checks make Toothpick injections slower, however they are useful to find issues ahead of time. Thus, this configuration is recommended during development (Android - Debug builds).

Toothpick.setConfiguration(Configuration.forDevelopment())

Production does not have runtime checks and is recommended for production environments. This is the default configuration.

Toothpick.setConfiguration(Configuration.forProduction())

Reflection

Only applies to TP 1.X. TP 2 use reflection only.

Toothpick is completely reflection free. But not by default.

By default Toothpick will use a very limited amount of reflection to:

• load factories
• load member injectors

These settings allow to get started faster. Though, we encourage to go reflection free for a substantial performance increase. Toothpick provides a disableReflection configuration based on registries to load both factories and injectors. In this more advanced configuration, Toothpick works without using any reflection code at all.

Toothpick.setConfiguration(Configuration.forProduction().disableReflection())
// or
Toothpick.setConfiguration(Configuration.forDevelopment().disableReflection())

To enable this configuration, developers will also have to setup their registries locations correctly for each compile unit as detailed in Registries.

Multiple root detection (version 1.0.1+)

In versions 1.0.1 + of TP, configuration.preventMultipleRootScopes allows to restrict the TP scopes to be arranged into a tree and prevent the creation of a forest (i.e: multiple root scopes are not allowed). This method can be called on any configuration. Any infringement to this rule will crash the application with a clear error message.

Toothpick.setConfiguration(Configuration.forDevelopment().preventMultipleRootScopes())

This can, for instance, be useful on Android as a common issue is that asynchronous tasks can open a scope in a background thread while this scope has been recently killed (on the UI thread, during onDestroy as suggested by the TP best practices and in the samples).

The problem with this scope opening is that the openScope statement will not return the previous scope, as it has been already destroyed, but create a new scope that, in turn, will never get destroyed. And as we recommend to use the activity as a key for opening scopes, it means that this key, the actual instance of the activity, is going to be kept in the TP internal map key--> scope. Thus, it will leak the activity that is used a key and actually the whole newly created scope.

The solution to this issue can actually be split into 2 parts: detection and fix.

• Fixing the issue is mostly about detecting that an activity has been destroyed prior to using it as a key to open a scope.
• Detecting this kind of problems can be hard as a leak detector will simply report the activity being leaked but doesn't explain when this happens. To assist developers with this issue, we provide this configuration option that allows to detect the creation of scopes that are not linked to the application scope and thus create secondary root scopes.