The way we build screens on Android changed significantly over the last years. We went from huge classes, strongly coupled with Android and containing a lot of responsibilities to a reactive-based data flow. It helped us to address ever-changing business requirements, extend functionality without adding unmanageable complexity and improve the app’s reliability. In this presentation I talked about lessons learned from this journey and the pros and cons of each approach.

1. Building complex
screens on
Android
Maciej Witowski
April 10th 2019, 1pm
Usability
#ZES19

2. Let’s get started!
Check-in to the session
on the App!
Turn on the Zoom! Record the Zoom!
#ZES19

3. A long time ago...

4. A long time ago...

5. A long time ago...

7. ● One of the top mobile CRMs
in App Store and Play Store
● 8000 paying users
● Offline mode, Voice, Calendar, Maps etc.
● Average screen time at 71 minutes per day

8. With a lot of features comes a lot of responsibility

9. With a lot of features comes a lot of responsibility
many lines of code

10. > 400k LOC

11. This talk
Old vs New way of building screens

12. Main types of objects in Sell

13. Main types of objects in Sell
Contact
Company
Person
Lead
Deal

14. Main types of objects in Sell
Contact
Company
Person
Lead
Deal

15. Main types of objects in Sell
Contact
Company
Person
Lead
Deal
You can create new
objects and edit
existing ones

16. Our task
Build the edit screens for these objects

18. The Old Way

19. Types Edit Screens
Contact
Company
Person
Lead
Deal

20. Types Edit Screens
Contact
Company
Person
Lead
Deal
ContactEditFragment
CompanyEditFragment
PersonEditFragment
DealEditFragment
LeadEditFragment

21. Fragment per object type
● Huge classes containing both view and logic
● Deep inheritance hierarchy
● Duplicated functionality
BaseFragment
Fragment
ContactEditFragment
CompanyEditFragment

22. Callbacks everywhere
● No clear direction
● Confusing lifecycle
● Problematic events handling
● Errors propagation
@OnClick(R.id.show_company)
private void onClick() {
Loader<Company> loader = new Loader<Company>(){
@Override
public void onLoadFinished(Company company) {
setCompanyData(company);
}
};
initLoader(loader);
}

23. Mutable state
● Extreme complexity growth
● Hard to debug
● Concurrency problem
private ContactData initialContactData;
private ContactData currentContactData;
private ContactData temporaryContactData;
private boolean isErrorShown;
private boolean canSaveNow;

24. Coupling with Android SDK
● No boundary between business logic and platform code
● Handling quirky APIs
● No way to unit test
● Espresso not ready

25. Modeling with primitives
● No built-in support for value objects in Java
● Working with Android SDK

26. Modeling with primitives
● No built-in support for value objects in Java
● Working with Android SDK
● “Performance impact”

27. Old times - sum up
● Inheritance
● Callbacks
● Mutable state
● Coupling with the Android SDK
● Lack of tests
● Modeling the logic using primitives

28. Time went by...

29. Time went by...
● Building many new screens
● Exploring new patterns, mostly Model-View-Presenter
● New tools, Kotlin, RxJava, Espresso

30. Time went by...
● Building many new screens
● Exploring new patterns, mostly Model-View-Presenter
● New tools: Kotlin, RxJava, Espresso
When it comes to the edit screens
● Small product changes
● Didn’t justify the investment
● Sticking the new code and hoping it will work

31. 2017: Required Fields

32. What is a better way to build screens?

33. Unidirectional Data Flow
StoreView
State
Actions

34. Unidirectional Data Flow
StoreView
State
https://github.com/zendesk/Suas-Android
Actions

35. Unidirectional Data Flow
View Reducer
Fields Builder
Configuration
Provider
Store

36. Unidirectional Data Flow

37. Unidirectional Data Flow
name: null,
phone: null

38. Unidirectional Data Flow
name: null,
phone: null
name: null,
phone: null

39. Unidirectional Data Flow
name: null,
phone: null
field(name: null),
field(phone: null)
name: null,
phone: null

40. Unidirectional Data Flow
name: null,
phone: null
field(name: null),
field(phone: null)
name: null,
phone: null
field(name: null),
field(phone: null)

41. Unidirectional Data Flow
field(name: null),
field(phone: null)
name: null,
phone: null
field(name: null),
field(phone: null)
name: null,
phone: null

42. Unidirectional Data Flow
field(name: null),
field(phone: null)
name: null,
phone: null
field(name: null),
field(phone: null)
name: null,
phone: null
name: “Joe”

43. Unidirectional Data Flow
field(name: null),
field(phone: null)
name: Joe,
phone: null
field(name: null),
field(phone: null)
name: null,
phone: null

44. Unidirectional Data Flow
field(name: null),
field(phone: null)
name: Joe,
phone: null
name: null,
phone: null
field(name: Joe),
field(phone: null)

45. Unidirectional Data Flow
field(name: null),
field(phone: null)
name: Joe,
phone: null
name: null,
phone: null
field(name: Joe),
field(phone: null)
field(name: Joe),
field(phone: null)

46. Unidirectional Data Flow
field(name: “Joe”),
field(phone: null)
name: Joe,
phone: null
name: null,
phone: null
field(name: Joe),
field(phone: null)

47. Unidirectional Data Flow
field(name: “Joe”),
field(phone: null)
name: Joe,
phone: null
name: null,
phone: 555
field(name: Joe),
field(phone: null)

48. Unidirectional Data Flow
field(name: “Joe”),
field(phone: null)
name: Joe,
phone: 555
name: null,
phone: 555
field(name: Joe),
field(phone: null)

49. Unidirectional Data Flow
field(name: “Joe”),
field(phone: null)
name: Joe,
phone: 555
name: null,
phone: 555
field(name: Joe),
field(phone: 555)

50. Unidirectional Data Flow
field(name: “Joe”),
field(phone: null)
name: Joe,
phone: 555
name: null,
phone: 555
field(name: Joe),
field(phone: 555)
field(name: Joe),
field(phone: 555)

51. Unidirectional Data Flow
field(name: “Joe”),
field(phone: “555”)
name: Joe,
phone: 555
name: null,
phone: 555
field(name: Joe),
field(phone: 555)

52. Is that it?

53. Is that it?
● Database changes
● Handling conflicts
● Different field types
● Sections, ordering
● Filtering
● Navigation
● Prefilled values
● Validations
● Persisting
● Confirmations, discarding changes
● ...

54. Configuration
Provider Reducer
Fields Builder
View

55. Store - key concepts
● Directed acyclic graph
● Single Store and Reducer implementations
● Unit tested the most
● Composition of simple dependencies unique per business type
● Dagger as a glue

56. Implementation

57. Implementation
class Store<FieldIdentifier>(
private val reducer: Reducer<FieldIdentifier>,
private val layoutProcessor: LayoutProcessor<FieldIdentifier>,
private val fieldsBuilder: FieldsBuilder<FieldIdentifier>,
//…
) {
fun start(initialState: State<FieldIdentifier>) {
//…
}
fun stop() {
//...
}
}

58. Implementation
class Store<FieldIdentifier>(
private val reducer: Reducer<FieldIdentifier>,
private val layoutProcessor: LayoutProcessor<FieldIdentifier>,
private val fieldsBuilder: FieldsBuilder<FieldIdentifier>,
//…
) {
fun start(initialState: State<FieldIdentifier>) {
//…
}
fun stop() {
//...
}
}

59. Implementation
class Store<FieldIdentifier>(
private val reducer: Reducer<FieldIdentifier>,
private val layoutProcessor: LayoutProcessor<FieldIdentifier>,
private val fieldsBuilder: FieldsBuilder<FieldIdentifier>,
//…
) {
fun start(initialState: State<FieldIdentifier>) {
//…
}
fun stop() {
//...
}
}

60. Implementation
class Reducer<FieldIdentifier> {
fun reduce(
fields: Observable<Set<FieldIdentifier>>,
userUpdates: Observable<Set<FieldIdentifier>>,
//...
): Observable<State<FieldIdentifier>>
}

61. Implementation
class Reducer<FieldIdentifier> {
fun reduce(
fields: Observable<Set<FieldIdentifier>>,
userUpdates: Observable<Set<FieldIdentifier>>,
//...
): Observable<State<FieldIdentifier>> {
return Observable
.merge(fields, userUpdated /* ... */)
.scan(initialState) { state, event ->
// Build new state
}
}
}

62. Implementation
sealed class ContactFieldIdentifier {
object Name : ContactFieldIdentifier()
object Phone : ContactFieldIdentifier()
sealed class ContactSectionIdentifier : ContactFieldIdentifier() {
object DefaultSection : ContactSectionIdentifier()
object ContactInformationSection : ContactSectionIdentifier()
}
}

63. Implementation
class ContactConfigurationProvider : ConfigurationProvider<ContactFieldIdentifier> {
fun getFields(): Observable<Set<ContactFieldIdentifier>>
//...
}
}
class ContactFieldValuesProvider : FieldValuesProvider<ContactFieldIdentifier> {
fun getFieldValues(fields: Set<ContactFieldIdentifier>):
Observable<Map<ContactFieldIdentifier, Value?>> {
//...
}
}
sealed class Value {
data class LongValue(val value: Long) : Value()
data class StringValue(val value: String) : Value()
//...
}

64. The graph

65. The graph - challenges
● Responsibilities
● Invalidations
● Side effects
● Unexpected requirements

66. The graph - challenges
● Clear flow
● Threading
● Debugging
● Extensibility

67. Cycles

68. View
Reducer
Configuration
Provider
Store
Fields Builder

69. View
Reducer
Configuration
Provider
Store
Display Values
Provider
Fields Builder

70. View
name: Joe,
company: 1
Store

71. View
name: Joe,
company: 1
name: Joe,
company: 1
Store

72. View
name: Joe,
company: 1
name: Joe,
company: 1
Store
name: Joe,
company: VW

73. View
name: Joe,
company: 1
name: Joe,
company: 1
Store
name: Joe,
company: VW
field(name: Joe),
field(company: {1, VW})

74. View
name: Joe,
company: 1
name: Joe,
company: 1
Store
name: Joe,
company: VW
field(name: Joe),
field(company: {1, VW})

75. View
name: Joe,
company: 1
name: Joe,
company: 1
Store
name: Joe,
company: VW
field(name: Joe),
field(company: 1)
Fallback:
company: null

76. View
name: Joe,
company: null
name: Joe,
company: 1
Store
name: Joe,
company: VW
field(name: Joe),
field(company: 1)
Fallback:
company: null

77. View
name: Joe,
company: null
name: Joe,
company: 1
Store
name: Joe,
company: null
field(name: Joe),
field(company: null)
Fallback:
company: null

78. View
name: Joe,
company: null
name: Joe,
company: 1
Store
name: Joe,
company: null
field(name: Joe),
field(company: null)
Fallback:
company: null

79. Cycles
● Limit or remove
● Rethink early
● Watch out for Rx Subjects

80. View effects

81. View effects
● Scroll to a field, show Snackbar, close the screen
StoreView
State
Actions

82. View effects
● Scroll to a field, show Snackbar, close the screen
● Option 1: Pass them in State
StoreView
State
Actions
field(name: Joe),
effect(scroll to top)

83. View effects
● Scroll to a field, show Snackbar, close the screen
● Option 1: Pass them in State
StoreView
State
Actions
field(name: Joe),
effect(null)

84. View effects
● Scroll to a field, show Snackbar, close the screen
● Option 1: Pass them in State
● Option 2: Separate them
StoreView
State
Actions
effect(scroll to top)

85. A few more things
● Data modeling
● Separation from Android
● Mapping data to views
● Development process
● Future improvements

86. A few more things
● Data modeling
● Separation from Android
● Mapping data to views
● Development process
● Future improvements

87. Data modeling
● Kotlin is a major improvement over Java
Data classes, sealed classes, extension functions, lambdas

88. Data modeling
● Kotlin is a major improvement over Java
Data classes, sealed classes, extension functions, lambdas
● Android Runtime improvements
“Creating garbage is OK. Use the types and objects you need.”
Nicolas Geoffray, Android Runtime Team

89. A few more things
● Data modeling
● Separation from Android
● Mapping data to views
● Development process
● Future improvements

90. Separation from Android
● Build wrapper classes with interfaces and clear API
● Abstraction increase
● Designing an API will be on you!
fun requestPermissions(
usage: RuntimePermissionsUsage
): Observable<RuntimePermissionsResult>

91. A few more things
● Data modeling
● Separation from Android
● Mapping data to views
● Development process
● Future improvements

92. Mapping data to views

93. Mapping data to views
Epoxy
● Abstraction over RecyclerView
● Kotlin support, many add ons
EpoxyTouchHelper
.initSwiping(recyclerView)
.leftAndRight()
.withTarget(MySwippableModel::class.java)
.andCallbacks(swipeCallback)

94. A few more things
● Data modeling
● Separation from Android
● Mapping data to views
● Development process
● Future improvements

95. Development process
● Significant entry level
● Proficiency in reactive programming

96. Development process
● Significant entry level
● Proficiency in reactive programming
● Duplication and copy-pasting
“Prefer duplication over the wrong abstraction”
Sandi Metz

97. A few more things
● Data modeling
● Separation from Android
● Mapping data to views
● Development process
● Future improvements

98. Future improvements
● Splitting the Store (~200 LOC)
● Reevaluating existing cyclic dependencies
● More type-safe modelling
● Developer experience
○ Initial setup
○ Unified naming
○ Tracking or rewinding state

99. Conclusion

100. Conclusion
Old New
Inheritance Composition
Callbacks RxJava-based blocks
Mutable state Unidirectional flow
Modeling with primitives Higher level abstractions with Kotlin
No separation from Android SDK Android SDK kept in isolated blocks
Lack of tests
Unit tests for the core logic, Espresso
for integrations

101. Questions?

102. Thanks!

103. Don’t Forget!
Fill out the Session
Survey in the App
End Zoom Recording
Leave the room better
than you found it!
#ZES19

104. #ZES19