API应该在API响应中发回UI层文本/数据，以便在旧的android / ios应用程序版本中随时允许更改吗？

Question

各种android / ios屏幕的标题，各种表单控件的标签是否应该在android / ios应用程序中进行硬编码，或者应该从API响应中提取这些数据？

页面/页面的大部分都有标题。在带有文本框/组合框的表单中，我们也为每个控件都有标签。这些UI信息是应该硬编码还是从API中提取？

这里几乎没有问题：

1. 在Android / ios应用程序上拥有所有这些硬编码的优点：干净且轻量级的API数据。 API将仅包含数据部分，而不包含标题，标签等用户界面元素。这样可以节省带宽并使API快速运行。
2. 在Android / ios应用程序上拥有所有这些硬编码的缺点：如果我们想在将来更改这些标题，标签，我们只能在较新版本上执行此操作。之前的所有应用版本将继续仅显示旧标题/标签。如果我们从API中提取了这些数据，我们可以随时在所有版本中更改这些数据。

哪种方法正确？或者，如果标题/标签在未来可以更改并且需要针对所有应用程序版本进行更改，我们是否应根据这一事实做出决定，如果是这种情况，那么它应该在API中，否则它们可能是硬编码的？ 应用程序是否可以使用firebase获取此类信息并在以前的应用程序版本中进行更改？

Answer 1

从API调用中填充所有UI元素可能不是一个非常好的用户体验，至少没有一些硬编码默认值允许用户最初在应用程序中导航而无需等待API调用来检索信息。此外，如果您尝试使用此服务器端UI设计创建应用程序，您可能希望主要使用Web组件，甚至可能将html提供给应用程序，因为内容之间可能存在不匹配（即标签的文本，按钮和文本字段）和UI元素本身。例如，设想一个分段控件，最初设计为只容纳两个选项（＆＃34; Home＆＃34;＆＃34; Work＆＃34;）然后在列表中添加一个额外的文本选项（＆＃ 34; Home，＆＃34;＆＃34; Work＆＃34;＆＃34; Gym＆＃34;）。