You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe that it would be possible to hide the RetentionManager from the public API and treat it as an implementation detail, so users would only need to supply a retention period and internally the ChuckCollector manages an instance of it.
I am assuming that you would always want to use the same context for both the collector and the retention manager. Can you imagine any circumstance where this wouldn't be the case and the exposed constructor would be useful?
Do you feel this would be a good way to evolve the API?
Do you want to develop this feature yourself?
Yes, I'd be happy to.
The text was updated successfully, but these errors were encountered:
This shoulds like a good idea to me :)
Please note that we also recently migrated all the retention mechanism to Room, so it should be easier to integrate with your proposal. Would be happy/free to code this feature?
* Hid the RetentionManager in the api in favor of passing a retentionPeriod instead.
* Fixed indentation based on library:ktlintMainSourceSetCheck report
I believe that it would be possible to hide the
RetentionManager
from the public API and treat it as an implementation detail, so users would only need to supply a retention period and internally theChuckCollector
manages an instance of it.becoming
I am assuming that you would always want to use the same
context
for both the collector and the retention manager. Can you imagine any circumstance where this wouldn't be the case and the exposed constructor would be useful?Do you feel this would be a good way to evolve the API?
Do you want to develop this feature yourself?
Yes, I'd be happy to.
The text was updated successfully, but these errors were encountered: