Htykuut

I understand that ViewModel in the Architecture component is for storage and managing data so it will not be lost during config changes.

For example, my activity has nothing do with LiveData or using storage Data. Should I still go through ViewModel? or directly instantiate the Repo Class and call the insertion method? I hope that make sense

An Example of my usage of ViewModel

public class MainViewModel extends AndroidViewModel {

    private DataRepo dataRepo;

    private LiveData<List<Group>> groupList;

    private LiveData<List<Bill>> billList;



    public MainViewModel(Application application) {

        super(application);

        dataRepo = new DataRepo(this.getApplication));

        groupList = dataRepo.getGroup();

        billList = dataRepo.getBill();

    }



    public LiveData<List<Group>> getGroupList() {

        return groupList:

    }



    public LiveData<List<Bill>> getBillList() {

        return billList:

    }



    public void insertGroupAndMember(Group group) {

        dataRepo.insertGroupAndMember(group);

    }



    public void insertBills(List<Bill> bills) {

        dataRepo.insertBills(bills);

    }



    public List<Member> getMemberList(Group group) {

        return dataRepo.getMembers(group);

    }

}

I think you want to use a ViewModel to keep your UI controller as clean as possible. Your viewmodel should call the repo to do simple CRUD operations.
See below snippet from documentation:

Requiring UI controllers
to also be responsible for loading data from a database or network
adds bloat to the class. Assigning excessive responsibility to UI
controllers can result in a single class that tries to handle all of
an app's work by itself, instead of delegating work to other classes.
Assigning excessive responsibility to the UI controllers in this way
also makes testing a lot harder.

Here are some points I would advice you to consider:

• MVVM as a pattern has it's roots back in 2000-th, for example, here is Martin Fowler's article about the concept, and in 2005 John Gossman announced the pattern in his blog. Yes, it solves the problem with rotation in android's implementation of the pattern, but this problem could be solved without it. MVVM is actualy needen for separation of presentation state from views that are seen to the end user. As Wiki says -

The view model is an abstraction of the view exposing public properties and commands. Instead of the controller of the MVC pattern, or the presenter of the MVP pattern, MVVM has a binder, which automates communication between the view and its bound properties in the view model. The view model has been described as a state of the data in the model.

So, primarily it is (like all other GUI architectural patterns in their root) about abstraction between view and domain parts of the application, so that they can vary independently and subsequent changes to the system will be cheap.

• Instantiating domain objects in the view scope and their subsequent use by the view leads to tight coupling between the view and domain objects, which is a bad characteristic of any system. Also, it is one more reason to change view's internals, because if construction logic of the domain object changes - view will have to be changed too.

If ViewModel is exessive for you (as I can see, its benefits are not relevant for you in this particular case, because the UI is not very complex and it's state is lightweight), consider using a less heavy-weight abstraction, such as MVP. Thus, you will be able to preserve abstraction between view and model in your application (no unwanted coupling) and you won't have to support the code that you don't benefit from.