GaR*_*eTa 8 mvp android design-patterns presenter ui-patterns
我正在使用MVP构建一个Android应用程序,我对此模式有一个疑问.
假设我有一个用于创建新人的屏幕.此屏幕将显示一个EditText用于插入名称,另一个用于ImageView显示所选照片图片等.这将导致一个View界面,由Fragment.它将与一个Presenter接口合作,由另一个类实现.
精细.
现在我有另一个功能:用于编辑现有人的屏幕.碰巧,View此功能与创建新人的功能相同.但是,Presenter情况有所不同.它将从db中加载现有人员以使用当前数据预先填充视图开始,单击"save"时对数据库的操作将是更新而不是插入.
因此,我认为这是MVP的一个示例,其中一个View与演示者的不同实现一起工作以实现不同的用例.
你认为这是一个正确的假设,或者你觉得不同的特点应该有不同的View和Presenter接口？
另外,如果你有一个共同的View和不同的Presenters,将View是共同的实现,还是会导致两个类实现相同的接口？在实践中,我看到两个选项.
只有一个Fragment实施View.根据用户是要创建新人还是更新现有人,Fragment应该接收并使用不同的Presenter.
有两个Fragment.每个人都会实例化一个不同的Presenter.使用组合或继承来避免在两个片段之间复制代码.
在这些情况下,您认为更好的做法是什么？
谢谢.
当您在 Android 上使用 MVP 模式创建类似 CRUD 的应用程序时，您会遇到这种情况。
您可以很容易地只拥有单个视图，只要您在课堂上很好地记录它为两个不同的演示者实现了“视图”，那么就“没问题”
我个人建议创建 2 个视图，一个用于“创建”，一个用于“编辑”（它们可能是相同的（目前），但将它们分开可以清楚地表明它们是不同的东西。）
您可以轻松地看到将来的情况（或此模式的另一个实现），您的“创建”和“编辑”视图实际上具有不同的 API。或者略有不同的视觉提示，例如一个按钮上标有“创建/添加”，另一个按钮上标有“更新”。
我个人会创建一个视图库/帮助器类，两个视图都可以从中提取逻辑。即使您创建了 2 个“视图”类，这也应该可以帮助您减少总体 LoC。这样做的好处是您可以轻松更改创建/编辑视图，而不必担心影响另一个视图。（我倾向于认为，当创建/编辑之间甚至存在“轻微”差异时，这两个视图文件会更容易维护）