使用Android构建动态表单的解决方案 [英] Solution to build dynamic forms with Android

问题描述

我实际上正在开发一个Android应用程序，我应该在该应用程序上基于JSON文档中包含的元数据显示动态表单.基本上，其工作方式(无详细信息)是JSON文档代表表单的结构:

I am actually developing an Android application on which I should display dynamic forms based on metadata contained inside JSON documents. Basically the way it works (without the details) is that a JSON document represent the structure of a form:

{
    "fields": [
        {
            "name": "fieldA",
            "type": "STRING",
            "minCharacters": 10,
            "maxCharacters": 100
        },
        {
            "name": "fieldB",
            "type": "INTEGER",
            "min": 10,
            "max": 100
        },
        {
            "name": "fieldC",
            "type": "BOOLEAN_CHECKBOX",
            "defaultValue": true
        }
        ...
    ],
    "name": "Form A"
}

当应用程序接收到这些JSON文档之一时，我实际上在做的是，它遍历每个字段并将其解析为适当的视图(EditText，Checkbox，自定义视图等)，并向该视图添加标签(以便能够轻松检索它)并将视图添加到LinearLayout.这是有关其实际工作方式的伪代码:

What I'm doing actually when the application receive one of those JSON documents is that it loop through each fields and parse it to the appropriate view (EditText, Checkbox, custom view, etc.), adding a tag to the view (to be able to retrieve it easily) and add the view to a LinearLayout. Here is a pseudo-code of how it is working actually:

//Add form title
linearLayout.addView(new TextView(form.name));
//Add form fields
for(Field field: form.fields) {
    View view;
    switch(field.type){
        case STRING: view = new EditText();
        ...
    }
    view.setTag(field.id);
    linearLayout.addView(view);
}

问题是大型表单(例如> 20个字段)需要膨胀很多视图，而UI线程也要承受很多痛苦.要考虑的另一点是，单个屏幕可能具有多种形式(一个接一个地垂直排列).

The issue with this is that with large forms (like >20 fields), it need to inflate lot of views and the UI thread suffer a lot. Another point to take into account is that a single screen may have multiple forms (one after another vertically sorted).

为避免UI线程过载，我想到了2种可能的解决方案:

To avoid overloading the UI thread I thought of 2 possible solutions:

1. 使用RecyclerView .
2. 使用 Litho by Facebook .

但是在考虑这两种解决方案时会遇到多个问题:

But multiple questions comes to me when considering these 2 solutions:

1. 使用Litho是一个很好的用例吗?还是使用RecyclerView就足够了?
2. 我的状态如何?如果我使用回收"模式，是否可以保持每个字段的状态(即使是在屏幕外)也可以保存表单而不丢失数据?
3. 如果我使用回收模式来显示一种形式，那么我将如何处理多种形式?我们可以嵌套RecyclerView吗?表单需要像在垂直RV内那样一个接一个地显示，但是如果表单本身是RV，我应该如何处理呢?

这是一个优良作法"问题，提供了实现我的目标的正确方法或正确方法之一，而不是需要通过代码示例等给出具体答案的情况.

This is more a "good practice" question and giving the right way or one of the right way of achieving my goal than a need of a specific answer with code example, etc.

在此感谢您的时间.

推荐答案

在设计移动应用程序时，我想解决以下问题:

When architecting for the mobile application I would like to address the following questions:

使用Litho是一个很好的用例吗?还是使用RecyclerView就足够了?

Is it a good use case to use Litho? Or using a RecyclerView is enough?

1. 视图是否已正确回收: 考虑到这对我们意味着什么，请考虑为每个屏幕创建40-50个视图，并且当用户移出该视图时，系统不应将所有视图标记为GC，而应将其放置在某种存档列表中，并且根据我们的要求，我们应该能够从中获取.

1. Are the views are being recycled properly: What does it mean to us is consider, creating 40-50 view per screen and as user moves out of the view, system should not mark all views for GC rather it should be inside some kind archived list and as we require it again we should be able to fetch from it.

我们为什么需要这样做:GC是最昂贵的操作，会导致应用程序呈现抖动，因此我们尝试通过不清除视图来将GC最小化.

为此，我想使用光刻，理由是在此处，因为您的要求似乎还有更多viewtypes 引用的计数

For this I would like to go with litho, justification is here as your requirement seems to have more of variable count of viewtypesreference

结论:光刻+ 1，RecyclerView +0

Conclusion: Litho +1, RecyclerView +0

我的状态如何?如果我使用回收"模式，是否可以保持每个字段的状态(即使是不在屏幕上)，也可以保存表单而不会丢失数据?

What about the state of my views? If I use a Recycling pattern, would I be able to keep the state of each of my fields (even those off-screen) and so being able to save the form without losing data?

1. 在RecyclerView中保存EditText内容这是一个组件，但应将相同的逻辑应用于复选框或<以及a href ="https://stackoverflow.com/a/29030776/2700586">单选按钮.或如在 状态维护 中进行光刻一样，请在此处

1. Saving EditText content in RecyclerView This is one the component but same logic should be appliced to checkbox or radiobutton as well. or as in state-maintenance for litho is here

结论:Litho + 1，RecyclerView +1都有特定的API来实现状态维护

Conclusion: Litho +1, RecyclerView +1 both has specific API's to achieve state maintenance

如果我使用回收模式来显示一种形式，那么我将如何处理多种形式?我们可以嵌套RecyclerView吗?表单需要像垂直RV一样一个接一个地显示，但是如果表单本身是RV，我应该如何处理呢?

If I use a Recycling pattern to display one form, how would I handle multiple forms? Can we have nested RecyclerView? Forms need to be displayed one after another like inside a vertical RV but if forms themselves are RV, how should I handle this?

1. 这必须通过用户体验和技术能力来解决: 根据IMHO的用户行为，我不鼓励嵌套的垂直滚动条，但是其他人也可以做到这一点轻松找到如何使用SO.最佳解决方案是在在此处
在Andriod或石印的回收者视图中进行水平滚动

1. This has to be addressed with user experience plus technical capability: As per user behaviour IMHO,I discourage the nested vertical scroll however others were able to achieve it you can easily find on how to in SO. Optimal solution would be to have horizontal scroll within either Andriod's or litho's recycler view as here

---

注意:如果您需要了解实施细节，请单独提出一个问题，我们很乐意为您提供帮助

---

NOTE: If you need to know implementation details, please raise it as separate question, I would be happy to help there

更新#1:

问题是大型表单(例如> 20个字段)需要膨胀很多视图，而UI线程也要承受很多痛苦.

The issue with this is that with large forms (like >20 fields), it need to inflate lot of views and the UI thread suffer a lot.

必须在后端执行UI创建/布局，而仅需在UI线程上完成添加到视图的操作.而litho可以内置来完成.但是，也可以实现本机回收器视图，但是您必须移出UI线程并定期发布到UI.

UI creation/layout has to be performed at the backend only adding to the view has to be done on UI thread. And litho does it in-built. However same can be achieved native recycler view as well but you have to move off the UI thread and post periodically to UI.

这篇关于使用Android构建动态表单的解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！