feat(Android): show live data indicator on predictions #612
Conversation
| @@ -60,57 +60,65 @@ fun formatTime(time: Instant): String = | |||
| format.format(time.toLocalDateTime(TimeZone.currentSystemDefault()).toJavaLocalDateTime()) | |||
|
|
|||
| @Composable | |||
| fun UpcomingTripView(state: UpcomingTripViewState) { | |||
| fun UpcomingTripView(state: UpcomingTripViewState, hideRealtimeIndicators: Boolean = false) { | |||
There was a problem hiding this comment.
suggestion: maybe worth a test that the indicator image is included when expected
There was a problem hiding this comment.
Since the icon has no content description, I'm not aware of a way for us to test that it exists without using test tags, and I don't want to either add a test tag to the image unconditionally or add an extra flag to add the test tag that's supposed to be only ever true in testing.
There was a problem hiding this comment.
I don't mind the use of test tags as a last resort when there are no other good ways to test.
There was a problem hiding this comment.
Added some checks for the realtime indicators to the UpcomingTripViewTest.
| if (!hideIndicator) { | ||
| Image( | ||
| painterResource(R.drawable.live_data), | ||
| contentDescription = null, |
There was a problem hiding this comment.
question(non-blocking): should there be a content description here, like "live"? This seems like an important symbol to convey to Talk Back users, though acknowledge that this is matching the existing iOS behavior
There was a problem hiding this comment.
There shouldn't, because the accessibility label for the entire nearby transit row gets read at once, and on iOS we annotate scheduled times with "scheduled" instead of annotating live times with "live".
There was a problem hiding this comment.
I think those annotations predate the decision to add the "live" indicator rather than the scheduled indicator. We should probably go back and update those, I can make a ticket for it.
Summary
Ticket: 🤖 | Nearby | Realtime indicator
I tried making this a custom modifier like it is on iOS, but Android modifiers can't (as far as I was able to tell) just wrap the entire component with another Composable.
iOS
android
Testing
Manually verified (since testing the presence of semantically-invisible UI elements in Android is a bit difficult) that the icons show correctly and look the same way they do on iOS.