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'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:
Mavericks recommends calling initialize on application creation. Although there are ways for libraries of accessing the application lifecycle (like via a ContentReceiver), let's assume the library does not want to run any code on the application.
The host app using the library might be already using Mavericks.
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!
The text was updated successfully, but these errors were encountered:
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.
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!
The text was updated successfully, but these errors were encountered: