Develop Reference

Using interfaces for ViewModels?

I am currently integrating architecture components into my app according to the official documentation and the sample apps provided by google (sunflower and todo-app). I realized that none of these use interfaces for ViewModels (the sunflower app does not even use interfaces for repositories).
My question is: is it reasonable to just omit the interfaces for ViewModels (including advantages and disadvantages)?

Is it reasonable to just omit the interfaces for ViewModels?
The below is quite general and applicable not just for ViewModels.
Advantages:
less code
Disadvantages:
won't be able to use most of the well-known design patterns;
won't be able to properly unit test classes (no mocking);
won't be able to properly use dependency injection frameworks;
code refactoring when using another concrete implementation.

The answer depends on the complexity of your ViewModel. If you are never going to create more than one implementation of an interface (including mocking), then there is no need to create the interface, so you can reduce the code and the overall maintenance burden.
That said the important things to consider are:
Can you unit test your view model, even without the interface (answer should be yes, otherwise you have some other problems IMO)
Can you still use a dependency injection framework (the answer is yes at least for some DI frameworks like Prism)
Are you only ever going to create one implementation of your ViewModel?
I believe that the mark of a well-designed ViewModel, should have a relatively simple implementation, and be easy to unit-test without having to resort to mocking.

Is it correct to bind a ViewModel to a Service?

I've started using Architecture Components in my application and I'm still learning how to use it.
In my app I have an Activity showing different Fragments sequentially. In some of them I need to communicate with a background service in order to receive data from external BLE sensors. Since I need to interact with the service in more than one Fragment, I'm wondering if ViewModel is the right place where to make the binding. I've looked around but I didn't found an answer.
Are there any problems binding a service inside a ViewModel?

It is not advisable to use Android framework classes inside ViewModels.
Here is the link on Google Developers blog post with the detailed explanation: ViewModels and LiveData: Patterns + AntiPatterns
Ideally, ViewModels shouldn’t know anything about Android. This
improves testability, leak safety and modularity. A general rule of
thumb is to make sure there are no android.* imports in your
ViewModels (with exceptions like android.arch.*). The same applies to
presenters.
Don’t let ViewModels (and Presenters) know about Android framework
classes

MVP Implementation in Android

I am looking into MVP architecture Implementation in android.
I found too many ways(mention end of the question) to implement it in the android studio, but Still, I am confused.
Can someone help me to find the right answer of below questions.
What would be directory structure of Application in MVP?
Activity should be a Presenter or View?
Way-1
Way-2

What would be directory structure of Application in MVP?
There is no predefined structure for that. What makes your code readable or what structure you are following, you can use same for MVP also.
Activity should be a Presenter or View?
View is the UI layer which displays the data and notifies the Presenter about user actions. So Activity will always be a view.
If you are looking for a good example of MVP implementation, there is one GitHub Repo for MVP developed by Android itself. Which you should look into.
Where
todo‑mvp
Demonstrates a basic Model‑View‑Presenter (MVP) architecture and provides a foundation on which the other samples are built. This sample also acts as a reference point for comparing and contrasting the other samples in this project.
todo‑mvp‑clean
Uses concepts from Clean Architecture.
todo‑mvp‑dagger
Uses Dagger 2 to add support for dependency injection.
todo‑mvp‑rxjava
Uses RxJava 2 to implement concurrency, and abstract the data layer.
todo‑mvvm‑databinding
Based on the todo-databinding sample, this version incorporates the Model‑View‑ViewModel pattern.
todo‑mvvm‑live
Uses ViewModels and LiveData from Architecture Components and the Data Binding library with an MVVM architecture.

Though there are lot of implementations for an MVP architecture, all of them share a basic idea (or they should at least), which is separating business logic from your views (activities, fragments, dialogs). Why is that? Well, for two reasons mainly:
separation of concerns
Testability: your business logic is able to be tested if there is no android components involved.
About your questions:
What would be directory structure of Application in MVP?
There is no rule about that except that your MVP components should be identified. Here you have an article where I started with a package structure but then I found other more convenient.
Activity should be a Presenter or View?
Your activity (or fragment or whatever components in charge of showing view components) should be the one that implements your view.
My advice is that you should check multiples examples and see their advantages and disadvantages of each one, and try to define your own architecture from those which you will feel more comfortable with.

You can use either Activity or Fragment for View layer. This is because showing UI elements in android needs Context.
For the Presenter layer, you must make sure not to pass the Context to the Presenter via constructor or setter. If you needed Context in your Presenter for tasks other than showing the UI, such as writing to SharedPreferences, you can get it from your View (which is either Activity or Fragment). In this way, if the View gets destroyed or becomes null, there would no standalone null Context in the Presenter to cause leak issues.
If you want to know more about the MVP structure, I have written a very handy MVP library for android and explained its use in a sample app here.

MVP android sample example application
MVP Android Example used to explain how to use this pattern in our Android apps.

MVVM with Android Architecture Components

I'm exploring the new Android Architecture Components and looking to implement it into an Android app. I am firmillair with MVVM as I use the paradigm on iOS development. Having read through the Android Architecture Components guide, provided by Google: https://developer.android.com/topic/libraries/architecture/guide.html
I have just a few questions...
In the above mentioned guide, Google use the UserRepository class that access these web service API - they go on to make this class a Singleton which is probably fine, if there were only ever one screen on the app that needed data from a REST API.
My concern, is this; it seems Google advocate the need to create a repository class on a per-ViewModel basis. This sounds very wrong to me, in having so many Singlton classes in the app. If we were to have 10 screens, with ten ViewModels - each needing its own Repository module - we then have ten singletons in our app. From an iOS dev perspective, this is wrong to have so many.
The solution to this, would be to have one mediator (Repository) class, that has public methods, exposing the API to get data from a REST API. The Web service part, would be in its own class. That way, we have a decent separation of concerns.
Is it best practice, to have one repository class, per, ViewModel - or to have one per app? I'm not 100% sure on this.
Lastly, I have the same concern when it comes to Room- is Google saying we create a DB on a per ViewModel bases or just one DB per app?

I don't think the architecture guide suggests to create a separate repository class for each ViewModel. In the example that is shown Google uses a library called Dagger to inject the singleton repository class into the ViewModel. It is normally best practice to split repositories (or managers) on functionality. UserRepository is responsible for all user related api calls for example.
If you turn this repository into a singleton that you can inject in any ViewModel, any ViewModel now has access to that specific repository.
After quickly looking into Room I found this little snippet (link):
Note: You should follow the singleton design pattern when instantiating an AppDatabase object, as each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances.
This to me means that you can implement the RoomDatabase much in the same way you can use your repository classes. Simply inject them as a singleton into your ViewModel so you don't need to have multiple instances of the same database.

Model-View-Presenter and Android Application Design

The Problem: Really large and convoluted Activity classes. Hard to read/understand and modify. Hard to test.
The Possible Solution: Model-View-Presenter (perhaps with dependency injection).
And Mock Test Objects!
I'm planning on implementing Model-View-Presenter in my Android application.
This is basically a variant of the Model-View-Controller. In essence, make the Activity
a glorified layout manager and defer any business logic to the Presenter. Another way of looking at the Presenter is that its like an Helper class instantiated within an Activity to do the heavy lifting with the activity providing a interface/callback that the Presenter can use.
I would like to get some community thoughts on this. For example:
What interfaces are implied by this?
What responsibilities would the Model and View have vs. the Presenter.
For Presenter I suppose the Activity would implement the interfaces needed by the Presenter?
What kinds of things should go into the Presenter vs. Activity?
Would a presenter be one-to-one with an Activity? What about an Activity with multiple fragments displaying different widgets each with its own adapter? Do we now need multiple presenters or still just one?
What about Presenter vs. Adapter?
How should a presenter relate to say an Activity with a ListView and a ListViewAdapter?
What goes into the Presenter vs. Adapter?
Should the Presenter pick the Adapter to use? Or should the Activity make this decision?
Should the Presenter process Model Data or the Adapter? Is there a conflict between adapters and presenters? Are adapters presenters? or something less/more. Usually Adapters are just for widgets like ListViews within an Activity. They don't make the calls that get the data itself I think.
So in model-view-presenter the key thing is really to decides what goes in the presenter vs. other classes and what the communication should be between the presenter and activities, adapters and views/including fragments.
Is Model-View-Presenter just a really bad idea for Android? Or does it fit well with the Android Framework?
Keep in mind there are numerous examples outside Android of very mature SDK's that still needed a micro-architecture like MVP. In fact examples abound: eg. Flex was very mature SDK for Flash and yet it still needed MVP and MVC frameworks for almost any major app.
EJB needed Spring to simplify and organize it. MFC/Struts etc and the list goes on and on. Why should Android be any different? Why should we assume the SDK has everything needed in the case of Android without a design pattern like MVP?
Nice to know before I spend hundreds of hours on this, please feel free to comment/answer on any part of this question.

Android punishes poor MV(P|C) design more than any platform I've ever encountered. Forget the clumsy methods it provides for passing state up and down the activity stack. Get as much state and logic out of your activities as possible. Move it into Services, ContentProviders, and SharedPreferences as appropriate. Try to make your activities pure view. IMO, Services have never been given enough attention in Android tutorials. Even the O'Reilly Programming Android book only gives them a quarter page!
Be wary of extending Application. If you ever start a Service in its own process (e.g., to allow it to be shut down gracefully when an Activity crashes) then the Service will have its own copy of your Application.

Just to provide a reference for others who may be interested. I was thinking the same thing some years before. When we apply MVC/MVVM/Presentation Model to android app, what we really want is to have a clear structured project and more importantly easier for unit tests. At the moment, without an third party framework, you usually have lots of code(like addXXListener(), findViewById()...), which does not add any business value. What's more, you have to run android unit tests instead of normal JUnit tests, which take ages to run and make unit tests somewhat impractical. For these reasons, some years ago we started an open source project RoboBinding - A data-binding Presentation Model framework for the Android platform. RoboBinding helps you write UI code that is easier to read, test and maintain. RoboBinding removes the need of unneccessary code like addXXListener or so, and shifts UI logic to Presentation Model, which is a pojo and can be tested via normal JUnit tests. RoboBinding itself comes with more than 300 JUnit tests to ensure its quality. Other alternatives: Android-Binding, Bindroid and MvvmCross.