Advice for my current MVVM android app architecture

I have experience using Java for back-end web applications and I'm trying to make some sense out of the way MVVM architecture has to be laid but I can't stop thinking about Java Services, ServicesImpl, Controllers, etc...

This is the structure of my android app ui so far:

Main activity ---> Fragment -> SubFragment
               |-> Fragment2 -> SubFragment2
               |-> etc...

Simple enough, right?

But that's it. I'm not using services nor ViewModels (so I guess it's not a MVVM structure then lol).

All the logic is written in Main Activity for global stuff, and each fragment has its own logic as well. And its starting to get messy and I've been avoiding making this question a lot too lol.

So I have 4 questions:

Q1) Is it OK that the logic is being written in the fragment class? I.e. MyFragment loads an RV with firestore documents. In my java back-end applications I'm always using services and stuff and the code remains a lot cleaner but in Android, as I said above, it's starting to get messy because in MyFragment I need the Adapter, the ViewHolder and multiple queries and methods because I've implemented some filters. And because these filters are another RV separately I need another Adapter, another ViewHolder, and well... you see my point. For an earlier version of my App I separated the fragment from the adapter creating a "MyFragmentAdapter.kt" file. Would you consider doing this a good solution? Or all of this should go into a ViewModel?

Q2) So far I have no use for a ViewModel because if I need to persist data, I put that data in my Main Activity and that's it. Main activity never dies so the fragments data never dies as well. Would you consider this a good practice?

Q3) Looking at open source android applications I found no structure containing a services folder, which for me is practically a given. Why is that?

Q4) The folders in my project are laid out like this:

.project.login -> some activities with barely any logic
        .models -> just pojos
        .utils -> some utils.kt
        .ui -> recipes (folder) -> bunch of fragments with lots of logic
            -> news (folder) -> more fragments with lots of logic

Would you add something to this structure?

I will try to answer as simple as possible. If it works for you (your example), then it is ok. Simple as that. There is no wright/wrong answer, best arch, pattern etc in this world to make android app. Even bigger IT companies follow their own design patterns and some devs loves it, some don't. Anyway, back to your part questions:

1. Consider Fragment and Activity just to be responsible for UI logic. That is loading views, changing view properties(button color, visibility etc), showing data on those views etc(getting from VM).
   MyFragmentAdapter-> yes, make separate adapter class with ViewHolder. I even make single class responsibility, that is separate ViewHolder class.
   Or all of this should go into a ViewModel?-> No, ViewModel holds no references to views! It just holds data and communicates with ui!

2. Would you consider this a good practice? If you are looking into VM, then this is not a good idea. As I said above, Fragment(and Activity) is only responsible for UI logic. In VM, start your query, REST Api call etc and send that data to UI.

Main activity never dies so the fragments data never dies as well.-> TRUE, but the main MAGIC of VM is, it "survives" configuration changes. When activity recreates, VM is "the same" and holds all data needed to show on UI.

3. Services holds no UI, no need for ViewModels.

4. Ok, but I would consider every feature module with its own logic. Example: recipes-> ui-> fragment, adapter,viewmodel, di(dependency), data(api,repository), domain(usecases)

I would not consider what you're doing good practice.

Whether you follow MVVM, MVP, MVC, or something else, the idea is to decouple your application into at least 2 different layers: UI and Logic.

What this means in a nutshell in Android is to not do any logic in your activities or fragments.

In MVVM, all logic should go in ViewModels. None should go in activities or fragments. Activities and fragments should be updated purely by observing LiveData fields in the ViewModel. LiveData isn't strictly necessary but some observer pattern should be used. The goal is for your views to be as dumb as possible. To have data-driven UI. And your logic should be ignorant of the platform, it shouldn't even know that this is Android.

Some benefits are:

1. Ability to unit test everything (Many developers don't understand the importance of this)
2. Decoupled, can change the UI without changing the logic and vice versa
3. Portability, could take that same logic code and put it on another platform or in another application
4. Cleaner code, less spaghetti, smaller files, follow SOLID principles, easier to read, debug, refactor, modify, etc.