I have a simple process which needs to complete during initiation of the app (splash fragment/view model) but also needs to be run from another fragment (settings fragment/view model). It:
I am struggling to understand where to put all this logic. My inclination is to do it in the view model as opposed to the fragment, so the fragment makes one call and all the work is done. Likely I will have to incorporate a listener into the view model so the fragment knows when everything is done, or if there is an error. Does this seem like the right place to put it?
If I do that, I have a different view model for the settings fragment. I don't want to recreate the logic for the splash view model. So how do I share this logic between the view models? Do I push it into the repository?
I'm using Java not Kotlin if that matters.
First of all you are definitely correct to not put it in a fragment, in modern Android development the Android lifecycle classes should always be kept as lean as possible.
Generally speaking, regardless of the architecture you are using, the viewmodel is still part of the view/presentation layer and shouldn't implement too much business logic if it can be avoided. Whereas a repository should have the single responsibility of storing, retrieving and updating a single model, but from multiple sources if necessary.
So in answer to your question, it depends. If all your steps 1-4 are referring to a single operation (which could be with multiple sources) concerning the same model then I would say that all of this logic should stay in the repository.
However if your steps include domain logic which concerns interacting with multiple models then I would recommend referring this work to your domain layer, maybe in the form of a use case or something similar. If this seems overkill for your application, then although it isn't best practice, letting a shared viewmodel (scoped to a parent fragment or activity) implement this logic would be acceptable.