Home
DI library based on working with weak/soft/strong jvm references.
Start on the java way or on the Kotlin way.
I think those who develop applications for jvm at some point face one problem - lack of memory. For many, a similar picture of memory consumption is becoming familiar:
It seems that the application consumes a lot of memory, I want to release it as soon as possible, reset all references. All screen caches are cleared when the user exits the screen or any other action. When the user re-enters the screen, we reload all the features to it, and fill it with new caches and data.
This behavior causes garbage collection to occur all the time, the memory consumption graph becomes sawtooth. When reopening the screen, we spend a lot of resources to update and normalize the data for the screen.
The idea of the library is that all the main objects of the program can be reused, and they do not affect the memory leak in any way, since the jvm can safely delete all these objects if they are not held by anyone. The application saves resources on loading and normalizing data, since objects that are not included in the GC are still available and can be further used when the screen is reopened.
For example, in the timeline, the feature presenter application can either be recreated or restored from the DI cache each time it is opened.
It cannot be destroyed at the time of use in a Feature Screen, as it is held by it (a class variable).
After closing the Feature Screen screen, the GC will already be destroyed.
In this case, you can trace the sequence of deleting application objects:
First, the Feature Presenter is destroyed, then only the Feature Interactor is deleted (because the Feature Presenter is holding it), and only then can the Feature Repository be deleted.
The philosophy of the library is that it does not hold any objects by itself. However, if the object is not destroyed in the GC, then it can be reused. From this comes the peculiarity of using scopes of objects and their life cycle. Objects in Stone are held only by the consumers of these same objects. If the consumer stops using the object, the object can be destroyed.
In another situation, the consumer may transfer the object to another consumer for use. In Stone, there is no need to create special scopes for managing such an object with a special life cycle. The object can be destroyed by the GC as soon as all consumers release it.
The library provides work with blurry object application scopes for each object separately, without obliging the developer to describe all these scopes. This behavior allows equally efficient implementation of various life cycles of the View layer and the model layer. For Android, now there is no need to describe how DI works for different View: compose/fragment/activity.
The user buys a subscription, can install any dynamically loaded code, or log in and the application will switch from demo mode to the main one. These events force a part of the application's functionality to be hot-swapped for a new one.
The Stone library allows you to flexibly replace one DI object with another. Moreover, everything can be done while saving the cache. Additionally, the systematic removal of various objects from use and gradual replacement with new ones can be configured. And all this at runtime.
Hot swapping also allows you to change application binding objects to fit a new context. There is no need to recreate the DI component each time if one of the binding objects has changed.
The library has a powerful API for generating objects with dependencies and qualifiers. Qualifiers allow you to create and cache each unique object according to the key. DI should be a single factory providing the creation of all the main application objects.
For Android in particular, you can get rid of providers and ViewModel generators. All ViewModels can be created and cached directly via DI using a unique tagging for each screen. Moreover, the library itself will determine which parameters are qualifiers, and which dependencies
Any object in the application, when created, can have an initialization load.
Everyone can subscribe to something, download something, initialize variables, or even go to a file to do it.
Access delegates are widely used in Kotlin, in particular the lazy delegate, which allows you to delay the initialization of the application of a variable until it is applied.
Delaying initialization until it is applied in stone allows you not to warm up features immediately, but to use them as needed.
Applications are now free from the problem of a long launch of the application and the opening of the screen. All objects are used only as needed, do not consume resources. The application becomes more responsive and faster.