rxviper/rxviper

Android micro framework for developing apps based on clean VIPER architecture.

This is a micro framework with a small, extensible API which provides basic abstractions for building your apps using VIPER architecture.

I copy these classes into all apps I make. I'm tired of doing it. Now it's a library. ©

Dedicated slides and video from my talk @ GDG Minsk 2016

SpeakerDeck or SlideShare

Download

Grab via Gradle:

compile 'com.dzaitsev.rxviper:rxviper:1.0.0-rc3'

Maven:

<dependency>
    <groupId>com.dzaitsev.rxviper</groupId>
    <artifactId>rxviper</artifactId>
    <version>1.0.0-rc3</version>
</dependency>

License

Copyright 2018 Dmytro Zaitsev

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.

rxviper's Issues

Add executeUnsafe method to Interactor

Hello, thanks for the great library.

I've faced issue with Interactor's execute method, this one:
https://github.com/RxViper/RxViper/blob/1.x/rxviper/src/main/java/com/dzaitsev/rxviper/Interactor.java#L149

The issue is, that method throws an exception in default onError implementation. The method was used for repetitive network requests, which are not important for app business logic, and the app should do nothing on error. E.g. actual app version check to propose new version for the user.

It would be really nice to add "unsafe" version of this method, which does nothing on errors.

I understand, that ignoring any errors is a potential way for bugs in an app, however, sometimes, there are cases, where this approach does fit.

Auto Generate Viper classes

Hello,

Great Work!!!

I just need to know that how can i Auto Generate Viper classes?

Interactor.execute(lambda, param) doesn't pass last param to Subscriber

• method 01
• method 02
• method 03

Crash in unit tests

After update to rc1 from 0.10.0, I unit tests crashes on any access to view or router methods.
See sample project, demonstrating the issue.
https://github.com/SemenovAlexander/RxViperReflectionBug

Get rid of deprecated viper.View

Description

It would be so useful if you add the slides and presentation about the project into the readme section.
Slides: http://www.slideshare.net/DmitriyZaitsev2/sexy-architecting-viper-mvp-on-steroids
Presentation: https://www.youtube.com/watch?v=pSSN_dnadKU

Add Interactor.isUnsubscribed()

Add sample how to save view state on rotation

Make Interactor.execute() non-final

It causes issues for testing Interactors with Mockito

Make Presenter's callbacks public

Ensure interfaces that extend ViewCallbacks don't have getters

According to the current implementation, Presenter#getView() always returns a proxy object to avoid NPEs in cases when a user tries to invoke view methods when it's already detached from a presenter.
Sometimes people violate the contract and use the library wrong way by adding getters to their views so that presenters can get some data from them.

This causes the following issue:

interface MyView extends ViewCallbacks {
    MyData getMyData(); // <--- this is mistake! You must avoid getters, but...
}

class MyPresenter extends Presenter<MyView> {
    // ..
    // the view's already dropped, hasView() == false
    MyData md = getView().getMyData(); // no NPE here, but we can get a reference to potential MyData object
    md.shitHappens(); // md == null, so the NullPointerException will be thrown
    // ..
}

I think, the library shouldn't allow such cases at all, so it has to check if view has getters and fail fast throwing runtime exception.
As an option, it would be nice to have a lint check for that.

Ensure presenter drops the same view and router that were attached

• Need to drop view when and only when the given view matches the last passed to takeView().
• Need to drop router when and only when the given router matches the last passed to takeRouter().

Hide Presenter#getRouter() and Presenter#getView()

These methods should be protected not public. Nobody except Presenter should get access to view and router.

Reconsider Presenter

Not all Presenters in projects usually need Router, only ViewCallbacks.
Would be great to have two kinds of Presenter: one that manages only view like in simple MVP and one that additionally manages Router for more complicated VIPER.

Make methods final

It will help to avoid issues in child classes

Provide JavaDoc

Add Gradle plugin

... that generates all boilerplate code from a simple config

Sample project has WindowLeaked after show progress and rotate device

Steps to reproduce
1 - Increase request time to 5 second for simplify reproduction.
2 - Click on GET DATA SUCCESS for showing progress.
3 - While is showing progress rotate device screen
4 - All done, you have WindowLeaked

Hold subscriptions in CompositeSubscription

Currently one has to unsubscribe manually and recreate Interactor every time to perform new use case because execute() could be called safely only once.
If we hold subscriptions in CompositeSubscription, it will allow us to call execute() safely as many times as needed and we'll be able to unsubscribe them all.

Change root package

Change rxviper -> com.dzaitsev.rxviper to avoid package conflicts.

Provide constructors for Presenter and ViperPresenter

Do not hold strong references to view and router in Presenter

Consider using weak references instead.
It will help to avoid memory leaks if user forgets to release view and router manually.

Remove parameter from onTakeX and onDropX methods

Presenters have view and router properties available.
At the same time the callback methods onTakeView(v), onTakeRouter(r) have view and router as parameters.
Very often developers launch different async jobs in that methods and capture strong references to views. For minimizing the number of issues related to it, it's better to get rid of those parameters and access views only as presenter's properties.
Also, if you use Kotlin, the property access syntax is available forgetView() and getRouter(), so within the onTakeView you won't need to call [email protected].

Change the order of the Interactor#execute() method parameters

Now all of the execute methods have requestModel the last parameter:

no param	w/ param
execute(onNext)	execute(onNext, requestModel)
execute(onNext, onError)	execute(onNext, onError, requestModel)
execute(onNext, onError, onComplete)	execute(onNext, onError, onComplete, requestModel)

This is not friendly with Kotlin where if the last parameter of a function accepts a function, a lambda expression that is passed as the corresponding argument can be placed outside the parentheses.
So, now in Kotlin we need to write:

interactor.execute({ item -> doSomething(item) }, param)

instead of:

interactor.execute(param) {
    item -> doSomething(item)
}

At the same time, the current order causes issues with correct type inference.
I think, it's reasonable to make responseModel the first parameter.

Observe in main thread

Why execute CheeseStorage in Main Thread ?

Create Android IDE Templates

Inspired by #52

Add RxJava 2 support

Add support for JSR-305 Nullable/Nonnull annotations

Consider com.google.code.findbugs:jsr305:3.0.2

Protect Presenter's methods from overriding

Need to add callback methods onViewTaken(view), onViewDropped(), onRouterTaken(router), onRouterDropped() and make them protected. Methods takeView(view), dropView(), takeRouter(router) and dropRouter() should be final.

Provide detailed ReadMe

Let Mapper implement Func1<T, R>

It will help to write shorter code
instead of

stream.map(item -> mMapper.map(item))

or

stream.map(mMapper::map)

just

stream.map(mMapper)

Allow call Interactor.execute() without params

Use dynamic proxying for null safe using view and router

Use Action in observer callbacks

It would be great if you implemented a wrapper for the subscriber like it's done in Observable class here:

public final Subscription subscribe(final Action1<? super T> onNext, final Action1<Throwable> onError, final Action0 onComplete) {
        return subscribe(new Subscriber<T>() {

            @Override
            public final void onCompleted() {
                onComplete.call();
            }

            @Override
            public final void onError(Throwable e) {
                onError.call(e);
            }

            @Override
            public final void onNext(T args) {
                onNext.call(args);
            }

        });
    }

It would allow to use lambdas in code and avoid bulky anonymous classes

Provide sample project