Updated for Jetpack Compose dev15 and Android Studio 4.2 Canary 5 #35
Conversation
There was a problem hiding this comment.
Hey, amazing job of converting these.
I have left a couple of comments, mostly referring to build files.
Regarding unchecked type checks, seems like for now we cannot avoid them all, as we are converting between more broad BackStack<Any> to very specific BackStack<T>. I think in these cases it is fine anyway, as we know that types are consistent based on the logic of the lib :)
app-lifelike/src/main/java/com/example/lifelike/composable/loggedin/AlbumList.kt
Outdated
Show resolved
Hide resolved
router/src/main/java/com/github/zsoltk/compose/router/Router.kt
Outdated
Show resolved
Hide resolved
app-lifelike/src/main/java/com/example/lifelike/composable/LoggedOut.kt
Outdated
Show resolved
Hide resolved
|
Okay, I have made all the changes and squashed into a single commit. I will open a separate PR for the CI stuff after this is merged and I can rebase. Let me know if theres anything else you need me to change. 😊 |
|
@madhavajay amazing, thanks 👐 . I still see a new yaml file in the diff, can you recheck if you have removed everything? |
- Updated to kotlin_version = "1.4-M3" - Cleaned up dependencies and build.gradle files - Removed redundant Column inside ScrollableColumn - Optimised imports and updated androidx.ui.foundation.TextFieldValue - foundation.TextFieldValue is now input.TextFieldValue
|
@ShikaSD Sorry, I missed that when I squashed the commits. It's gone now, so I think we're ready for merge. Thanks for the patience. |
|
@madhavajay @ShikaSD thank you both! |
I got everything working, however I can't figure out the correct way to handle the three unchecked casts properly.
I left the @Suppress("UNCHECKED_CAST") commented near each one.
I guess this is something to do with Covariance / Contravariance etc, but I dont know enough about how to solve it. Seems theres a List and a Map with BackStack<*>. Would one solution be to have some kind of known Routing interface or class which is subclassed or implemented so that the type and its sub/super are known?
I would be interested in knowing how this should be fixed so that I can understand this whole <*> thing in Kotlin.