在Android中實現模型 - 視圖 - 演示者的困難

模型 - 視圖 - 演示者（MVP）是GUI應用程序中衆所周知的設計模式。對於Android來說，在普通的Java模塊中實現業務邏輯有助於在不需要Android模擬器的情況下進行測試。因爲特殊要求的Android應用程序的GUI實現Android上的圖案在Android中實現模型 - 視圖 - 演示者的困難

不過，我有困難：

的活動可以在任何時候（來電被破壞，用戶按下home鍵， ...），並且在重新創建時應該與它離開時的狀態完全相同。這與大多數其他GUI應用程序不同。
活動可以經歷許多生命週期狀態。在這種情況下，活動的UI不應該被修改。例如，如果某些數據在後臺加載，如果它處於暫停狀態，則無法將其傳遞到MVP（活動）的View部分。再次，這是一個不尋常的要求。

我已閱讀博文MVP for Android並查看了example source code。我試圖通過使用MVP模式實現的最終目標是能夠使用轉譯程序j2objc將所有業務邏輯轉換爲Objective-C，以便在iOS上實現相同的應用程序時可以重用業務邏輯。

有沒有人成功實現了Android的MVP模式，在這種情況下，我錯過了什麼？

來源

2014-07-11 foens

我在想什麼：如果你的業務邏輯模塊是普通的java而不需要'Context'，爲什麼你的'Activity'生命週期很重要？換句話說，爲什麼這些特殊的GUI需求是一個問題？ – Blacklight

如果MVP的'View'部分可能在某些時候沒有更新（當它暫停時），那麼'Presenter'還是'Model'不知道？而且'Model'不應該被創建，以便它可以在稍後恢復？ – foens

有人可能會爭辯說，活動負責管理生命週期並根據需要設置/暫停/拆除演示者。主持人對你的系統依賴UI框架的怪癖並不聰明。 – dcow

我建議在不涉及Activity的情況下實現MVP組件，或許從概念上考慮哪些對Android和GWT都有用。使用帶有模擬View接口的測試驅動開發創建組件，添加測試，直到完全實現並驗證業務邏輯。 TDD有助於保持組件的API精簡（爲什麼編寫不需要的東西的測試？），這使得移植組件變得更容易。

您描述的活動需求可以概括爲與平臺無關：組件應該是可序列化的（小的，不是特定的Java序列化），並且需要接受生命週期狀態事件。這些也可以使用模擬系統功能進行全面測試。在您完成這一步驟時，您可能會注意到很少有活動要求必須與Android相關，並且可能在其他平臺上很有用。避免創建大量的服務API;以支持序列化，例如，所有需要的是存儲/加載方法，而不是像Parcel API。我發現在白板上向另一位開發人員描述這樣的服務API是發現不必要的絨毛的好方法。

接下來，將組件移植到Android，可能通過創建委託給組件的Activity併爲模擬接口提供Android特定的實現類。它應該都是第一次「正常工作」，但實際上，有些要求可能已經錯過了，所以將它們添加到與平臺無關的部分並重復。

當您準備好移植到iOS時，重新實現以前模擬的接口。如果這些接口是精簡的，可能會更容易直接在Objective-C中創建它們，導入由j2objc生成的協議頭。例如，j2objc的NSDictionaryMap類實現了帶有NSDictionary實現的java.util.Map - 無需編寫和翻譯Java版本，因爲它僅使用iOS API。

來源

2014-07-11 16:59:41 tball

嗨，謝謝你的想法。我不完全確定'組件'是什麼。你在談論主持人嗎？在你的文章中，我感覺你實際上描述了稱爲[Presenter-First]的實現過程（http://atomicobject.com/files/PresenterFirstAgile2006.pdf），我在這裏是否正確？視圖應該是界面（沒有平臺細節），這些應該由Android上的Activity來實現。我覺得實現保存/加載過程需要付出相當大的努力，這也是重新實現Android娛樂過程的有效手段。 – foens

我打電話給組合的MVP「單位」一個組件，有沒有更好的名字？所有可用的術語似乎超載。關於Presenter-First，你是對的，謝謝你的鏈接，因爲我沒有看過那篇論文。保存/加載應該從特定於平臺的歸檔服務（如Parcel或Java的序列化）外部調用 - 組件應該處理的是它自己的存儲/恢復。通過提供服務，特定於Android的代碼將使用Android應用程序通常使用的相同代碼。 – tball

我發現MVP變體Android是圍繞在應用程序中隔離業務邏輯的正確方向邁出的一步。但是，如果您希望實現更好的問題分離，並且由此創建更多可重用的域/業務邏輯，則我建議使用Presenter First pattern（您在評論中簡要提及自己）。除了減少耦合之外，它還可以很好地適用於TDD，並允許您單元測試所有業務邏輯。

我最近通過Presenter爲Android開啓了一個GitHub回購協議。由於Android架構的複雜性，實現模式並非易事。視圖往往比普通的Presenter First應用程序看起來「更胖」，主要是因爲您提到自己時的活動生命週期和其他古怪。我盡了最大努力將平臺的業務邏輯分離出來，但絕對有改進的空間。你可以找到例子：

http://github.com/olerass/presenter-first-android

也許你可以使用一些想法從那裏？或者甚至更好地貢獻一些你自己的。

來源

2016-01-14 22:53:30 olerass

在Android中實現模型 - 視圖 - 演示者的困難

回答

相關問題