I was thinking about doing a sample with MVVM but with RxJava not with databinding.
What do you all think?
Why no databinding? Normally MVVM and databinding are "connected".
indeed, MVVM is initially designed to be used with XAML and declarative databinding technology is essential to it. Infact this is the only way to connect the View and ViewModel.
The MVVM pattern lends itself naturally to XAML application platforms such as Silverlight. This is because the MVVM pattern leverages some of the specific capabilities of Silverlight, such as data binding, commands, and behaviors.
more info on MVVM here
If you want to use RxJava without any databinding it is fine but you should not call it MVVM but some variant of MVC/MVP
I'd love to see how you solve the ViewModel challenge using RxJava. How about creating the sample and linking it in the issue so it can be reviewed?
Should have put a link. I meant without the Data Binding library.
I have a small sample of a project with MVVM here.
The ViewModel exposes streams of data to which the View can bind to.
Sure, I'll create the sample and link it here.
Sounds Great! I Just looking for the sample with MVVM.
@florina-muntenescu nice example using RxJava, but again I would not call this MVVM.
@djodjoni I believe @florina-muntenescu is correct and that it is a good example of MVVM. Could you perhaps elaborate on what you believe is the right way to do MVVM instead?
In my understanding from MVVM above other things I expect:
1) most of the GUI logic removed from the code
2) declarative data/command-binding
in @florina-muntenescu example
mSubscription = new CompositeSubscription();
mSubscription.add(mViewModel.getGreeting()
.subscribeOn(Schedulers.computation())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(this::setGreeting));
mSubscription.add(mViewModel.getSupportedLanguages()
.subscribeOn(Schedulers.computation())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(this::setLanguages));
this clearly violates those believes of mine and generates boilerplate code, which would otherwise be handled by the Binder.
This however could be an attempt to create a RxDataBinder.
@djodjoni I didn't want to use another library just for a simple example.
There is already a RxBinder library
@florina-muntenescu RxBinding is a lovely lib but I believe its purpose is not to do DataBinding for MVVM
@djodjoni how about you create a new sample based on your comments and we can all compare with to @florina-muntenescu's one? The main purpose of this repo is for everyone to learn, pointing out something you don't like from somebody else's repo is not very constructive. 馃憤
@malmstein I didn't mean to be de-constructive :) on the contrary, challenging @florina-muntenescu's MVVM approach by expressing my point of view could improve her and my understanding on the subject. I also do not mean to compete to create MVVM example without databinding, however I am super curious how this can be achieved.
Anyway Florina's architectural approach is definitely going towards 'separation of concerns' design no matter how we call it and could be a nice addition to this repo.
Why don't we contribute and help @florina-muntenescu to be much clearer and easier maybe more richer ?
@florina-muntenescu, we can add it to the list of external samples for now.
Does it make sense to have a vanilla MVVM sample?
@JoseAlcerreca ok, sure. Yes, I do think it would be good to have a vanilla MVVM sample.
@JoseAlcerreca @florina-muntenescu is anybody working on the 'vanilla MVVM sample' ?
@djodjoni yes, I am.
cool! im really interested in this and would love to contribute if you share the repo where you work on it.
@djodjoni - the repo is here: https://github.com/florina-muntenescu/android-architecture
I had a long flight, so lots of time to code. Therefore there are already 3 PRs and I'm working on the 4th and last part, so there isn't so much left. But feel free to review the PRs.
@florina-muntenescu thx for the info. i see youre doing the Rx one. I am more interested in the pure MVVM with actual databinding. If you haven't started on that I will take it. ok for ya? :)
@djodjoni do you mean "actual databinding" or "actual Data Binding (library)"?
@JoseAlcerreca yep
Discussion here seems to have died out, but I'd point out to @djodjoni that the definition of MVVM on Android isn't tied to using the Databinding Library. The View layer includes both any UI classes and XML descriptors, - how you decide to bind the ViewModel and the View (through the DataBinding lib, or through Rx code) is entirely up to your project and doesn't break the MVVM pattern. In fact, with projects heavy on different configs - multiple layouts, UI A/B testing and the like, using the Databinding Lib can sometimes be a hindrance because of code duplication in the XML (even if you can limit this by reusing layouts).
tldr: DataBinding Libary is only one way to do Databinding.
@florina-muntenescu I see a branch as dev-todo-MVVM-rx but the actual implementation is a MVP, please do correct me if I'm wrong and happy to see an update on this.
there's a PR to merge a sample using MVVM with RxJava in the dev-todo-mvvm-rxjava branch
@clackbib
but I'd point out to @djodjoni that the definition of MVVM on Android isn't tied to using the Databinding Library
I have never said that. The definition of MVVM is tied however to using A Data/Control Binding module which does the 'smart' job outside the View and the ViewModel. RxJava is a very good candidate to design your data/control flows but how you apply it defines if this is MVVM or not. When you change Presenter to ViewModel and put binding capabilities in your Views could be one way to design your architecture but I wouldn't call it MVVM. Anyway these are just words just don't pick the ones that are in use:) I personally used to design my apps in a very similar way @florina-muntenescu did but just didn't call it MVVM :)
@djodjoni
The definition of MVVM is tied however to using A Data/Control Binding module which does the 'smart' job outside the View and the ViewModel
is where I disagree. In MVVM, one component, the ViewModel exposes streams of Data that the View binds to. The DataBinding library is just one way to alleviate writing this "plumbing" code, but writing this code in Rx doesn't break the pattern. Consider this example:
public class PostViewModel{
Subject<Int> progressVisibility ...
Subject<Int> layoutVisibility
Subject<String> pageTitle ...
Subject<String> postTitle...
Subject<String> postContent...
Subject<Int> postLikes...
private final Repository repository ...
private Observable<Object> refreshButtonClicks(Observable<Object> clicks){
return clicks
.doOnNext(n ->{
layoutVisibility.onNext(View.GONE);
progressVisibility.onNext(View.VISIBLE);
})
.switchMap(request ->repository.loadPost())
.doOnNext(post->{
layoutVisibility.onNext(View.VISIBLE);
progressVisibility.onNext(View.GONE);
pageTitle.onNext(post.title);
postTitle.onNext(post.postTitle);
postContent.onNext(post.postContent)
postLikes.onNext(post.likes);
})
}
//getters for subjects above
}
public class PostFragment extends Fragment{
... // onCreate, instantiate ViewModel
public void bindDataStreams(){
vm.refreshButtonClicks(RxView.clicks(refreshButton)).subscribe()
vm.layoutVisibility.subscribe(v -> container.setVisibility(v))
vm.progressVisibility.subscribe(v -> progressbar.setVisibility(v))
vm.pageTitle.subscribe(t -> pageTitle.setText(t))
vm.postTitle.subscribe(t -> postTitle.setText(t))
vm.postContent.subscribe(t -> postContent.setText(t))
vm.postLikes.subscribe(t -> postLikes.setText(t))
}
}
How does something like this not qualify as MVVM?
Most helpful comment
@djodjoni
The definition of MVVM is tied however to using A Data/Control Binding module which does the 'smart' job outside the View and the ViewModelis where I disagree. In MVVM, one component, the ViewModel exposes streams of Data that the View binds to. The DataBinding library is just one way to alleviate writing this "plumbing" code, but writing this code in Rx doesn't break the pattern. Consider this example:
How does something like this not qualify as MVVM?