Open carlosmuvi-stripe opened 2 years ago
I'm not aware of any libraries using Mavericks but that's certainly interesting 😄
WorkManager uses androidx.startup to do its initialization. You could follow a similar approach in which you initialize by default with that and allow it to be overridden in the consumers AndroidManifest.
That's a great idea, should be actually addressing both concerns at once. We'll try going with it (commit) Thanks Gabriel!
I'm leveraging using mavericks in a library with a strong UI component. There are a couple things to be considered, I was wondering if anyone has faced these in the past:
initialize
on application creation. Although there are ways for libraries of accessing the application lifecycle (like via aContentReceiver
), let's assume the library does not want to run any code on the application.For 1, by checking the
initialize
implementation, doesn't look like delaying initialization to a later point in time would be an issue as long as a) it's done before any mavericks View / ViewModel is created and b) initialization gets triggered across process kills right?However, for 2, the host app might have already initialized Mavericks. In the POC linked above, we're using a workaround to check if Mavericks has been already initialized to avoid overriding the host app's
viewModelConfigFactory
. But the host app can be customizing the factory configuration in different ways (i.e.: overriding the default coroutine contexts), making its usage within the library non-deterministic.Thanks in advance!