状态机谁来操控？

[rccoder]

状态机放前端还是后端

前端：

• 相对较为简单，各自维护自己的状态
• 对于动态改版不好做，没有服务端直接

后端：

• 前端只是请求同一个 API，接收相同格式的数据做出响应
• 后端维护不同请求的状态？如何维护？
• 状态机？

思考

## 每次进去，获取今天新闻
// 前端
{
  command: 'todayNews',
  options: {},
}
// 后端
jwt 判断用户，判断 command，查询，发送

{
   status: 200,
   data: {
     type: 'MultiText',
     content: [
       {
         img: '',
         title: '', // 此种情况需要前端绑定时间，走 id Activity，请求参数
         id: ''
       }
     ]
   }
}

## 快递

## 前端
{
  command: 'common', 
  options: {
    data: 'xxxxx'
  }
}

## 后端
能直接判断出，查询，发东西

发查快递，然后这样返回 
{
  nextCommand: 'xxx',
  data: 'xxx'
}

服务端数据格式

{
  status: 200,
  data: {
    nextCommand: '', // 下次的命令, 没有就是空。用于对话交互，
    type: 'SingleText',
    content: 'xxxxx',
  }
}

{
  command: 'common' // 默认 common，直接指定，或者从 nextCommand 获取。先后顺序： 指定 -> nextCommand -> common。nextCommand 每次请求都刷新屌。
  options: {
  }
}

例子

// request 首页获取东西
{
  command: 'todayNews',
  options: {}
}

// reponse 判断是 todayNews 直接返回

{
  nextCommnd: '',
  type: 'MultiText',
  content: [{}, {}]
}

// request 直接输入了快递号

{
  command: 'common',
  optopns: {
    data: '123456677'
  }
}

// reponse 匹配到是全数字，知道是快递，返回

{
  nextCommand: '',
  type: 'xx',
  content: ''
}

// request 点了查饭卡

{
  command: 'common',
  options: {
    data: '差饭卡'
  }
}

// response 判断 data 知道是查饭卡

{
  nextCommond: 'getFoodCard',
  type: 'xx',
  content "xx" // 给几个可选项？
}

// 一中情况 request 选择了1，

{
  command: ''getFoodCard,
  options:{
    data: 1
  }
}

// 另外一种情况： 
输了其他的，也没有什么耦合

这样不用单独记录每个的状态，由这种 command 的标记直接到相应状态，转移用 nextCommand

主动推送怎么实现？

• 单独 API 隔一段时直接请求看有没有？

合理性？

[rccoder]

单独设计退出状态

为避免特殊情况发生，下面的 scrollview 加退出有无必要？

哪种情况会陷入状态循环？