Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mavericks in a library. #630

Open
carlosmuvi-stripe opened this issue May 13, 2022 · 2 comments
Open

Mavericks in a library. #630

carlosmuvi-stripe opened this issue May 13, 2022 · 2 comments

Comments

@carlosmuvi-stripe
Copy link

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:

  1. 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.
  2. 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!

@gpeal
Copy link
Collaborator

gpeal commented May 15, 2022

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.

https://developer.android.com/topic/libraries/architecture/workmanager/advanced/custom-configuration#remove-default

@carlosmuvi
Copy link

carlosmuvi commented May 16, 2022

That's a great idea, should be actually addressing both concerns at once. We'll try going with it (commit) Thanks Gabriel!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants