-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Mercury bus e-ink screens #2257
Conversation
In places we were previously checking that the screen type was GL E-ink, or a combination of that and the vendor being Mercury, we now only check the vendor.
3a5b203
to
efd5897
Compare
@@ -271,7 +271,10 @@ defmodule Screens.V2.WidgetInstance.Alert do | |||
end | |||
end | |||
|
|||
def audio_valid_candidate?(%__MODULE__{screen: %Screen{app_id: :gl_eink_v2}}), do: true | |||
def audio_valid_candidate?(%__MODULE__{screen: %Screen{app_id: app_id}}) | |||
when app_id in ~w[bus_eink_v2 gl_eink_v2]a, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering about this conditional. Are there places we use this widget on audio-supporting screens where we specifically don't want it to be included in audio readouts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we first introduced audio for this widget when we started converting e-inks to Mercury. My guess is that we wanted to limit the scope of the change to just Mercury screens so we added this guard to exclude Bus Shelter. In hindsight, it seems overly cautious because bus alerts should read the same as GL. Problem is we never made a task to review the alert audio on Bus Shelters. It might be ok to just leave out the guard and ship alert audio to two screens at once. I feel confident in that but would understand leaving it to a future task.
@@ -135,7 +135,7 @@ defmodule Screens.V2.WidgetInstance.SubwayStatus do | |||
def audio_sort_key(_instance), do: [2] | |||
|
|||
def audio_valid_candidate?(%{screen: %Screen{app_params: %app{}}}) | |||
when app in [PreFare, GlEink], | |||
when app in [BusEink, GlEink, PreFare], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same wondering here as above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is likely done for the same reason as above. Something to think about here is whether it's not a bad experience to hear subway audio at a bus stop. That's the only thing I could see being an issue and even that is reaching.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good. We'll definitely need to communicate with Ana that these screens need to have vendor
populated for them to work properly.
We'll soon be setting up our first Bus E-ink screen provided by Mercury. This requires a couple of changes:
gl_eink
, we should instead key on thevendor
field.