-
Notifications
You must be signed in to change notification settings - Fork 1
java_init
The library supports DI component initialization: installing dependencies and module instances.
The main feature of the initialization process is that the library supports hot-swapping of its main components.
There are no builders in the library, all initialization methods are defined by creating initialization methods in the component.
All initialization methods are annotated with the @Init annotation.
@Component
public interface AppComponent {
FeatureModule feature();
@Init
void initFeatureModule(FeatureModule featureModule);
}Now you can execute the initialization method not only at the time of DI creation. But also when updating the application context, for example loading dynamic features.
// init stage
FeatureModule module = new FeatureModule();
AppComponent DI = Stone.createComponent(AppComponent.class);
DI.initFeatureModule(module);
// some work
// dynamic feature loaded
DynamicFeatureModule moduleNewFeatures = new DynamicFeatureModule();
DI.initFeatureModule(moduleNewFeatures);The DI component will also store already provided objects according to caching rules and scopes.
And after their destruction and re-creation, it will generate new ones, described in the moduleNewFeatures module.
For the application it will look like this:
- The user walks through the screens. Each screen is a holder of objects (provided from DI)
- The user sees a warning on one of the screens to install a new dynamic feature. Installs it, DI is initialized with the new module.
- After installation, the user also sees the old functionality on the screen, since the screen is still an object holder. And DI did not clear them from the cache.
- The user exits the screen. For DI, the GC is called, all released objects are cleaned.
- The user comes to the screen and sees the new functionality.
Please note that strong links will not be stripped from the DI, if they also need to be updated after a new initialization, change the cache type for them using @SwitchCache
In addition to initializing modules, the library allows you to configure dependencies for each component. This approach allows you to develop feature modules for an application independently of each other, while specifying for each feature only those dependencies that are necessary. Dependencies differ from modules only in that there is no caching for them. Dependencies are provided through another component that already has caching.
@Dependencies
public interface StarsDependencies {
Sun sun();
}You can also use the entry above as a module. Its methods are specified as a factory cache type.
@Module
public interface StarsDependencies {
@Provide(cache = Provide.CacheType.Factory)
Sun sun();
}Imagine that you are developing a pro and free version of an application. Where pro implements all the functionality of a free application, but also provides a paid one. In some cases, it is also possible to replace some free objects with pro ones. Developing such an application through the feature approach seems inconvenient.
The library allows you to completely expand the functionality of one component with another.
To do this, you need to create a child DI component and explicitly extend one with the other using the @ExtendOf annotation.
@Component
public interface AppProComponent extends AppComponent {
@Override
ProFeatureModule feature();
@ExtendOf
void extendComponent(AppComponent parent);
}Now using the method we described, we can create 2 different components and link them together.
AppComponent DI = Stone.createComponent(AppComponent.class);
AppProComponent DIPro = Stone.createComponent(AppProComponent.class);
DIPro.extendComponent(DI);The free subroutine completely uses the simple implementation of DI. DIPro is available for the pro subroutine.
After executing DIPro.extendComponent(DI), everything provided in DI will be provided from DIPro (subject to cache clearing).
In the free subprogram, objects are replaced with their pro implementation. The pro subroutine makes full use of pro objects.