by Alex Hartwell and Tim Miko

作者:Alex HartwellTim Miko

Across the past couple of years, different mobile app teams across Lyft have been moving to Server Driven UI (SDUI) for three main reasons:


  • To deal with business complexity
  • 处理业务的复杂性
  • To increase release velocity
  • 为了提高释放速度
  • To be more flexible in how we staff and build features
  • 以更灵活的方式配备人员和建立功能

This post is about Lyft Bikes and Scooters’ journey to SDUI, why we’ve gone down this path, and what’s worked well for us.


(If you don’t care about the background story that led to us thinking about SDUI, you can skip down to The Core Primitives of SDUI for the nitty gritty tech discussion.)


A Quick History of Lyft Bikes and Scooters at Lyft


Lyft scooter

In 2018, Lyft had just launched dockless scooters (scooters that can start and end a ride without dedicated docking stations) in Denver. We sent what were simply database models directly to the mobile clients (we’ll call these “business models” from here on out) and used ride, vehicle, and hardware properties to drive the UI. Things were simple and they were good.

2018年,Lyft刚刚在丹佛推出了无桩滑板车(无需专用停靠站即可开始和结束骑行的滑板车)。我们把简单的数据库模型直接发送到移动客户端(我们从这里开始称这些为 "商业模式"),并使用乘坐、车辆和硬件属性来驱动用户界面。事情很简单,也很好。

Simple mapping of ride state to UI elements

There was a simple mapping of ride state to UI elements (pseudo code)


Later that year, we got to work adding dockless electric bikes to the app. Things started to get a little more complex. The ride flow of scooters and bikes was similar, but not exactly the same. The mobile app needed to know what the user was riding so we could change the UI.


We added an enum with two cases: “electric scooter” and “electric bike”. We could swap out elements in UI and feature sets with that enum. The enum allowed us to abstract all the product differences behind a single value ...


首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.130.1. UTC+08:00, 2024-07-24 18:03
浙ICP备14020137号-1 $访客地图$