Hello everyone :wave: I think I've spent ~30 hour...
# compose
o
Hello everyone 👋 I think I've spent ~30 hours now over 3 days trying to figure out what is going on with this insanely weird compose issue. I was hoping I could share the nightmare I've found myself in and see if anyone would mind playing rubber duck here to help me get more ideas on how to tackle the problem. At a high level, here's what's going on. I work in 3 different android projects. Project 1 and Project 2 are working properly with compose and I'm migrating more and more of UI to compose and everything works flawlessly. I just added the exact same compose dependencies to project 3 and found that what I am seeing in Compose Preview is broken when I run the code in an emulator or real device. I stashed all my compose work and just made a simple screen that has a Column with verticalScroll that just loops 40 times and renders a Text component. When I deploy this code, the column DOES NOT scroll. I take this EXACT same code and copy it to Project 1 and 2, deploy, and I'm able to scroll the Column. Other things don't work as well such as clipping a Custom Shape etc but I'm positive all the issues are related. So I am just focusing on getting the simple Column with vertical scrolling to work. What. The. $@#!. Right? I'll post some of my notes/findings/additional info in thread for anyone curious or who may have insight. I sincerely apologize for the long message in this channel and really have tried avoiding bothering anyone with this as I'm trying to figure it out but I really am losing my mind at this point...
Some notes about Project 3 where compose code is not working properly:. • MinSdk = 23 (6.0) • Target SDK = 30 • Compile SDK = 30 • Android Gradle plugin 7.0.2 • Gradler wrapper 7.0.2 • Kotlin 1.5.21 • compose 1.0.1 • This is a multi module project (app, data, domain) • All build.gradle are Kotlin DSL • There is a buildSrc module as well where all version and dependencies are located
What I've tried: • Copied the exact composable for rending the scrollable column into different android projects and it works fine • I've created a new compose project from studio and added every single dependency that project 3 uses, and the scrollable column code works fine for this new compose project. The difference here is the Gradle scripts for all projects where the compose code works fine are all groovy, but I don't it's possible for that to make a difference, since project 3 has been using Kotlin DSL from the moment it was build and there hasn't been any other issues • Checked that all other projects are targeting the same versions of android, I checked dependencies and made sure project 3 was using same version of dependencies and still the issue persists • I've checked the jdk version being used which is pointing to the embedded jdk version with studio, which seems correct
Copy code
@Composable
fun ScrollBoxes() {
    Column(
        modifier = Modifier
            .background(Color.LightGray)
            .size(100.dp)
            .verticalScroll(rememberScrollState())
    ) {
        repeat(40) {
            Text("Item $it", modifier = Modifier.padding(2.dp))
        }
    }
}
Here is the compose code that does not work (doesn't scroll) when added to project 3
d
I would try adding
.fillMaxSize()
modifier to the outermost column.
The intent being to actually limit the size (viewport) of the Column to the screen, rather than grow it. Otherwise the Column view is not constrained to the screen dimensions and so is growing off-screen to accommodate to its content... with no need to scroll.
Oh, I see you already sized it at
100.dp
🤔
👍 1
u
All projects are being deployed to the same device or emulator? I.e. Project 1 & 2 work on device A, Project 3 breaks on the same device A?
Could you think of any differences in the host of your composable (Activity/Fragment)? Different styles/themes?
a
I don't think any of the factors you listed affects whether the column scrolls. It looks like the touch events are intercepted/consumed by something else. I think what you need to check is whether your activity or other views in the activity process touch events incorrectly.
To verify, you can add a breakpoint on AndroidComposeView.dispatchTouchEvent() to see if ComposeView can receive touch events normally.
👍 1
o
Yes @uli , all deployed to the same emulator and devices. In all projects I created the exact same base empty activity overriding onCreate and setting setContent { ScrollBoxes() } without wrapping in any theme so it's consistent in all projects.
@Albert Chang great idea ! I'll try setting some breakpoints and debugging and seeing if that's even getting hit
As I mentioned above though, I literally did a copy/paste job of the barebones activity in all projects, so there is no differences there. And I'm not wrapping the composable in any theme either
Okay added break points and dispatchTouchEvent is definitely getting triggered. I am more and more convinced that something in the build.gradle setup is causing issues and isn't playing nice with compose. At this point I'm going to do the brute force check and create a new project and start copying over pieces one by one and keep building and deploying this scrollable column composable until I see what is causing the scrolling functionality to break... Pray for me.
u
Good luck
z
have you tried wiping your gradle + AS caches?
o
Yup! @Zach Klippenstein (he/him) [MOD] One of the 193736 things I tried haha. I know this sounds really odd, but I've narrowed this down to either all my Gradle files written in Kotlin DSL and some features are possibly deprecated and/or not working properly, OR there's one specific plugin or dependency that is breaking compose somehow. (Maybe something is bringing in Kotlin 1.5.3 which I think is not compatible with compose, but I don't see that in the resolved dependency tree.... What I've started to do this evening is I've created a basic compose app through studio, and copied over the composable that doesn't work in the original project. I rewrote the Gradle scripts from Kotlin to groovy, and am starting to copy over modules, files, code little by little and continuously redeploying the compose code to the emulator till I find the change that is breaking it. Will def share my findings once I find the issue in case someone else goes through this nightmare....
💪 1
d
@OG The struggle is real... I can't help but want to wish you strength on your toolchain quest! Sure many of us have been through similar.
❤️ 1
o
My god. I solved it... after 5 gruesome days of digging into this issue..... One line of code.
android:hardwareAccelerated="false"
in AndroidManifest. I don't even know why I have this disabled, must have been by accident since the default is
true
if target API is >= 14. Removing that flag fixes ALL the compose issues in the project (scrolling, clipping, custom shapes, background, etc) Is this expected? @Zach Klippenstein (he/him) [MOD]
👍 3
Also, thank you to everyone who responded @darkmoon_uk @uli @Albert Chang If I ever have the pleasure of meeting you all in person one day (perhaps at a Google I/O event or something else), 🍻 🍕 🍦 ON ME. Whatever you want! 🙂
u
Wow. Thanks for finding this one. You probably saved some people some time here 🙂
👍 2
z
I have no idea if Compose is even theoretically supposed to work with software rendering, but i think it is generally built assuming hardware rendering is being used and a lot of performance decisions are based on that (e.g.
graphicsLayer
is basically pointless in software rendering afaik).
o
Yeah that makes sense, and aligns with what I was seeing since I was using graphics layer to set a custom shape and clip. And it was basically not doing anything with this hardware rendering set to false. The part that doesn't add up though is why scrolling behavior is completely broken with software rendering. Im assuming under the hood, the verticalScroll modifier is just translating views by their y coordinate in both vertical directions using some offset etc and that doesn't seem to me like it should require hardware rendering?
z
I’m not sure tbh, but doesn’t really seem worth investigating to me since there are plenty of reasons why it’s a bad idea regardless.
o
Yeah agreed... Just super unlucky on my part I guess as I never thought to check the manifest to find something like that when trying to figure out what is causing compose to "break". Anyway thanks for all the help!
z
Seems like we could at least warn you. Filed
❤️ 1
👍 1
o
Thanks @Zach Klippenstein (he/him) [MOD]! That was nice of you to open that 🙏👍👌🙌