Now that the new Wear OS guidelines are in effect,...

# compose-wear

[Venthorus]

Now that the new Wear OS guidelines are in effect, I'm getting a reject because the scroll bar does not appear on entering a screen with a list (it only appears on scroll). That is a good requirement, however how do I make sure that this is the case when using ScalingLazyColumn (inside a Scaffold)? I don't see an option in PositionIndicator either.

[yschimke]

We will look into this internally, since PositionIndicator doesn't support this, you shouldn't be getting rejected for it.

[yschimke]

You can file an appeal, if you drop me the app package I can follow up after that.

[Venthorus]

Alright, we will update the app in the next few hours (there were also other reasons for the reject). If we receive a reject again, I will come back to you.

[yschimke]

The quality guidelines have been updated
https://developer.android.com/docs/quality-guidelines/wear-app-quality

Display the scroll bar when the user interacts with a scrollable view.

[Venthorus]

@yschimke We have received a reject with only one issue found left, which is WO-V8. The email we received mentions that the scroll bar should display when entering a scrollable view. The reviewer doesn't seem to know that this requirement is no longer a thing.
I have written an appeal. The application ID is de.sevend.the_good_miles .

[yschimke]

I'm moving house, if you still have issue tomorrow, I'll escalate internally.

[Venthorus]

@yschimke So my appeal got rejected with a more detailed note from the reviewer that it doesn't show the scroll indicator when scrolling with the rotary input. And I have to admit that the person is right and I agree that this should be the case, however I implemented it exactly the way the "Rotary input on Compose" document describes it. If I use animateScrollBy instead of scrollBy it shows the scroll indicator, however the scroll doesn't behave correctly then. Do you possibly know a workaround for this?

I really like the strict requirements as it will lead to more consistency, but I would expect that Compose handles most it out of the box. The documentation pretends that something like rotary input is optional and leads to better UX when in fact it is simply a requirement now.

[yschimke]

A ticket has been raised internally.

[Venthorus]

@yschimke So we finally got through the review after I let the position indicator appear whenever the user enters a scrollable screen. I looked into the settings app of WearOS to realize that letting the indicator appear is also needed when using the rotary input, after resuming an app or returning to a scrollable screen. Seems like the reviewer didn't get the memo, so we got rejected until it fully worked.

I used a combination of LaunchedEffect, animateScrollBy, awaitFrame and lifecycle handling to make it possible; however it adds a lot of boilerplate to each scrollable screen and it doesn't feel "right", because it should be the job of the position indicator to do the correct thing.

I also had to make each scrollable screen long enough, because the position indicator somehow doesn't show up if scrolled to the top and the content isn't long enough.

[yschimke]

Yeah - this review isn't working as intended. I'm escalating slightly to see if we can fix this before others cargo cult what you had to do.

[Thomas]

My app updates also keep getting rejected because of this. How did you make the PositionIndicator appear without scrolling?

[yschimke]

Rather than copying the approach above "combination of LaunchedEffect, animateScrollBy, awaitFrame and lifecycle handling", I'd personally suggest using the support in Horologist for this. It should delete a lot of code, and implement the current requirements correctly. It doesn't show a position indicator without scrolling, as that shouldn't be a requirement.

[yschimke]

Example https://github.com/android/wear-os-samples/blob/2bd2418b4e8101c948ddaba9d88f6d2cad[…]le/composeadvanced/presentation/ui/watchlist/WatchListScreen.kt

[Thomas]

Thanks Yuri, I will give it a try!

[Nat Strangerweather]

Hello, I'm having the same rejection problem but it is because my position indicator is not showing at all. I have been using Horologist, but I am obviously not doing it right:

fun DescriptionScreen(
    id: Long,
    navController: NavController,
    columnState: ScalingLazyColumnState = ScalingLazyColumnDefaults.belowTimeText().create()
) {
    val scalingLazyListState = rememberScalingLazyListState()
    Scaffold(
        vignette = { Vignette(vignettePosition = VignettePosition.TopAndBottom) },
        positionIndicator = { PositionIndicator(scalingLazyListState = scalingLazyListState) },
        timeText = { TimeText() }
    ) {
        ScalingLazyColumn(
            columnState = columnState,
            modifier = Modifier
                .fillMaxWidth()
                .padding(top = 20.dp)
        ) {}

[Nat Strangerweather]

Any ideas of how I can solve this problem?

[yschimke]

I think where we got to internally.

Wear Compose doesn't support showing on entry. This is no longer a requirement.

There appears to be a bug at least in the latest Wear Compose alpha, that it won't show on only slightly scrollable screens.

For other cases, what you have above should work for touch scrolling. And you can add the rotaryWithScroll modifier to make it work for RSB.

You should also use the scrollAway modifier on TimeText

[Nat Strangerweather]

Thanks for this. What do you mean by "only slightly screens"?

[yschimke]

Missing a scrollable word

[yschimke]

Screens that are like 30dp too tall

[yschimke]

Horologist has an overload taking ScalingLazyColumnState, that also handles the RSB. So you can drop your .create() call, also for PositionIndicator.

[Nat Strangerweather]

"Your app does not display the scroll bar when the user enters a scrollable view". This is still happening. I have sent an appeal but it is rather annoying how much time is wasted because of these things.

[yschimke]

Yep, this was removed.

[yschimke]

Thanks for persevering. Feedback is being given, docs updated. Hopefully a one off for you.

[Dustin]

hi, I am also getting a rejection because of scrollbars. my app is a very straightforward implementation of horologist. anyone have advice for appealing

[Dustin]

I have to say, the wear review process is incredibly frustrating. it’s so random

[Thomas]

Are you using staged rollouts? Because Google seems to reject existing versions as well even when there is a newer (fixed) version with a staged rollout.

[Dustin]

no, actually I think the issue is the “slightly scrollable” bug yuri was talking about