管理UI元素的Android设计模式

这个问题的答案将是一种设计模式，用于Android应用程序的开发，它简化了用户界面元素的管理方式，使得许多这样的元素可以集中管理，即使这些元素是从应用程序中的不同位置执行的

给定一个没有太多状态的小应用程序，可以在活动生命周期方法中管理UI元素。如果应用程序增长，并且可以基于主线程之外的进程更改状态，则进行更改的位置的数量会增加。这会降低应用程序的可维护性（在许多地方有状态更改代码）。我寻求一种设计模式，使其更清楚地了解在各种状态下UI会发生什么

我意识到，

SQLiteDatabase

和

SharedPreferences

等持久化工具是可用的，这可能是设计模式的一部分，但中央控制可以维护应用程序的状态，除了控制用户看到的内容和用户能够做的事情外，还有一个目标。

有一种称为“MVP”（Model/View/Presenter）的模式已用于此目的。提供在Android框架中编程时MVP优于MVC三元组的原因

从中获取一个队列，我们看到此模式背后的想法是将模型和视图与演示者分开

• 演示者- 与MVC模式一样，演示者从模型中获取数据并将其返回到视图。此外，它还决定与视图交互时发生的情况

• 视图- 这将是一项活动，并将创建演示者。它会倾听活动，但不会自己做任何事情，而是要求演示者采取行动

• 模型- 我们希望显示的数据的提供者

---

这里有一个MVP应用程序运行的例子

这个问题可能是一个更广泛的问题。你应该看看MVP模式，有一个“状态”，想象一个应用程序可以登录或不登录，可以连接到数据库1或不连接到数据库2或不连接，同时提供各种服务（和相关的UI控件），取决于这五个州中哪一个与当前州相匹配。也许答案是MVP？实现可能是一个挑战，因为用户界面和数据访问在Android活动中自然是紧密耦合的。现在将所有这些逻辑放到某个服务层中，并使用演示者访问该层。完全可以测试。@DavidMedenjak，我不能接受这个问题太过宽泛，因为它要求一个在复杂的Android应用程序中工作的设计模式来简化视图管理。所以在重写了一个有点失控的应用程序后，我会说这是可行的。有很多我称之为垂直重复的东西，其中一层似乎没有增加多少价值，但更像是我承认写的东西