1. Username EditText
2. Email EditText
3. Password EditText
4. Confirm Password EditText
5. “Proceed” Button

Task:

Implement effective interactive validation for input data.

Solution:

Serial input of text data by a user can be considered as a data stream and processed with the help of related instruments — Asynchronous Stream SDKs.

There are some benefits of processing data as Asynchronous Stream:

• Absence of callback hell
• Ability to combine last emitted items without adding last_Item variable
• Most Asynchronous Stream SDKs have rich API for dealing with a wide range of tasks of combining data streams.

The task can be implemented with the help of the next Asynchronous Stream SDKs:

• RxJava
• Reactor
• Reactive Streams
• etc.

In this article, the Kotlinx.coroutines.flow SDK will be considered as an instrument to accomplish the task.

In most cases, an Android component that receives text data entered by a user is EditText. The changes in text data input can be tracked via EditText.addTextChangedListener callback. Since the EditText.addTextChangedListener callback doesn’t have a built-in ability to be converted to Kotlinx.coroutines.flow stream there is a need to implement such conversion.

To convert the EditText.addTextChangedListener callback into the asynchronous stream, Flow and Channel extensions of kotlinx.coroutines library can be used. Here is an example:

fun EditText.asFlow(resetTarget : () -> Unit): Flow<EditText> {

return Channel<EditText>(capacity = Channel.UNLIMITED).also { channel -> addTextChangedListener(object : TextWatcher {

override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {

}

override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {

s?.let {

this@asFlow.clearError()

resetTarget();

channel.offer(this@asFlow)
 }
}

override fun afterTextChanged(s: Editable?) {

}

})

}.receiveAsFlow()

}

The example above shows how Channel.offer is used as a bridge between EditText.addTextChangedListener callback and Flow since the last one uses suspend methods and requires CoroutineScoupe. Channel.offer buffers values that come from EditText.addTextChangedListener and converts them to Flow with the help of Channel.receiveAsFlow.

After the above preparation, the input of an EditText can be converted to Flow, and all the inputs of EditText fields from the condition section can be received as:

val resetProceedButton = {proceedButton.isEnabled = false}

val usernameFlow = userNameEditText.asFlow(resetProceedButton)

.filter(EditText::isValidSize)

.debounce(300)

.filter(EditText::isUniqueUsername)

val emailFlow = emailEditText.asFlow(resetButton)

.filter(EditText::isValidEmail)

val password1Flow = password1EditText.asFlow(resetButton)

.filter(EditText::isValidSize)

val password2Flow = password2EditText.asFlow(resetButton)

.filter(EditText::isValidSize)

.filter is used to prevent the user input from going to the next validation steps if the current is not passed.

Example of the function that is passed to .filter:

suspend fun EditText.isValidSize():Boolean {

if (text.length < 5) {

error = "Invalid Size"

return false

}

return true

}

And

suspend fun EditText.isUniqueUsername():Boolean  {

delay(1000)

if (text.toString() == "111111") { // Here should be call to backend API with proper check of uniqueness of

error = "Invalid username"  // a username

return false

}

return true

}

A good example of how Asynchronous Streams can help to track the latest emitted item is operator .combine.

val passwordsAreEqualFlow = password1Flow.combine(password2Flow, this::comparePasswords)

private suspend fun comparePasswords(edit1: EditText, edit2: EditText) : Boolean {

if (edit2.text.toString() == edit1.text.toString()) {

edit1.error = null

edit2.error = null

return true

}

edit1.error = "Passwords are not equal"

edit2.error = "Passwords are not equal"

return false

}

Whenever a user types in the edit1 EditText, comparePasswords will receive the edit2 EditText with its latest state.

Since Flow is cold observable, it requires the terminal operator to start the processing of items. The .collect operator is one of such terminal operators.

coroutineContextOnStart.launch {

combine(usernameFlow, emailFlow, passwordsAreEqualFlow, ::enableProceedButton)

.onEach { proceedButton.isEnabled = it }

.collect()

}

Issues:

In case of replacing .filter with more common .onEach + throw Exception + .retryWhen the operator .combine forgets last value of all flows except the current active. It happens because of the recreation of the flows after an exception is thrown at any point of the stream despite the presence of .catch operator.

Conclusion:

Kotlinx.coroutines.flow provides an excellent and perspective API for dealing with asynchronous streams of data.

But as the @ExperimentalCoroutinesApi annotation says it is mostly experimental. It seems that RxJava (RxKotlin) is still an excellent way to handle asynchronously emitted items.