MVVM – Android’s Architecture Components Part 2 – Repository Pattern

In the Part 1 of Android Architectural Component series, we have implemented two-way data binding and explained the Android Architectural components: ViewModel and Live Data, and LifeCycleOwner. However, the data layer part of the app was not complete, more specifically we did not implement the Repository Pattern. The previous example did not have a persistence solution to cache data from API. This might be required in many use cases for following reasons:

  1. User experience: making the user wait for some data is bad user experience, when possible, it needs to be avoided
  2. Data needs to be persisted: user needs to login once
  3. Waste of network resource: re-fetch same data
  4. Data lost: Flaky network can prevent you from obtaining data anytime
  5. Android OS/GC can clear data which is store in memory anytime.

In this blog post, we will go through the detail of our open source example of the MVVM android app implementing the Architectural Components guideline. Since this guideline was released only year, I did not find many open source project which is complete. Our example follows the Android App Guideline as strictly as possible and the source code is easy to understand:

Persistence data using Room DAO & LiveData

The Android Architecture Components provides a library to persist data: Room DAO. In a previous blog post, we have discussed about how to setup the Room Persistence Library: https://devanshramen.com/2017/09/20/intro-to-room-persistence-library/. Feel free to go back to this if you haven’t used Room before.

@Dao
public interface UserDao {
    
    @Query("SELECT * FROM user LIMIT 1")
    LiveData<User> getUser();

    @Insert
    (onConflict = OnConflictStrategy.REPLACE)
    void insert(User user);

    @Delete
    void delete(User user);

    @Query("DELETE FROM user")
    void deleteAll();
}

 

  • Returning LiveData

@Query(“SELECT * FROM user LIMIT 1”)
LiveData<User> getUser();

LiveData as mentioned in Part 1 of Android Architectural Component will notify any of its observers when its value changes. For instance, in our login example, the user entity will be updated when the Login API operation is successful (user will be inserted into user entity).

 

Fetching Data from Webservice

In the blog post, we were calling Login API operation inside of our ViewModel. We marked this part TODO and rightly so. Other than not providing a Persistence solution, the ViewModel is responsible for holding Data for the Activity and Fragment. Fetching data inside the ViewModel would violate the Single Responsibility Principal. This would make our app more difficult to maintain as it is scaled when new features are added. We will have a new class “UserRepository” to manage all operations which are at the “data layer”. (Note that we are using a mock api and does not include any authentication or use of token for this example in which we won’t go through this part)

 

UserRepository

The Repository class (modules if we use dagger2), will manage data which is being cached local repository or which needs to be sent to a remote repository (through web service). The UserRepository is using Room (userDao) and Retrofit for remote data.

public class UserRepository {
    UserDao userDao;
    Executor executor;

    public UserRepository() {
        this.userDao = AppDatabase.getAppDatabase(MApplication.context).userDao();
        executor = Executors.newSingleThreadExecutor();
    }

    public void clearUserCached() {
        executor.execute(() -> {
            userDao.deleteAll();
        });
    }

    public void loginUser(String email, String password) {

        getAPIService().login(new LoginRequest(email, password))
            .compose(RxUtils.applySchedulers())
            .subscribe(
                (LoginResponse response) -> {
                    executor.execute(() -> {
                        userDao.insert(response.getUser());
                    });
                },
                (Throwable e) -> {
                    e.printStackTrace();
                }
            );
    }

    public LiveData<User> getUser() {
        return userDao.getUser();  
    }
}

  • loginUser(String email, String password): 

We have now exposed a method for network call to perform the login operation inside of the UserRepository. The key point here is that when the operation is successfully we will update the RoomDao:

executor.execute(() -> {
    userDao.insert(response.getUser());
});

(note that the i/o operation for Room needs to be done in background thread – thereby use of executor)

 

  • LiveData<User> getUser(): 

Our LoginViewModel will setup its UserResponse LiveData attribute with this method such that the LiveData for User Entity in Room DAO will be used to detect if user data was updated.

 

  • Optimise code with Dependency Injection:

Note that we can optimise this class for scalability by using Dependency Injection to provide for UserDAO with a single implementation and thereby avoid some code duplication.

 

Updated LoginViewModel

public class LoginViewModel extends ViewModel {

    // Create a LiveData
    private LiveData<User> userResponse;

    public final ObservableField<String> email = new ObservableField<>();
    public final ObservableField<String> password = new ObservableField<>();

    public final ObservableField<String> errorEmail = new ObservableField<>();
    public final ObservableField<String> errorPassword = new ObservableField<>();

    UserRepository userRepository;

    public LoginViewModel() {
        userRepository = new UserRepository();
        userResponse = userRepository.getUser();
    }

    public LiveData<User> getUser() {
        return userResponse;
    }
    
    public void onBtnLoginClick() {
        if (validateInputs()) {
            userRepository.loginUser(email.get(), password.get());
        }
    }
   .
   .
   .
}

We were previously using an observable on LoginResponse. This has been updated to use LiveData and the UserRepository which has the implementation for calling login API and which can talk to UserDao. Note that the updated ViewModel will not have any implementation for fetching cached data or data from a Web service.

  • Subscribe to UserDao from UserRepository

The method getUser() from UserRepository returns the LiveData<User> from UserDao:

public LoginViewModel() {
    userRepository = new UserRepository();
    userResponse = userRepository.getUser();  
}

 

The LoginViewModel exposes the LiveData to the LoginActivity so that the Activity can take UI actions should the data in UserDao be updated:

public LiveData<User> getUser() {
    return userResponse;
}

 

  • Calling Login method from UserRespository: 
public void onBtnLoginClick() {
    if (validateInputs()) {
        userRepository.loginUser(email.get(), password.get());
    }
}

 

LoginActivity – User Observer

The Login will remain same as before but now we will get user object instead of LoginResponse. It will also be notified in theory of changes from UserDAO instead of actual Login API.

// The observer updates the UI when UserDAO is updated
mViewModel.getUser().observe(this, userResponse -> {
    if (userResponse != null) {
        Toast.makeText(LoginActivity.this, "Login success", Toast.LENGTH_SHORT).show();

        Intent intent = new Intent(this, MainActivity.class);
        startActivity(intent);
        finish();

    } else {
        Log.d("LoginActivity", "value user is null");
        // Show ERROR
    }
});

 

MainActivity

For the sake of the example, we have added a MainActivity class which will display the user’s details. The data will be retrieved directly from Room UserDAO without requiring to make another API call to fetch data. It also shows that the data was successfully cached.

  • Display cached User Details: 
// The observer updates the UI to display prefetched user details
mViewModel.getUser().observe(this, userResponse -> {

    if (userResponse != null) {
        binding.txtWelcome.setText("Welcome " + userResponse.getFirstName() + " " + userResponse.getLastName()
                + "\n\n" + "You are more than a " + userResponse.getJobTitle());

    } else {
        logoutUser();
    }
});

 

MainViewModel

The MainViewModel will also make use of the same method (userRepository.getUser()) from UserRepository to get cached user:

public class MainViewModel extends ViewModel {
    private UserRepository userRepository;

    public MainViewModel() {
        userRepository = new UserRepository();
    }

    public LiveData<User> getUser() {
        return userRepository.getUser();
    }

    public void clearUserData() {
        userRepository.clearUserCached();
    }
}

Conclusion:

That’s it, we have now implemented the Repository Pattern and completed the Part 2 of our MVVM using new Android Architectural components. Please find the full project source below:

https://github.com/devansh-ramen/Android-App-Architecture-MVVM

Do not forget hit the “Star” button on the project repository:

If you have any queries, feel free to post a comment in the Comment section below, I will respond to you as soon as possible.

 

Please Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s