The final phase of the Dynamic Routes feature is to implement full support for multiple simultaneous routes. We already have servers-side support for multiple routes as long as only one is active at any given time, which didn’t require any client updates, but to support multiple simultaneous routes, we’ll need to update the routes API to send a consistent color name that clients can use to color-code each route on the map. We’ll also have the server return a human-readable display name for each route. This will require updates both to the server and to all clients.
The API change will take the form of two additional key-value pairs in each route object that’s returned in the server’s JSON response. Here’s an example of a JSON route object with this new key-value pair:
(The values for the "schedule" and "coordinates" keys are omitted for brevity. The Dynamic Routes feature will require no changes to their respective formats.)
One key aspect of this design is that the server specifies color names but not precise color values. This is intentional: it lets each client determine the precise color value that’s most appropriate for its local context. For instance, a client might decide to use a darker shade of red when the local OS is in dark mode than it would use in light mode.
For now, the list of valid color names is as follows:
"red"
"orange"
"yellow"
"green"
"blue"
"purple"
"pink"
"gray"
We may alter the list of valid color names in the future. In the meantime, all clients should fully support all of the above color names so that new routes can safely use any of those colors purely via server-side updates without requiring any changes to the clients.
We need to develop and to ship this feature quickly because there will indeed be multiple simultaneous routes this fall. The server-side implementation will involve incrementing the API version number, so we must roll out the client updates at the same time as we deploy the server updates to avoid significant downtime.
The final phase of the Dynamic Routes feature is to implement full support for multiple simultaneous routes. We already have servers-side support for multiple routes as long as only one is active at any given time, which didn’t require any client updates, but to support multiple simultaneous routes, we’ll need to update the routes API to send a consistent color name that clients can use to color-code each route on the map. We’ll also have the server return a human-readable display name for each route. This will require updates both to the server and to all clients.
The API change will take the form of two additional key-value pairs in each route object that’s returned in the server’s JSON response. Here’s an example of a JSON route object with this new key-value pair:
(The values for the
"schedule"and"coordinates"keys are omitted for brevity. The Dynamic Routes feature will require no changes to their respective formats.)One key aspect of this design is that the server specifies color names but not precise color values. This is intentional: it lets each client determine the precise color value that’s most appropriate for its local context. For instance, a client might decide to use a darker shade of red when the local OS is in dark mode than it would use in light mode.
For now, the list of valid color names is as follows:
"red""orange""yellow""green""blue""purple""pink""gray"We may alter the list of valid color names in the future. In the meantime, all clients should fully support all of the above color names so that new routes can safely use any of those colors purely via server-side updates without requiring any changes to the clients.
We need to develop and to ship this feature quickly because there will indeed be multiple simultaneous routes this fall. The server-side implementation will involve incrementing the API version number, so we must roll out the client updates at the same time as we deploy the server updates to avoid significant downtime.