Selama even Google I/O berlangsung, kami diperkenalkan dengan architecture components yang meliputi LiveData dan ViewModel untuk memfasilitasi pengembangan aplikasi Android dengan paradigma MVVM pattern.
Definisi MVVM
Jika Anda sudah familiar dengan MVVM, silakan skip saja bagian ini, agar waktu Anda tidak terbuang sia-sia.
MVVM adalah singkatan dari Model View ViewModel, yaitu salah satu desain arsitektur pattern atau paradigma baru untuk mengelola konsentrasi pengembangan aplikasi Android, sehingga memungkinkan developer memisahkan antara User Interface dengan Business Logic (back-end). MVVM adalah evolusi dari arsitektur legendaris MVC pattern, berpegang teguh pada prinsip yang sama yaitu;
Keeping UI code simple and free of app logic in order to make it easier to manage (Menjaga kode UI tetap sederhana dan bebas dari logika aplikasi untuk membuatnya lebih mudah dikelola)
MVVM memiliki lapisan utama berikut ini.
1. Model
Model mewakili data dan logika bisnis aplikasi. Salah satu strategi implementasi yang direkomendasikan dari lapisan ini, adalah mengekspos datanya melalui observable untuk dipisahkan sepenuhnya dari ViewModel atau Observer lainnya.
2. ViewModel
ViewModel berinteraksi dengan Model dan juga menyiapkan observable yang dapat diamati oleh View. Secara opsional, ViewModel dapat menyediakan kail / pengikat bagi View untuk meneruskan peristiwa ke Model. Salah satu strategi penting implementasi lapisan ini adalah untuk memisahkannya dari View, yaitu ViewModel tidak boleh mengetahui tentang tampilan yang berinteraksi dengannya.
3. View
Terakhir, peran tampilan dalam pola ini adalah untuk mengamati atau berlangganan observasi ViewModel, guna mendapatkan data yang dibutuhkan elemen UI.
Diagram berikut menunjukkan komponen MVVM dan interaksi dasar.
Seperti yang disebutkan di atas, LiveData adalah salah satu komponen arsitektur yang baru diperkenalkan. LiveData bertanggung jawab membawa data yang diamati. Hal ini memungkinkan komponen aplikasi mengamati perubahan data objek LiveData tanpa membuat jalur dependensi yang eksplisit dan kaku di antara mereka. Ini sepenuhnya memisahkan produsen objek LiveData dari konsumen objek LiveData.
Selain itu, ada juga manfaat besar dari LiveData, yaitu menghormati siklus utama aplikasi Anda (Activity, Fragment, Service) dan menangani manajemen object lifecycle dan memastikan bahwa objek LiveData tidak bocor (leak).
Dokumentasi google menyebutkan bahwa jika Anda sudah menggunakan library seperti Rx atau Agera, maka Anda bisa melanjutkannya sebagai pengganti LiveData. Tapi pada kasus ini, Anda bertanggung jawab mengelola object allocation & de-allocation di setiap components lifecycle.
Karena LiveData menghormati Android Lifecycle, berarti LiveData tidak akan memanggil callback observer kecuali host LiveData (Activity atau Fragment) dalam keadaan aktif (onStart()). Selain itu, LiveData juga akan secara otomatis menghapus observer saat host-nya sedang onDestroy().
ViewModel
ViewModel juga bisa dibilang salah satu komponen arsitektur yang baru diperkenalkan, yang bertanggung jawab menyiapkan data untuk UI/View.
ViewModel menyediakan kelas khusus pada lapisan MVVM, karena ViewModel (dan kelas turunannya AndroidViewModel) diperluas secara otomatis memiliki kemampuan mempertahankan data selama perubahan konfigurasi, contohnya seperti pada saat terjadi rotasi layar.
Diagram berikut menunjukkan siklus hidup komponen ViewModel
Sekarang, mari kita ke bagian yang paling menarik, mari kita susun puzzle di atas ke dalam contoh aplikasi. Layar pertama yang ditunjukkan di bawah ini menampilkan daftar proyek Google GitHub dengan beberapa informasi singkat seperti judul, bahasa pemrograman, dll.
Dan ketika item-item itu diklik maka akan menampilkan detail semacam ini.
Berikut menunjukkan struktur project dari contoh Aplikasi ini.
Sementara itu, diagram interaksi ini menunjukkan skenario aplikasi mengambil project Google GitHub.
Modul repository bertanggung jawab menangani operasi data. Selain itu, juga menyediakan API yang bersih dan jelas, entah itu RestFul untuk akses external resouce, atau room untuk akses internal resource.
Sekarang, mari kita jelaskan lapisan ini dari bawah ke atas, dimulai dengan Model, ViewModel, dan terakhir View untuk mengambil skenario proyek GitHub.
Sample App Model Layer
Mari kita mulai dengan lapisan logika bisnis, kita memiliki dua objek model.
- Proyek, berisi informasi proyek GitHub seperti id, nama, deskripsi, tanggal pembuatan,… dll.
- Pengguna, berisi informasi pengguna dari pemilik proyek GitHub.
Untuk berinteraksi dengan GitHub RESTful API, saya menggunakan library tercinta yaitu Retrofit 2, berikut bagaimana saya mendefinisikannya ke dalam kode.
interface GitHubService {
String HTTPS_API_GITHUB_URL = "https://api.github.com/";
@GET("users/{user}/repos")
Call<List<Project>> getProjectList(@Path("user") String user);
@GET("/repos/{user}/{reponame}")
Call<Project> getProjectDetails(@Path("user") String user, @Path("reponame") String projectName);
}
Untuk memfasilitasi Pekerjaan ViewModel, kelas ProjectRepository dibuat untuk berinteraksi dengan service GitHub dan akhirnya menyediakan objek LiveData untuk ViewModel. Ini juga akan digunakan nanti untuk mengatur panggilan service. Cuplikan kode berikut menunjukkan implementasi API getProjectList().
public class ProjectRepository {
private GitHubService gitHubService;
//…
public LiveData<List<Project>> getProjectList(String userId) {
final MutableLiveData<List<Project>> data = new MutableLiveData<>();
gitHubService.getProjectList(userId).enqueue(new Callback<List<Project>>() {
@Override
public void onResponse(Call<List<Project>> call, Response<List<Project>> response) {
data.setValue(response.body());
}
// Error handling will be explained in the next article …
});
return data;
}
// …
}
ProjectRepository adalah penyedia data untuk ViewModel, yang mana getProjectList() bertugas menggabungkan respons ke dalam Objek LiveData.
Untuk mempermudah dalam memahami artikel ini, maka kode error handling kami hilangkan, dan rencana akan kami ulas dalam artikel terpisah.
Sample App ViewModel Layer
Karena proses konsumsi API Repositori dilakukan secara background task, maka inilah alasan kenapa getProjectList() perlu dibuat di ViewModel, dia memanggil LiveData, tujuannya agar kita bisa mengkonsumsi data hasil transformasi backround task ke main thread (UI). Cuplikan kode berikut menunjukkan kelas ProjectListViewModel.
public class ProjectListViewModel extends AndroidViewModel {
private final LiveData<List<Project>> projectListObservable;
public ProjectListViewModel(Application application) {
super(application);
// If any transformation is needed, this can be simply done by Transformations class ...
projectListObservable = ProjectRepository.getInstance().getProjectList("Google");
}
/**
* Expose the LiveData Projects query so the UI can observe it.
*/
public LiveData<List<Project>> getProjectListObservable() {
return projectListObservable;
}
}
Dalam kasus dunia nyata, transformasi mungkin diperlukan sebelum meneruskan data ke View Observer. Anda dapat menggunakan kelas Transformasi seperti yang ditunjukkan dalam dokumentasi INI.
Karena Activity dan Fragment dianggap sebagai pemilik siklus hidup, maka dalam kasus nyata, Anda dapat menginisialisasi observer dengan this (jika itu dilakukan di Activity), dan viewLifeCycleOwner jika itu dilakukan di Fragment.
public class ProjectListFragment extends LifecycleFragment {
private ProjectAdapter projectAdapter;
//…
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
final ProjectListViewModel viewModel =
ViewModelProviders.of(this).get(ProjectListViewModel.class);
observeViewModel(viewModel);
}
private void observeViewModel(ProjectListViewModel viewModel) {
// Update the list when the data changes
viewModel.getProjectListObservable().observe(this, new Observer<List<Project>>() {
@Override
public void onChanged(@Nullable List<Project> projects) {
if (projects != null) {
//…
projectAdapter.setProjectList(projects);
}
}
});
}
//…
}
Ini adalah penjelasan dari salah satu skenario proyek end-to-end, Anda dapat menemukan proyek lengkapnya di SINI.
