Weegloo Docs - 跑步记录应用

跑步记录应用是一款移动应用，用手机随时记下跑过的距离、时间、配速、路线，只向登录的人展示他本人的记录。跑完后当天的记录会累积到列表里，其他人的记录彼此都看不到。

这个示例只展示一件事：网页服务里用过的同一套后端，移动应用照样使用。收纳记录、接纳会员、只让本人看到自己的记录，这些工作无论是网页还是应用都没有区别。因此这个示例也会从头到尾展示搭建那套后端（收纳记录的数据、会员登录、只看自己记录的权限）的全过程，并单独点出因为移动端而不同的两点：分发，以及把登录结果接回应用的连接。

要做什么

这次的示例不是服装店或博客，而是一款个人用跑步记录应用。界面定为三个。

登录界面： 用 Google 登录。
记录列表： 登录的人查看自己迄今为止留下的跑步记录，按最新顺序排列。
添加记录： 留下跑过的距离、时间、配速、路线、日期。

核心是「各自只看自己的记录」。登录的人只会收到自己留下的记录，看不到别人的记录。这个条件让后面需要会员登录和权限一起配合。

先做界面再连接

自己动手做这款应用分两步。先做出应用界面，然后把这些界面背后的部分交给 WEEGLOO。

1. 制作界面设计。 上面的界面是给 LLM 下达如下提示语得到的。用一行写清要做的是什么应用，加上界面清单、每个界面要放的内容、设计方向即可。

帮我设计一款跑步记录应用的界面。这是竖屏移动应用。

界面：

登录：应用介绍一行，加一个「用 Google 继续」按钮。

记录列表（主页）：总距离、跑步次数的概览，跑步记录卡片列表（日期、距离、时间、配速、路线缩略图），添加记录按钮。

添加记录：日期、距离、时间、配速、备注、路线照片的输入和保存。

风格干净且有活力，让距离、配速这类数值一眼可读。遵循移动 UI 惯例。

上面「要做什么」里的三个界面就是这段提示语得出的结果。此时还没有数据也没有登录，只是空有界面的状态。

2. 连接到 WEEGLOO。 把智能体接入 WEEGLOO（连接），然后这样说。

帮我连接 WEEGLOO。

不必长篇解释要做的是什么，智能体会查看这些界面，把界面背后需要的东西备齐。这种整体托付的流程与一句话连接相同。

界面背后 WEEGLOO 备齐的东西

一句「帮我连接」，智能体看着界面备齐的就是这四样。这是界面背后 WEEGLOO 承担的后端。

收纳跑步记录的数据框架（Content Type）。收纳距离、时间、配速、路线、日期这类项目。
Google 登录（ServiceLogin）。让应用用户自行注册并登录。
「只看自己记录」的权限。让登录的人只能读、写、删自己留下的记录。
自己记录的投递。只把某人自己的记录以列表形式送给登录的那个人。

这四样与用网页做同样的服务时所需的东西完全一致。分别处理每一块的方法，在加上注册和登录、划分权限、保存并取用数据里逐一讲解。如果想连路线地图图片或照片一起留下，还可以附上文件（Media）。

实际做出来的东西

下面是这个示例的 Stride Space 里实际做好的资源。这里看的不是如何逐一设置，而是「帮我连接」的结果给这款应用带来了什么。

收纳跑步记录的框架

第一样是收纳跑步记录的框架（Content Type）「Run」。一次跑步收纳的值按项目分成各个栏位。

项目	栏位种类	必填	收纳的值
`Date`	Date	必填	跑步的日期。在列表中也用作指代该记录的标题。
`Distance (km)`	Number	必填	跑过的距离（千米）。可以带小数。
`Duration (seconds)`	Integer	必填	花费的时间（以秒为单位）。界面上会像 `41:05` 这样按分、秒显示。
`Notes`	Long Text	可选	当天跑步的备注。
`Route photo`	Media	可选	路线地图或照片文件一张。

平均配速没有单独保存的栏位。只要有距离和时间就能算出，所以由应用随时计算并显示（添加记录界面里的「auto-calculated」）。

第二样是会员用 Google 登录的通道（ServiceLogin）。这个示例里把名称设为「Stride」，登录方式只开启了 Google 一种。新登录的人默认获得下面的「Runner」权限。登录结束后，其结果会经过把登录结果接回应用所说的中转页面回到应用。

「只看自己记录」的权限

第三样是会员获得的权限（ServiceUserRole）「Runner」。规则如下。

能做的事	适用范围
创建记录	任何登录的会员
读取记录	仅自己创建的
修改记录	仅自己创建的
删除记录	仅自己创建的

「读取」被限定为「仅自己创建的」，所以列表里各自只显示自己的记录。前面所说的四样中的第 3 项（权限）和第 4 项（投递），其实都从这一条规则里一起产生。每位会员能读到的记录都只是自己的，那也就是投递给他的那份列表。

记录与照片

第四样是每一条跑步记录（Content）和路线照片（Media）。这两者不是事先做好的，而是会员在应用里留下跑步时，以他的名义一条条生成。下面是实际留下的一条记录。前面「Run」框架里填上了值，并一起附有路线照片。

距离 42.195 是马拉松全程。时间以秒为单位收纳（这里是 3 小时 53 分的记录），应用里会像 3:53:00 这样显示。路线照片作为文件（Media）单独保存，记录里只收纳指向该文件的连接。「要做什么」里的列表、卡片，就是这样的记录累积多条后的样子。

与网页不同的两点

到这里为止都和网页一样。同一套后端由移动应用照样使用。因为是移动端而不同的只有两点。

分发：应用市场在 WEEGLOO 之外

网页服务可以把做好的东西用 Web Hosting 发布到互联网上（把网站发布到互联网），但把做好的移动应用送到人们手上（在应用市场上架）这件事，是在 WEEGLOO 之外完成的。WEEGLOO 承担的是应用界面背后的数据、会员、权限。

登录功能本身以与网页相同的方式接入。只是登录结束后把结果接回应用的连接与网页不同。登录结果只能回到网页地址，因此需要一个充当中转桥梁、把结果转交给应用的页面这一步。这个技术步骤在 Auth API 中讲解。

查看是否真的只显示自己的记录

这款应用的核心条件「各自只看自己的记录」确实得到遵守。下面是用两个不同账号打开同一款应用的主页。虽是同一款应用，总距离、跑步数、列表里出现的记录都不一样。

一个账号里只有 5km 一件，另一个账号里只有马拉松和 3km 两件。彼此的记录对方都看不到。Stride 里这三件全都收纳着（参见实际做出来的东西），但每位会员只会收到他自己留下的记录。这是前面「只看自己记录」的权限中把读取限定为「仅自己创建的」的结果。

接下来要做的事

加上注册和登录：讲解如何单独加上接纳自有会员的登录。
Auth API：讲解把登录结果接回应用的技术步骤。
划分权限：讲解如何设定权限，让会员只能处理自己的东西。
保存并取用数据：讲解如何做数据框架并填入内容。