A powerful, and very simple MVP library with annotation processing and bytecode weaving.
EasyMVP eliminates the boilerplate code for dealing with MVP implementation.
- Easy integration
- Less boilerplate
- Composition over inheritance
- Implement MVP with just few annotations
- Use Loaders to preserve presenters across configurations changes
- Support Clean Architecture approach.
Configure your project-level build.gradle
to include the 'easymvp' plugin:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.sixthsolution.easymvp:easymvp-plugin:1.0.0-beta4'
}
}
Then, apply the 'easymvp' plugin in your module-level build.gradle
:
apply plugin: 'easymvp'
android {
...
}
For reactive API, simply apply the 'easymvp-rx' plugin in your module-level build.gradle
and then add the RxJava dependency:
apply plugin: 'easymvp-rx'
dependencies {
compile 'io.reactivex:rxjava:x.y.z'
}
First thing you will need to do is to create your view interface.
public interface MyView {
void showResult(String resultText);
void showError(String errorText);
}
Then you should implement MyView
in your Activity
, Fragment
or CustomView
.
But why?
- Improve unit testability. You can test your presenter without any android SDK dependencies.
- Decouple the code from the implementation view.
- Easy stubbing. For example, you can replace your
Activity
with aFragment
without any changes in your presenter. - High level details (such as the presenter), can't depend on low level concrete details like the implementation view.
Presenter acts as the middle man. It retrieves data from the data-layer and shows it in the View.
You can create a presenter class by extending of the AbstractPresenter
or RxPresenter
(available in reactive API).
public class MyPresenter extends AbstractPresenter<MyView> {
}
To understand when the lifecycle methods of the presenter are called take a look at the following table:
Presenter | Activity | Fragment | View |
---|---|---|---|
onViewAttached |
onStart |
onResume |
onAttachedToWindow |
onViewDetached |
onStop |
onPause |
onDetachedFromWindow |
onDestroyed |
onDestroy |
onDestroy |
onDetachedFromWindow |
Well, here is the magic part. There is no need for any extra inheritance in your Activity
, Fragment
or View
classes to bind the presenter lifecycle.
Presenter's creation, lifecycle-binding, caching and destruction gets handled automatically by these annotations.
@ActivityView
for all activities based onAppCompatActivity
.@FragmentView
for all fragments based onDefault Fragment
orSupport Fragment
@CustomView
for all views based onView
.
For injecting presenter into your activity/fragment/view, you can use @Presenter
annotation. Also during configuration changes, previous instance of the presenter will be injected.
EasyMVP uses Loaders to preserve presenters across configurations changes.
Presenter instance will be set to null, after onDestroyed
method injection.
@ActivityView
example:
@ActivityView(layout = R.layout.my_activity, presenter = MyPresenter.class)
public class MyActivity extends AppCompatActivity implements MyView {
@Presenter
MyPresenter presenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
@Override
protected void onStart() {
super.onStart();
// Now presenter is injected.
}
@Override
public void showResult(String resultText) {
//do stuff
}
@Override
public void showError(String errorText) {
//do stuff
}
}
- You can specify the layout in
@ActivityView#layout
and EasyMVP will automatically inflate it for you.
@FragmentView
example:
@FragmentView(presenter = MyPresenter.class)
public class MyFragment extends Fragment implements MyView {
@Presenter
MyPresenter presenter;
@Override
public void onResume() {
super.onResume();
// Now presenter is injected.
}
@Override
public void showResult(String resultText) {
//do stuff
}
@Override
public void showError(String errorText) {
//do stuff
}
}
@CustomView
example:
@CustomView(presenter = MyPresenter.class)
public class MyCustomView extends View implements MyView {
@Presenter
MyPresenter presenter;
@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
// Now presenter is injected.
}
@Override
public void showResult(String resultText) {
//do stuff
}
@Override
public void showError(String errorText) {
//do stuff
}
}
@Presenter
annotation will instantiate your presenter class by calling its default constructor, So you can't pass any objects to the constructor.
But if you are using Dagger, you can use its constructor injection feature to inject your presenter.
So what you need is make your presenter injectable and add @Inject
annotation before @Presenter
. Here is an example:
public class MyPresenter extends AbstractPresenter<MyView> {
@Inject
public MyPresenter(UseCase1 useCase1, UseCase2 useCase2){
}
}
@ActivityView(layout = R.layout.my_activity, presenter = MyPresenter.class)
public class MyActivity extends AppCompatActivity implements MyView {
@Inject
@Presenter
MyPresenter presenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
SomeDaggerComponent.injectTo(this);
super.onCreate(savedInstanceState);
}
//...
}
Don't inject dependencies after super.onCreate(savedInstanceState);
in activities, super.onActivityCreated(bundle);
in fragments and super.onAttachedToWindow();
in custom views.
You can follow the principles of Clean Architecture by applying 'easymvp-rx' plugin. Previous part was all about the presentation-layer, Now lets talk about the domain-layer.
Domain Layer holds all your business logic, it encapsulates and implements all of the use cases of the system. This layer is a pure java module without any android SDK dependencies.
UseCases are the entry points to the domain layer. These use cases represent all the possible actions a developer can perform from the presentation layer.
Each use case should run off the main thread(UI thread), to avoid reinventing the wheel, EasyMVP uses RxJava to achieve this.
You can create a use case class by extending of the following classes:
public class SuggestPlaces extends ObservableUseCase<List<Place>, String> {
private final SearchRepository searchRepository;
public SuggestPlaces(SearchRepository searchRepository,
UseCaseExecutor useCaseExecutor,
PostExecutionThread postExecutionThread) {
super(useCaseExecutor, postExecutionThread);
this.searchRepository = searchRepository;
}
@Override
protected Observable<List<Place>> interact(@NonNull String query) {
return searchRepository.suggestPlacesByName(query);
}
}
public class InstallTheme extends CompletableUseCase<File> {
private final ThemeManager themeManager;
private final FileManager fileManager;
public InstallTheme(ThemeManager themeManager,
FileManager fileManager,
UseCaseExecutor useCaseExecutor,
PostExecutionThread postExecutionThread) {
super(useCaseExecutor, postExecutionThread);
this.themeManager = themeManager;
this.fileManager = fileManager;
}
@Override
protected Completable interact(@NonNull File themePath) {
return themeManager.install(themePath)
.andThen(fileManager.remove(themePath))
.toCompletable();
}
}
And the implementations of UseCaseExecutor
and PostExecutionThread
are:
public class UIThread implements PostExecutionThread {
@Override
public Scheduler getScheduler() {
return AndroidSchedulers.mainThread();
}
}
public class BackgroundThread implements UseCaseExecutor {
@Override
public Scheduler getScheduler() {
return Schedulers.io();
}
}
Each DataMapper transforms entities from the format most convenient for the use cases, to the format most convenient for the presentation layer.
But, why is it useful?
Let's see SuggestPlaces
use case again. Assume that you passed the Mon
query to this use case and it emitted:
- Montreal
- Monterrey
- Montpellier
But you want to bold the Mon
part of each suggestion like:
- Montreal
- Monterrey
- Montpellier
So, you can use a data mapper to transform the Place
object to the format most convenient for your presentation layer.
public class PlaceSuggestionMapper extends DataMapper<List<SuggestedPlace>, List<Place>> {
@Override
public List<SuggestedPlace> call(List<Place> places) {
//TODO for each Place object, use SpannableStringBuilder to make a partial bold effect
}
}
Note that Place
entity lives in the domain layer but SuggestedPlace
entity lives in the presentation layer.
So, How to bind DataMapper
to ObservableUseCase
?
public class MyPresenter extends RxPresenter<MyView> {
private SuggestPlace suggestPlace;
private SuggestPlaceMapper suggestPlaceMapper;
@Inject
public MyPresenter(SuggestPlace suggestPlace, SuggestPlaceMapper suggestPlaceMapper){
this.suggestPlace = suggestPlace;
this.suggestPlaceMapper = suggestPlaceMapper;
}
void suggestPlaces(String query){
addSubscription(
suggestPlace.execute(query)
.map(suggetsPlaceMapper)
.subscribe(suggestedPlaces->{
//do-stuff
})
);
}
}
How does EasyMVP work under the hood?
- For each annotated class with
@ActivityView
,@FragmentView
or@CustomView
, EasyMVP generates*_ViewDelegate
class in the same package. These classes are responsible for binding presenter's lifecycle. - EasyMVP uses bytecode weaving to call delegate classes inside your view implementation classes. You can find these manipulated classes in
build/weaver
folder.
Is there any restrictions on using EasyMVP?
- EasyMVP uses android's transform API for bytecode weaving. Related to this issue the Jack toolchain doesn't support it yet.
EasyMVP API: Javadocs for the current API release
EasyMVP RX-API: Javadocs for the current RX-API (Clean Architecture API) release
Copyright 2016 6thSolution
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.