PHẦN 1 – PHẦN 2

Sau bốn mẫu designs khác nhau trong sáu tháng đầu của sự phát triển của các ứng dụng upday, chúng ta đã học được một bài học quan trọng đó là chúng ta cần một architecture pattern mà nó cho phép “react” nhanh chóng khi có những thay đổi trong design!

Và giải pháp cuối cùng mà chúng tôi chọn là Model-View-ViewModel. Hãy cùng khám phá MVVM là gì, cách chúng ta áp dụng nó tại upday và những gì đã làm nó trở nên “perfect” đến như vậy

Pattern Model-View-ViewModel

Những yếu tố chính trong pattern MVVM:

• View  – Mang chức năng thông báo cho ViewModel về những actions của người dùng.
• ViewModel  – Hiển thị streams của những data liên quan đến View
• DataModel  – abstracts những nguồn data. ViewModel kết hợp với DataModel sẽ có được data và save data.

Thoáng nhìn qua, MVVM dường như rất giống với mô hình Model-View-Presenter pattern, vì cả hai pattern này đã abstract rất tốt state và behavior của View. Presentation Model abstract một View độc lập với 1 nền tảng iao diện người dùng (UI) riêng biệt, trong khi đó pattern MVVM được tạo ra để đơn giản hóa việc lập trình event driven của giao diện người dùng (UI).

Nếu pattern MVP đồng nghĩa là Presenter yêu cầu trực tiếp là View phải hiển thị những gì, thì đối với MVVM, ViewModel cho ta thấy được nhiều dòng sự kiện (event streams) mà View có thể kết nối vào. Nói cách khác, giống như Presenter, ViewModel không cần phải giữ một tham chiếu đến View . Điều này cũng có nghĩa rằng hiện nay, tất cả các giao diện mà pattern MVP yêu cầu đang giảm.

View cũng mang chức năng thông báo cho ViewModel về các actions khác nhau. Vì vậy, pattern MVVM hỗ trợ two-way data binding giữa View và ViewModel và có một sự liện hệ theo kiểu “many-to-one” giữa View và ViewModel. View có một tham chiếu đến ViewModel nhưng ViewModel lại không fcó thông tin nào vê View. Khách hàng của dữ liệu cần được biết về producer này, nhưng producer – ViewModel – lại không biết, và không quan tâm ai là tiếp nhận data.

Model-View-ViewModel at upday

Nhìn sơ qua những bài post của Android trên blog upday, bạn sẽ ngay lập tức cho ta biết được rằng library yêu thích chính là: RxJava. Vì vậy, không có gì lạ, bởi vì RxJava là nền tảng dcủa code upday! Phần event driven được yêu cầu bởi MVVM sẽ được thực hiện bằngObservable của RxJava. Đây là cách chúng tôi áp dụng MVVM trong ứng dụng Android tại upday, với sự hỗ trợ của RxJava:

DataModel

DataModel thể hiện data dễ consume thông qua các event streams – đó là các Observablecủa RxJava. Nó thường bao hàm data từ nhiều nguồn khác nhau, như các layer network,database và các tham chiếu đã chia sẻ và hiển thị data dễ consum đến những ai đang cần. Những DataModel giữ toàn bộ business logic.

Chúng ta muốn nhấn mạnh về nguyên tắc single responsiblity tạo ra một DataModel cho mọi tính năng trong app. Ví dụ, chúng ta có một ArticleDataModel mà compose những output của nó từ API service và database layer. DataModel này xử lý business logic và đảm bảo rằng những thông tin mới nhất từ ​​các database được lấy ra bằng cách áp dụng age filter.

ViewModel

ViewModel là một model cho View của các app: một abstraction của View. ViewModel lấy các dữ liệu cần thiết từ DataModel, áp dụng logic UI và sau đó hiển thị data có liên quan với View. Tương tự như DataModel, ViewModel hiển thị data thông qua những Observable

Chúng ta đã học được 2 thứ về ViewModel, đó là:

• ViewModel nên hiển thị những state cho View, chứ không phải chỉ là những event. Ví dụ, nếu chúng ta cần để hiển thị tên và địa chỉ email của một User, chứ không phải là tạo ra hai stream, thì chúng ta tạo ra một đối tượng DisplayableUser mà chỉ gói gọn trong hai mảng là tên và địa chỉ mail. Stream sẽ luôn luôn hiển thị tên hoặc những thay đổi trong email. Bằngcách này, chúng ta sẽ đảm bảo được rằng View sẽ luôn luôn hiển thị trạng thái
  hiện tại của User.
• Chúng ta cần phải bảo đảm rằng mọi action của người dùng phải thông qua ViewModel và bất kỳ logic nào có thể xảy ra của View phải được di chuyển trong ViewModel.

Tham khảo thêm tại các lỗi thông dụng trong MVVM + RxJava.

View

View là giao diện người dùng thực tế trong các app. Nó có thể là một Activity, một Fragment hoặc bất kỳ Android View tùy chỉnh. Đối với Activities và Fragment, chúng ta đang binding và unbinding từ những nguồn event trênonResume() và onPause().

Nếu MVVM View là một Android View tùy chỉnh, thì binding được thực hiện trong constructor. Để đảm bảo rằng các subscription vẫn chưa được lưu lại, dẫn đến tình trạng rò rỉ bộ nhớ, unbinding xảy ra trong onDetachedFromWindow.

Testability Of The Model-View-ViewModel Classes

Một trong những lý do quan trọng khiến chúng ta yêu thích pattern Model-View-ViewModel là vì nó rất dễ test.

DataModel

Việc sử dụng phép nghịch đảo của control pattern, được ứng dụng rất nhiều trong mã code, và sự thiếu hụt của bất kỳ class Android  tạo thuận lợi cho việc thực hiện các unit test của DataModel.

ViewModel

Views và các unit test như là hai loại consumers của dữ liệu khác nhau so với ViewModel. ViewModel được tách biệt hoàn toàn với UI hay bất kỳ những classes Android, do đó unit test rất dễ dàng.

Hãy xem xét ví dụ sau đây, nơi ViewModel chỉ hiển thị một số dữ liệu từ DataModel:

Tests dành cho ViewModel rất dễ thực hiện. Với sự hỗ trợ của Mockito, chúng ta đang sao chép DataModel và chúng ta kiểm soát các dữ liệu trả về cho những methods đã được sử dụng. Sau đó, đảm bảo rằng khi chúng ta subscribe các Observable được trả về bởi getSomeData(), data sẽ ​​được phát ra.

Nếu ViewModel cần truy cập vào các class Android class, chúng ta tạo ra những wrapper gọi là các Provider. Ví dụ, đối với các resources của Android, chúng ta tạo ra một IResourceProvider mà nó hiển thị những methods như String getString(@StringRes final int id). Việc thực hiện IResourceProvider sẽ chứa một tham chiếu đến Context, nhưng ViewModel sẽ chỉ đề cập đến 1 IResourceProvider được thêm vào.

Như đã đề cập ở trên, thì chúng ta đang tạo ra những model object để giữ trạng thái data, cho phép mức độ testabilitycao hơn và việc quản lý dữ liệu được hiển thị bởi ViewModel.

View

Ví dụ logic trong UI là tối thiểu, rất dễ test Views với Espresso. Chúng ta cũng đang sử dụng những library như DaggerMock và MockWebServer để cải thiện sự ổn định của những lần tests UI

MVVM có phải là 1 giải pháp đúng đắn?

Chúng ta đã sử dụng MVVM cùng với RxJava trong gần một năm nay. Kể từ khi View chỉ là một consumer của các ViewModel, rất dễ thay thế các yếu tố UI khác nhau với những thay đổi nhỏ trong những class khác.

Chúng ta cũng đã nhận ra tầm quan trọng khi phân chia các vấn đề, và chúng ta nên chia nhỏ các code nhiều hơn, tạo ra những View nhỏ và ViewModels nhỏ mà chỉ có những trách nhiệm cụ thể. ViewModels được thêm vào Views. Điều này có nghĩa rằng chúng ta thường chỉ thêm Views trong XML UI, mà không thực hiện bất kỳ thay đổi nào khác. Vì vậy, khi những yêu cầu của UI thay đổi một lần nữa, thì chúng ta có thể dễ dàng thay thế một số Views với những Views mới.

Kết luận

MVVM kết hợp những ưu điểm của việc phân chia các vấn đề mà MVP mang lại, đồng thời tận dụng những lợi thế của những data binding. Kết quả là một pattern – nơi mà model thực hiện càng nhiều operation càng tốt – sẽ giảm thiểu logic trong View.

Sau khi design thay đổi trong “giai đoạn trứng nước” của app upday, chúng ta sẽ chuyển sang MVVM trong “giai đoạn trưởng thành” của upday – một giai đoạn mà từ những sai lầm, chúng ta học được rất nhiều. Và giở đây, chúng ta có thể tự hào về một app mà nó đã chứng minh được khả năng “chống chịu” trước lần redesign. khác Và cuối cùng chúng ta đã sắp được gọi upday là một app “trưởng thành”.

Nguồn: Medium.com

Có thể bạn chưa biết:

TUYỂN THỰC TẬP REACT NATIVE

* Trang bị kỹ năng về JS, lập trình hybrid app, sử dụng những công cụ hỗ trợ (VScode, github, sourcetree, ...)
* Thành quả mong muốn là các bạn tham gia sẽ có được kỹ năng lập trình hybrid app

Biểu mẫu đăng ký training tại đây >> http://bit.ly/2NK9YWd

TEAM MOBILE APPS - CTY DVMS