Assessing Type Safe Navigation Compose in Android Development
Project Setup
As per the documentation, in libs.versions.toml
[version]
navigationCompose = "2.8.0-alpha08"
kotlinSerializaton = "1.6.3"
[libraries]
androidx-navigation = { group = "androidx.navigation", name = "navigation-compose", version.ref="navigationCompose"}
kotlinx-serialization = { group = "org.jetbrains.kotlinx", name = "kotlinx-serializati
on-json", version.ref = "kotlinSerializaton"}app’s build.gradle.kts
plugins {
alias(libs.plugins.android.application)
alias(libs.plugins.jetbrains.kotlin.android)
kotlin("plugin.serialization") version "1.9.24"
}
dependencies {
implementation(libs.androidx.navigation)
implementation(libs.kotlinx.serialization)
}Here, the OnBoardingScreen needs to know the current status of terms & condition and isHelpShown value to understand the user’s preferences. OnBoardInfo is served by API and the same has been bound with graph.
package com.piappstudio.piauth.data
import kotlinx.serialization.Serializable
@Serializable
data class OnBoardInfo(val isTermsAccepted:Boolean? = null,
val isHelpShown:Boolean? = false)@Composable
fun SetupNavigation() {
val navController = rememberNavController()
NavHost(navController = navController, startDestination = Splash) {
composable<Splash> {
SplashScreen {
navController.navigate(OnBoardInfo())
}
}
composable<OnBoardInfo> {
val onBoardInfo = it.toRoute<OnBoardInfo>()
OnBoardingScreen(onBoardInfo)
}
composable<Profile> {
LoginScreen()
}
}
}During execution, the system throws an exception as shown above.
Int, boolean does not allow nullable values
The realm of Android development is ever-evolving, with each new feature promising to revolutionize the way we build apps. Among these innovations, Type Safe Navigation Compose has garnered significant attention. Touted as a game-changer, it aims to streamline navigation and enhance type safety in Jetpack Compose applications. However, as developers dive deeper into its implementation, cracks in the facade begin to surface.
The hype surrounding Type Safe Navigation Compose is palpable, with promises of smoother navigation and improved compile-time safety. Yet, in practice, the reality often falls short of expectations. One glaring issue is the handling of server responses, particularly concerning default values for INT or BOOLEAN data types. This oversight not only complicates the integration of server data but also runs counter to established best practices.
Imagine a scenario where a server response lacks default values for certain data types. Suddenly, what should be a straightforward process becomes a tangled web of workarounds and compromises. As developers, we’re left grappling with the fallout, frantically patching up the cracks in our codebase.
But let’s not despair just yet. While Type Safe Navigation Compose may be bleeding, it’s not beyond salvation. By acknowledging these challenges and working collaboratively to address them, we can steer this ship back on course.
Suggested Solutions:
Instead of iterating through each parameter in the data class and converting it into an optional or default parameter string, why not convert the whole thing to a string using “GSON” and pass it as an optional parameter?
This way, during the receiving time, we could easily convert it back to the original object using the same “GSON” `fromJson` function. In this way, we could avoid unnecessary NavType definitions.
Suggested Route:
classname?args = {“name”:”boobalan”, “department”:”IT”}
Conclusion
In conclusion, Type Safe Navigation Compose holds immense promise for the Android ecosystem. However, its success hinges not only on the brilliance of its design but also on our collective efforts to refine and enhance its capabilities. Let’s roll up our sleeves, confront the challenges head-on, and chart a course towards a brighter, more navigable future for Android development.
