Android Apps with Mortar and Flow

Transcript

1. Android Apps with Mortar and Flow Edward Dale @scompt

2. Agenda • Motivation • Flow • Mortar http://knowyourmeme.com/memes/business-cat

3. Motivation

4. Motivation • Lots of activities (old) • Lots of fragments

   (new) • Loaders • Lifecycle fun hell • Fragment transitions • Back stack The Android Way

5. Motivation • Lots of activities (old) • Lots of fragments

   (new) • Loaders • Lifecycle fun hell • Fragment transitions • Back stack The Android Way • Few activities • No fragments • Fatter views • Dependency injection • RxJava The Square Way

6. Sample App https://github.com/square/flow

7. Sample App https://github.com/square/flow

8. Flow A small library that helps with describing an app

   as a collection of moderately independent screens.

9. Flow • A screen in a POJO with the @Screen

   annotation saying which view or layout should be used to display it. • The Backstack is a stack of these objects. • The Flow is the interface for navigating the history of your app. http://www.rluxemburg.com/2013/09/01/kitten-flow-chart/

10. The conversation list screen @Screen(ConversationListView.class) public class ConversationList { }

11. The conversation view screen @Screen(ConversationView.class) public static class Conversation implements

    HasParent<ConversationList> { public final int conversationIndex; ! public Conversation(int conversationIndex) { this.conversationIndex = conversationIndex; } ! @Override public ConversationList getParent() { return new ConversationList(); } }

12. App start Object firstScreen = new ConversationList(); Backstack backstack =

    Backstack.single(firstScreen); Flow flow = new Flow(backstack, this); go(flow.getBackstack(), Flow.Direction.FORWARD);

13. On conversation tap Flow flow = ...; int position =

    <index of conversation>; flow.goTo(new Conversation(position));

14. • Controller layer is a bit 
 too ad-hoc But

    not quite enough This is nice • No fragments • Unified interface for navigating in the app • Power over the back stack http://www.catster.com/molz/happy-cat-is-happy

15. • Controller layer is a bit 
 too ad-hoc But

    not quite enough This is nice • No fragments • Unified interface for navigating in the app • Power over the back stack

16. Mortar Mortar eases the use of Dagger to divide Android

    apps into composable modules.

17. Mortar • View and controller destroyed in traditional android MVC

    • Only view destroyed with MVP under mortar. Presenter stays around. MVC MVP

18. Mortar • Every Screen has an associated Dagger Module •

    Every View has an associated ViewPresenter Implementation http://animals.desktopnexus.com/wallpaper/1386356/

19. Blueprint @Screen(ChatListView.class) public class ChatListScreen implements Blueprint { @Override public

    String getMortarScopeName() { return getClass().getName(); } @Override public Object getDaggerModule() { return new Module(); } }

20. ViewPresenter public class ChatListView extends ListView implements ChatListScreen.View { @Inject

    ChatListScreen.Presenter presenter; ! public ChatListView(Context context, AttributeSet attrs) { super(context, attrs); Mortar.inject(context, this); } ! @Override protected void onAttachedToWindow() { super.onAttachedToWindow(); presenter.takeView(this); } }

21. http://www.catster.com/molz/happy-cat-is-happy This is nice • Screens are self-contained and injected,

    facilitating testing • Insulated from lifecycle events • Memory efficient

22. Mortar Flow A small library that helps with describing an

    app as a collection of moderately independent screens. Mortar eases the use of Dagger to divide Android apps into composable modules. Questions? Edward Dale @scompt