manas-chaudhari / android-mvvm Goto Github PK

Usecase:
Two Way binding is required
Value of the field needs to be updated from an observable.

As of now, two way binding has been implemented using vanilla ObservableField. Hence, it has no functionality to bind to an Observable. Hence, the only way is to subscribe to the observable externally. However, that requires knowledge about lifecycle.
Idea is to provide a bindingadapter: bind:lifecycle_to: @{vm}, between View and any instance of Connectable interface.

The adapter will add an AttachStateListener and invoke connect when the view is subscribed and unsubscribe when view is detached.

ViewModels can then implement connect method and do the subscriptions there.

Not Functional any more 😭

Of course, it would be ideal to find a way around this. Allowing subscriptions in ViewModels would make the pattern weak, as it won't enforce functionalness constraint.

As twowaybinding behaviour is analogous to BehaviourSubject, it can be used to allow creating ObservableFields from observables while still allowing two way binding. Need to think about all edge cases here. If this works, this would be the way to go.

Looking for other usecases

Although subject could solve the top usecase, there could be other usecases, where subscribing cannot be moved to binding layer.

Hello,
are you planning to add RxJava2 support? If yes, any ETA yet?

Because MVVM & RxJava Databinding integration are two streams, which can be used separately, it is possible to split these into two separate libraries.

1. android-mvvm
   • The generic Adapters & binding adapters
   • Perhaps RxJava's dependency could be removed from this part by replacing rx.Observable<List<ViewModel>> with databinding.ObservableList<>
   • Split library into modules based on support libraries, so that there is no overhead of including an indirect dependency.
2. databinding-rxjava
   • Conversion between rx.Observable and databinding.ObservableField
   • Additionally, bindingConversions can be provided to convert from Observable<List<>> to ObservableList<>
     • This would be essential for Adapters in MVVM to work with Rx
3. databinding-rxjava2
   • Same as above but with RxJava2 support
4. databinding-rxjava-kotlin
   • Extension functions for easy conversions
5. databinding-rxjava2-kotlin
   • Same as above, but with RxJava2 support

Google announced architecture components such as ViewModel, LiveData, ViewDataProvider, which are similar to components in our library.

As of now, there is no concrete objective about what can be achieved. But, this issue is to explore what's possible and discuss ideas.

ObservableField when converted to Observable, emits the current value on subscription.
Since RxJava2 doesn't support null values, this causes NPE.

• MvvmActivity onCreate -> protected
• toField inside FieldUtils. This is convenient for static import

Because Observable<List<ItemViewModel> cannot be cast to Observable<List<ViewModel>, bind:items does not accept the former one. Adding a BindingConversion resolves this issue.

Hi @manas-chaudhari,
I'm researching your project to implement MVVM to my project.
I saw you init data for RecyclerViewAdapter in ItemListViewModel at the same time activity create
So how I can automatically update RecyclerViewAdapter when I have a new data, example: I load data from server
Please help me. Thanks!

As defaultBinder is available in the library, moving BaseActivity (as MvvmActivity) will make setting up activities straight forward.

Similarly, MvvmFragment can also be provided.

Currently, BindingAdapters for setting up RecyclerView from items and view_provider are in sample. Although binding to recyclerView is quite straight forward, adapters with manual lifecycle requires additional setup, which could be easy to miss.

Proposal: Add a static setup method for configuring default binding. This will have to be invoked in application's setup
MVVM.setDefaultBinder(view, vm -> view.setVariable(BR.vm, vm))

Then these binding adapters can be added to the library

• items, view_provider, binder
• items, view_provider (Use default binder)
• BindingConversion: layout_res to ViewProvider

Thus, clients will only need to configure the defaultBinder and they should be ready to start using databinding attributes.

@BindingConversion public static View.OnClickListener toOnClickListener(final Action0 listener) { if (listener != null) { return new View.OnClickListener() { @Override public void onClick(View view) { listener.call(); } }; } else { return null; } }

and

@BindingConversion public static View.OnClickListener subjectToListener(final PublishSubject<Void> subject) { if (subject != null) { return view -> subject.onNext(null); } else { return null; } }

you showed 2 different ways. what;s the main difference?

• Navigation to a different page on selection
• Action inside a ViewModel, e.g. Show toast when a button is clicked

in getting started, initializing the library in the applicaiton object following statement is used:
viewDataBinding.setVariable(BR.vm, viewModel);

What is BR in the above statement; I am new to Java. I am unable to fix BR when I try to do it in a new project. Any help will be appreciated...

Hi, your MVVM design is very inspiring.

I made a small sample app which utilizes your modules and Kotlin.

Here is the link https://github.com/mishkaowner/MVVMSample

The only issue I came across is that you are missing a unit test example for your sample application.

I already checked all the test files

ex) https://github.com/manas-chaudhari/android-mvvm/blob/master/android-mvvm/src/test/java/com/manaschaudhari/android_mvvm/FieldUtilsTest.java

But I have not found a clear example of a unit test for ViewModel.

val vm = MainViewModel()
vm.edit.set("Hello")
vm.result.toObservable().test().assertValue("You typed Hello")

this is the best test code I made so far...

Please, lead me to the right direction.

Thank you

Example: Selected state for items in RecyclerView. When any item is selected, others should get deselected.

MvvmActivity allows for easy setup of activities.
A similar MvvmFragment can be added to allow easy setup of fragments.

How about using a reactive list for populating the RecyclerViews and ViewPagers? Such as if you wanted to add or remove items from a list without redisplaying the entire list. Something like this.

Again, awesome library.

Adding MainThread logic in ViewModel requires dependency on Android, which causes unit tests to fail.

It seems that when a View is recycled in a RecyclerView, the view model of that view is set to null (in onViewRecycled of RecyclerViewAdapter.java). Subsequently the pending bindings are executed resulting in a crash.

Use composition instead of inheritance for MvvmActivity

Currently, if the source observable errors, the error gets caught in ReadOnlyField and is printed. Because of these silent failures, bugs could get missed during testing.
A better way could be to provide a callback during setup of library. A stricter approach would be to let the app crash. This would create the requirement for using only error-free observables in bindings.

Add a kotlin artifact android-mvvm-kotlin with convenient extension functions for converting between Fields and Observables

Currently using the latest configuration.
compileSdkVersion 24
buildToolsVersion "24.0.2"
and with gradle com.android.tools.build:gradle:2.2.0

public final Action0 onClickRx = new Action0() {
@OverRide
public void call() {
System.out.println("Hello world");
}
};

this just simply prints

Error:Execution failed for task ':app:compileDebugJavaWithJavac'.
java.lang.RuntimeException: Found data binding errors.
***/ data binding error ***msg:Cannot find the setter for attribute 'android:onClick' with parameter type rx.functions.Action0 on android.widget.Button.
file:D:\Users\jh\AndroidStudioProjects\MVVMTEst\app\src\main\res\layout\activity_main.xml
loc:25:31 - 25:47
***\ data binding error ***

Create MVVMUtils class

ItemVM:

• title
• image (optional)
• quantity in cart
• add, subtract handlers

There is a common pattern between ViewPagerAdapter and RecyclerViewAdapter, which will likely be present in other adapters to come.
This functionality can be extracted in a separate class MVVMAdapter perhaps.
All adapter methods would simply call methods of MVVMAdapter.
For users of library, it would then be possible to bind MVVMAdapter to all views (for basic functionality)