Lets say I have following business layer function:...

# android

[Lilly]

Lets say I have following business layer function:

fun someFunction(): Flow<Pair<Int, SomeStateType>>

Would you
1. define a data class and create a new object on every change (this might happen 100x). Disadvantage: object creation on every change, advantage: state is coupled to its function
2. expose 2 observable StateFlows. Disadvantage: pollutes interface API, advantage: no object creation on every change
Is there any guidance about this or is this an issue of preference?

[Javier]

can you put code samples?

[Colton Idle]

I'd probably go with option 1 unless there's a measurable perf hit.

[Adam Powell]

If you have two different flows they can't each emit a new value in one atomic change. If this matters to you then you don't have a choice, you need to use a single flow.

[Lilly]

I have only one flow, but the values I would like to emit are of different type, e.g.

fun someFunction(): Flow<Pair<Int, SomeStateType>> = flow {
  emit(SomeStateType.LOADING)  

  repeat(100) { i ->
    emit(i)
  }

  emit(SomeStateType.COMPLETE)
}

or 

val intValue: MutableStateFlow<Int> // has to be a Channel
val valueState: MutableStateFlow<SomeStateType>

fun someFunction(): Unit {
  valueState.value = SomeStateType.LOADING

  repeat(100) { i ->
    intValue.value = i
  }

}

ok while writing this sample I noticed two things:
1. in the latter case I would have to define a hot Channel to ensure my int values are not conflated.
2. I could let the caller decide when operation is done and introduce SomeStateType there. Then I just need fun someFunction(): Flow<Int>
Sometimes just writing about the problem helps to make it more clear .

[Javier]

Why not a sealed class?

[Lilly]

@Javier As Return Type of the function or for the SomeStateType value?

[Erick Sumargo]

I would kill to have a stateless design in every possible way. Sometimes the consideration of the impact of new object creation is often overestimated. https://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

If your code practice is right, the old object will be deallocated and gracefully GC-ed.

[Lilly]

Thanks for your input @Erick Sumargo thats a good guidance. I share your opinion that more state leads to more problems