Segue service

[pardom-zz]

The library additions depend on SimplePathContainer for view inflation, however, there is no way to provide custom animations. Ideally, SimplePathContainer could fetch a segue animation using something like SegueService.getSegueAnimator(context) and default to the basic animation if no service is found.

[almozavr]

Good catch, but also one could copy/modify-and-provide CustomPathContainer to make own-style animation, or even make a AnimFactory which will create animation depending on Path properties.

[pardom-zz]

Yes, I considered those alternatives. Out of all those, I would probably lean towards the AnimFactory type solution. If that were the preferred route, I would also like to see ScreenScoper support factory composition. For example: https://speakerdeck.com/loganj/android-forestry-droidcon-nyc-2015?slide=95

[almozavr]

I consider ScreenScoper way a little bit obtrusive as for library as it's not clear for client how to scale it for custom needs – by now I'm using something like this to control title and drawer:

public class StyledPath extends Path {

    public PathAttrs getAttrs() {
        return EMPTY;
    }

    @Value.Immutable
    public static abstract class PathAttrs {

        public abstract @StringRes int title();
        @Value.Default public boolean drawerEnabled() {
            return true;
        }

        public static ImmutablePathAttrs of(@StringRes int title) {
            return ImmutablePathAttrs.builder().title(title).build();
        }

        public static ImmutablePathAttrs withDrawer(boolean enabled) {
            return ImmutablePathAttrs.builder().title(R.string.app_name).drawerEnabled(enabled).build();
        }

    }

    public static PathAttrs EMPTY = PathAttrs.of(R.string.app_name);
}

Would like to think about ScreenScoper way a bit more.

[almozavr]

Anyway, mortar-flow is the square-way for android. So, it's quite strong opinion to move that direction :)