我是马里全栈网络和移动开发人员培训（训练营）的学习者。 我的最终项目是制作一个通用的调查应用程序，即在 Angular、ionic 或 flutter 和 springboot 中收集、分析和扩散数据我正在寻求帮助，因为在这个领域没有太多的例子可以遵循。 提前谢谢你，我希望你能陪我完成这个对我来说非常重要的项目。
我正在对 figma 进行研究，我希望就如何构建离线收集应用程序以及如何集成分析 api 并使其更容易在应用程序本身中分发获得一些建议。 我为仪表板使用角度框架，为移动应用程序使用 flutter，为创建 api 使用 springboot，这 3 个框架是验证我的培训所必需的。
【问题讨论】：
标签： android angular flutter spring-boot survey
有趣的是，这正合我意，因为我最近使用 Ionic 设计并制作了一个通用数据收集（调查）应用程序。
简要概述：
CouchDB 在服务器上运行用于存储，而 Pouch 是它的移动版本，它很可爱，可以处理我们的设备端离线存储。它们具有开箱即用的保持同步的能力，并且老实说让我们的生活更容易处理数据并大大缩短了我们的开发时间。
因此，API 实际上非常少；它作为应用程序进行身份验证、检查分配的新调查以及促进应用程序相关连接字符串和信用以用于 Couch/Pouch DB 连接的一种方式。
整个app的大概流程是：
检查新调查 -> 接收 url/creds -> 设置通过详细信息连接的新 Pouch DB -> 开始同步 -> 进行调查（将更新写入 Pouch） -> 同步 -> 完成。
Ionic 碰巧有一个令人愉快的 Pouch 插件，所以它们很好地结合在一起并且工作得很好。
所以，这就是所有的技术和一般的东西 - 这里没有人会直接告诉你如何设置每个应用程序并让它们作为一个整体系统进行交流和工作；那是一切照旧的事情，也是您开始工作所需的东西（也许是在帮助下，是的），但没有交给您。
我一直觉得很有趣的关键部分是组织您的数据，以便它能够是通用的。我喜欢将 ER 图和 JSON 结构等组合在一起。
这就像数独之类的某种组织游戏。
Couch 是一个基于 (JSON) 文档的数据库，JSON 非常适合应用程序之间的传输，并且易于阅读和扩展等。我的意思是我们选择了 JSON，而且有争议的是，您可能会出色地。
首先，您需要考虑数据的结构，以及涉及的层次结构。
去 x 地方，进行 y 次不同的调查，也许每个调查都有 z 次问题。
在我们的例子中，我们实际上需要各种分组；例如整个城镇，分解成街道，每个场所都在街道上，然后是客户希望我们在这些场所进行的任意数量的调查（有些调查可能会或可能不会在每个场所进行！）。
这只是我们自己的数据收集分组，更不用说客户可能想要的方式了。因此，首先，考虑如何使其尽可能通用，以迎合塑造（并因此呈现）导致问题本身的数据给进行调查的用户。
我想如果你没有人四处做调查，而是有一个收银台，静态设备类型的安排正在进行，那么这种事情可能与你无关，但我会忽略它，因为一个正确设计的系统应该两者都能做到！
一旦您弄清楚您希望如何以适当灵活的方式安排您的数据，您就需要弄清楚您的调查本身将采用什么结构，以及问题。
对于您的调查需要包含哪些元数据，有各种各样的考虑因素——可以回答的频率（可能有理由在给定位置多次检查问题集，而不仅仅是一次）；可能有一些并非每个地方都满足的调查条件，可能有针对用户的基本说明，忽略所有基础知识，如标题、描述等。
在您提出问题之前，所有这一切！ Aww yiss，一个有趣的项目，毫无疑问。
你有各种各样的问题类型要处理！文本输入、数字、滑块、评分（我们作弊并暂时使用滑块进行评分）、图像捕获、单选框选择、复选框、下拉选择、多选....
我们拥有的是一系列设定的输入（我们可以随着时间的推移而增长），问题只是表示预期的输入类型——每个问题都只是一个输入，对吧？你叫什么名字，你的年龄，你如何推荐这项服务等等。
但是您的问题类型本身可能有某种设置/选项供考虑。一项调查需要 0-5 的评分，另一项调查需要 1-10 的评分。一项调查希望收集一张图像，另一项调查希望收集最多 5 张图像。
以及可用的答案选项！谁是您的 ISP？提供一个列表以供选择...
因此，连同问题的详细信息（文本），您需要让它知道预期的输入是什么，以及该输入适用的选项。
哦，法律，然后是问题流程！我们已经对确定要在屏幕上显示的项目的问题“引擎”进行了几次迭代。
我的意思是，你可以只显示所有问题，对吗？但有时人们想要一个流程——如果你同意，就问这组，如果你说不，就问这组。不只是在屏幕上显示所有这些。
那只是是和否——你可能有许多分支要根据答案来遵循。
我们的第一个版本是简单的指针 - 正在回答的问题导致下一个问题，或者一个可用的答案导致另一个。当您用完“下一个”问题时，您就完成了调查。
那很好；但我们得到的反馈是，将所有问题都交给手头实际上是件好事，因为它们实际上可能不会按顺序填写 - 因为在四处走动时，他们会与人进行更多对话而不是临床访谈（他们没有时间！）所以更有机地得到答案。
这导致了另一个版本来处理这类事情。
然后我们切换到分支上的反向工作；我们有“先决条件问题”风格，而不是“下一个问题”风格。而不是“问题 1 已回答，转到 2”，现在是“仅当问题 1 已回答时才显示问题 2”。
这使我们能够单独设置调查，以便我们现在可以选择显示所有问题 - 或所有给定分支 - 或者保持顺序，这是前向解析版本不允许的。
哦，不要忘记处理“必填”问题 - 当您有条件地出示问题时，这是一种额外的乐趣。
然后您需要保存这些答案——我们所有的输入组件都会返回 JSON 字符串。不管它是什么，它都已转换为 JSON，以便我们可以保存它、发送它并稍后解析它以获取输出。因为我们知道用于回答它的输入（和设置）是什么，所以我们知道如何解析它并再次阅读它。
所以，老实说，不确定这有多大帮助，但如果没有为您提供模式、代码、示例等文字块，我会为您做一半，我认为这可能是我要回答的问题的限制这个原本模糊的问题。
不过，我确实希望它有所帮助！
【讨论】：