Yuvaraj
04/20/2024, 12:05 AMRudy Sulley
05/15/2024, 5:40 PMsealed class Screens {
@Serializable
data object Home : Screens()
@Serializable
data object About : Screens()
}
fun NavGraphBuilder.aboutScreen(
modifier: Modifier = Modifier,
onBackButtonClick: () -> Unit,
) {
composable<Screens.About> {
AboutScreen(
modifier = modifier,
onBackButtonClick = onBackButtonClick,
)
}
}
Or would you throw each route definition in separate files, probably where the composable is defined or within their respective packages?
Slack ConversationRaji
06/05/2024, 1:15 PMraghunandan
06/14/2024, 3:01 AMChristopher Mederos
06/20/2024, 5:54 AMCompositionLocal
since units are usually 4-6 children deep in my composable hierarchy. I'm thinking of storing the setting in my cache (realm), making it available in a viewmodel, collecting the state and making it available via CompositionLocalProvider just above my NavHost. Then I'd pass the viewmodel method reference to update the setting values to my "settings screen" composable.
Is that reasonable? Is that easier than passing a UnitsPreference arg a bunch of times? Thanks!raghunandan
07/05/2024, 2:38 AMSuraj Shukla
07/13/2024, 5:20 PMJoost Klitsie
07/26/2024, 10:30 AManlex N
08/21/2024, 9:44 AManlex N
09/22/2024, 2:41 AManlex N
09/29/2024, 1:13 PMDaniel Okanin
10/08/2024, 5:34 PMModel
data from the server and use a transformer in the ViewModel
to create a UiModel
specific to the view.
I’m wondering: when I need to display an icon based on the UiModel
, should I include the drawable resource (@DrawableRes
) directly in the UiModel
class? Or, should I include a type field and map the drawable resource in the view layer itself?
Which approach is considered best practice? If I go with the first approach, the view stays very simple since it only needs to display the data. However, I’m unsure if this is the best solution for maintainability or flexibilityVarun Sethi
10/10/2024, 5:12 AMVarun Sethi
10/10/2024, 5:14 AMRaju Kulo
10/17/2024, 11:38 AMKashismails
10/28/2024, 7:06 PMPeter
11/05/2024, 10:52 AMLuke
11/26/2024, 2:48 PMinterface MyRepository {
val state: StateFlow<State>
sealed interface State {
data class Foo(...): State
data class Bar(...): State
}
}
Now, I need to run some code each time the state changes while the application runs. What is the best way to set a collector on the state and test that the collector works properly?Mohammed Akram Hussain
11/29/2024, 12:11 PM@HiltViewModel
class HomeViewModel @Inject constructor(
repository: Repository
) : ViewModel() {
val uiState = repository.data
.mapLatest { result ->
when (result) {
is Result.Success -> UiState.Success(result)
is Result.Error -> UiState.Error(result.exception.message ?: "Unknown error")
}
}.stateIn(
scope = viewModelScope,
started = SharingStarted.WhileSubscribed(5.seconds.inWholeMilliseconds),
initialValue = UiState.Loading
)
sealed class UiState {
data object Loading : UiState()
data class Success(val data: Data) : UiState()
data class Error(val message: String) : UiState()
}
}
class Repository @Inject constructor(
private val api: Api
) {
private val _data = MutableStateFlow<Result<Response>?>(null)
val data = _data.asStateFlow().filterNotNull()
suspend fun getData() {
try {
val response = api.getDataFromNetwork()
if (response.isSuccessful) {
val body = response.body()
if (body != null) {
_data.emit(Result.Success(body))
}
} else {
val exception = Exception("Server Error: ${response.code()}")
_data.emit(Result.Error(exception))
}
} catch (e: Exception) {
_data.emit(Result.Error(e))
}
}
}
The above is the approach suggest in the architecture samples HERE but I don't understand how it'll work for network call where caching or offline support is not required. The two main problems I am facing with this approach for the above are:
1. How should I trigger the initial data load when the screen opens?
2. What's the best way to implement a refresh mechanism (like pull-to-refresh)?
Is this Flow-based approach overkill for simple network calls without caching? Should I consider a different approach? Would appreciate any guidance or best practices!Evan Holtrop
01/02/2025, 4:47 PMDaniel Okanin
01/09/2025, 4:54 PMSu Van Ho
01/17/2025, 7:39 AMthe domain layer depends on the data layer
Abhishek Sharma
01/24/2025, 1:35 AM:feature:home
and :feature:reviews
) that need a use case combining data from two domain modules (:domain:books
and :domain:reviews
). For example, Feature A
and Feature B
both require data that comes from a composition of BooksUseCase
(from :domain:books
) and ReviewsUseCase
(from :domain:reviews
).
A few approaches come to mind:
1. Create a new module (e.g., :domain:books-reviews
) to house the combined use case logic. However, this introduces horizontal dependency, as the new domain module depends on both :domain:books
and :domain:reviews
, potentially violating clean architecture principles of vertical dependency.
2. Place the combined logic in a common domain module (:domain:common
). But in a large app, this could lead to bloating and tightly coupling unrelated shared logic in a single module.
3. Move the composition logic to the feature layers and directly invoke the relevant use cases from the domain modules. However, this risks duplicating logic across multiple features if the combination logic is reused.
What is the best way to handle this scenario while maintaining modularity, scalability, and adherence to clean architecture principles? Is it acceptable to have a cross-domain dependency in such cases, or should the logic live elsewhere (e.g., feature layer or backend)? Any recommendations or best practices for managing such cross-domain use cases in large apps?Matti MK
02/12/2025, 1:58 PMStore
(https://github.com/MobileNativeFoundation/Store) would be a valid option, as well as using the NetworkBoundResource
pattern.
Has anyone used Store
, NetworkBoundResource
or another approach?mattinger
02/12/2025, 7:38 PMRaj Paliwal
02/28/2025, 5:40 PMOTHER_REASON
• Description: ScreenOffCheckKill 26m3s4ms (26.33344%) threshold 2.0%
The issue occurs when a*fter screen turns off, app in background.*
The description in the exit logs suggests ScreenOffCheckKill, but I couldn’t find any official documentation explaining this behavior.
• What exactly does ScreenOffCheckKill
mean, and why does it happen?
• Is this a system-level restriction or a configurable setting?
• How can I prevent my app from getting killed due to this reason?
• Any pointers to official documentation or similar cases would be highly appreciated.
Thanks in advance for any insights!KotlinLeaner
03/07/2025, 6:25 PMFilippo De Pretto
03/23/2025, 12:31 AMNovo Dimaporo
04/23/2025, 5:44 AM@Dao
interface EntityDao {
@Transaction
fun transaction(block: () -> Unit) {
block()
}
}
And expose this to the repository layer then the usecase.Usman
05/06/2025, 6:05 AM