Custom Views as components - DroidJam '18

How will you organize your android app's 10k+ lines of code written by group of people? In a couple of months, before you know it, it'll cross a 100k lines. Wouldn't it be great if when a new feature requirement comes, you create a new class and start working on it, rather than worrying about what other things might break if you edit this 5k lines Activity/Presenter class?

Enter components.
Components are intuitive! They let you split your code into independent, reusable pieces, and think about each piece in isolation- great for abstraction and modularization.

Developers don't realize that rather than fragments, they can create custom views and use them as components. Views are light-weight and don't blow up in your face with the infamous IllegalStateException. You don't need any libraries or learn a new programming paradigm to get started.

In this talk, I go through how to get started with views, how using views has made my teams' lives easier, some common patterns implementing different use-cases and how to unit test.

Transcript

1. <custom.views.as.Components>
2. CURRENT STATE OF CODE TaskStatusPresenter: 4k Lines of Code LIFE’S A BITCH
3. LIFE’S GOOD WITH COMPONENTS TaskStatusRoot: 918 LoC MapFragment: 1144 LoC ChatView: 351 LoC …
4. WITH MV* Sorry jim, but you have drawn the short straw after 2 hours of discussion on the interfaces…
5. WITH COMPONENTS lets build!
6. ARE COMPONENTS, FRAGMENTS?
7. OVER KILL! FRAGMENTS? IllegalStateException() getFragmentManager/ getSupportFragmentManager onCreate()… onSaveInstanceState Tough to put them in RecyclerView/ LinearLayout Nesting Fragments
8. VIEWS! IllegalStateException() getFragmentManager/ getSupportFragmentManager onCreate()… onSaveInstanceState RecyclerView/LinearLayout friendly XML friendly Nesting Components ARE THE BEST COMPONENTS
9. YOU CAN PUT ANYTHING IN COMPONENTS
10. YES, EVEN “BUSINESS LOGIC”
11. — The new GO-JEK rider app (COMPONENTS) CAN CONTAIN BOTH UI AND BUSINESS LOGIC ” “ https://blog.gojekengineering.com/an-architectural-overview-of-the-new-go-jek-rider-app- bb1dbd174323
12. — Unix DO ONE THING AND DO IT WELL ” “
13. CREATING COMPONENTS
14. THE CONSTRUCTOR CREATE A CUSTOM VIEW MyAwesomeComponent(…) : FrameLayout(…) { // This is an actual constructor, unlike // onCreate() and onCreateView() that just // look like constructors, but aren’t. init { View.inflate(context, R.layout.view_my, this) } }
15. PASS IN THE DATA CREATE A CUSTOM VIEW class AddEditRootView(…) { /** * Pass in the data */ fun showTaskWithId(id: String?) { id ?: return context.getTasksRepository().getTask(id) .subscribe { task -> mTask = task add_task_title.setText(task.title) add_task_description.setText(task.description) } }
16. CREATE THE DEPENDENCY SETUP THE DEPENDENCIES class MyApplication : Application(), TasksRepositoryFactory { override val tasksRepository: TasksRepository by lazy { … } } interface TasksRepositoryFactory { val tasksRepository: TasksRepository }
17. FETCH THE DEPENDENCY SETUP THE DEPENDENCIES /** * Calls the correct implementation of application * based on the manifest or roboletric properties */ fun Context.getTasksRepository() = (applicationContext as TasksRepositoryFactory) .tasksRepository
18. UNIT TESTING
19. SETUP FOR EVERY SCREEN THE STATUS QUO - UNIT TESTING IN MVP For every screen, we additionally need a: 1.ViewContract 2.PresenterContract 3.DaggerModule 4.Presenter
20. VERIFY METHOD CALLS IN TEST THE STATUS QUO - UNIT TESTING IN MVP verify(mockedClass).methodCall(withArgs) // saved to the model verify(mTasksRepository).saveTask(any(Task.class)); // shown in the UI verify(mAddEditTaskView).showTasksList();
21. — TDD Gods VERIFY BEHAVIOUR, NOT IMPLEMENTATION ” “
22. VERIFY SIDE-EFFECTS UNIT TESTING IN COMPONENTS // verify behaviour assertThat(getTasksInRepo().count(), `is`(1)) assertThat(activity.isFinishing, `is`(true))
23. HOW TO? UNIT TESTING IN COMPONENTS WITH ROBOLECTRIC
24. THE SETUP UNIT TESTING IN COMPONENTS class TestApplication : Application(), TasksRepositoryFactory { override val tasksRepository: TasksRepository by lazy { // create a test repo object … } } # robolectric.properties application=mocks.TestApplication
25. “GLOBAL” DEPENDENCIES UNIT TESTING IN COMPONENTS Now context.getTasksRepository() returns the test object. Magic! No need for: @Mock private TasksRepository mTasksRepository; @Mock private AddEditTaskContract.View mAddEditTaskView; in your tests.
26. WITH ROBOLECTRIC UNIT TESTING IN COMPONENTS
27. COMPARISON UNIT TESTING IN COMPONENTS // saved to the model verify(mTasksRepository).saveTask(any(Task.class)); // shown in the UI verify(mAddEditTaskView).showTasksList();
28. TESTING TIME WITH ROBOLECTRIC No doubt slower than JUnit. 5 sec with JUnit vs 10 sec with Robolectric. It reduces the number of espresso tests which decreases complete-test times. You will still have JUnit tests (for the data repositories, for example). Robolectric speed will only increase with sub- sequent versions.
29. COMPOSE COMPONENTS
30. YOU CAN PUT THEM ANYWHERE In XMLs In RecyclerViews Inside other components!
31. RE-USE THEM SUPER EASY TO DO
32. IF YOU DO THINGS CORRECTLY…
33. THE TREE STRUCTURE Data Repository RootComponent Retrofit Glide Local SQL Firebase LeafComponent
34. PARENT-CHILD COMMUNICATION COMMUNICATION BETWEEN NODES x
35. SIBLING COMMUNICATION COMMUNICATION BETWEEN NODES x x
36. MUCH EASIER TO LEARN (AND TEACH) THAN MVVM OR MVI
37. onPause() Components are intuitive and much more modular. Fully unit testable via robolectric. You probably don’t need the lifecycle callbacks or onSaveInstanceState provided by Fragments. Easy to learn and implement in a team- No abstractions for tests.
38. TRADE OFFS It adds another layer in your test pyramid, between JUnit and espresso. If your use case needs a lot of among interactions, you may need to do a MV* inside that view. No silver bullet for transitive state management
39. </custom.views.as.Components> @vedant_ag @vedanta