<ol>
<li>Don't let ViewModels know about Android framework classes. (A general rule of thumb is to make sure there are not(android.) imports in your ViewModels(with an exception like android.arch.)
</li>
<li>Keep the logic in activities and Fragments to a minimum.
</li>
<li>Avoid references to Views in ViewModels.(Result in generating memory leak in most of the cases).
</li>
<li>Instead of pushing data to the UI, let the UI observe changes to it.
</li>
<li>Distribute responsibilities, add domain layer if needed.(Avoid Fat ViewModel)
</li>
<li>Add a data repository as a single point entry to your data.
</li>
<li>Expose information about the state of your data using a wrapper or another LiveData.
</li>
<li>Whenever your think you need a Lifecycle object inside a ViewModel, A Transformation is probably the solution.
</li>
<li>You don't usually extend LiveData. Let your activity or fragment tell the ViewModel when it's time to start loading data.
</li>
</ol>

1. Don't let ViewModels know about Android framework classes. (A general rule of thumb is to make sure there are not(android.*) imports in your ViewModels(with an exception like android.arch.*)

2. Keep the logic in activities and Fragments to a minimum.

3. Avoid references to Views in ViewModels.(Result in generating memory leak in most of the cases).

4. Instead of pushing data to the UI, let the UI observe changes to it.

5. Distribute responsibilities, add domain layer if needed.(Avoid Fat ViewModel)

6. Add a data repository as a single point entry to your data.

7. Expose information about the state of your data using a wrapper or another LiveData.

8. Whenever your think you need a Lifecycle object inside a ViewModel, A Transformation is probably the solution.

9. You don't usually extend LiveData. Let your activity or fragment tell the ViewModel when it's time to start loading data.

Keep these things in mind when using ViewModel in your application

Table of contents

No headings in the article.