工作流程

http://wiki.jikexueyuan.com/project/notes/images/MVP.png" alt="MVP.png" />

• view通常會持有presenter的引用；
• presenter持有view和model的引用；
• model應該包括數(shù)據(jù)和對數(shù)據(jù)的獲取或者修改操作；

具體來說

http://wiki.jikexueyuan.com/project/notes/images/MVP1.png" alt="MVP1.png" />

• MVP之間應該盡量解耦，可以通過定義接口來實現(xiàn)，相互持有的是接口引用；
• view應該盡可能聽從presenter的指令，而不是自己控制，如：接受presenter的showLoading指令之后才顯示正在加載；
• 與用戶的交互由view負責，顯示的細節(jié)由view負責；

MVP in Android(Mosby)

• 使用場景：單一的UI單元，例如fragment，或者一個ViewGroup，原則是這部分UI由一個presenter獨立負責，不必相互干擾；
• Acticity、Fragment更應該是view，而不是presenter；
• core模塊集成了Butterknife、FragmentArgs、Icepick等開源庫；
• MVP模塊，定義了MvpPresenter，MvpActivity、MvpFragment類，作為presenter，view的基類；
• MvpPresenter是一個接口，有一個MvpBasePresenter實現(xiàn)，使用WeakReference保存view的引用，所以presenter（子類）要調用view的接口時，需要調用isViewAttached()檢查view是否有效，調用getView()獲取其引用；
• MvpLceView，模板化loading-content-error流程；
• ViewState模塊：保存view（并非android中的View）的狀態(tài)，處理屏幕旋轉、view（fragment、activity）重新創(chuàng)建時的狀態(tài)恢復；
• 還有針對dagger、retrofit、rx、testing等的模塊；

一些建議

• Don’t “over-architect”
  In fact refactoring is a vital part of development, you simply can’t avoid it (but you can try to minimize the number of refactoring). Start with doing the simple thing and afterwards refactor and make it more extensible as app and requirements grow.
• Use inheritance wisely
  正確利用繼承，基類擁有基本特點，子類增加新特性；避免“子類爆炸”；
• Don’t see MVP as an MVC variant
  http://wiki.jikexueyuan.com/project/notes/images/mvp-controller.png" alt="mvp-controller.png" />
  Controller負責控制View(UI)和用戶交互時應該執(zhí)行的動作（調用Presenter的哪個方法）；當被Presenter調用顯示方法時，如何顯示（動效、數(shù)據(jù)使用方式）；
• Take separation of Model, View and Presenter serious
  寫代碼的時候，認真思考每一行代碼的功能應該屬于哪個模塊，目前的位置是否合適？
  • View負責UI顯示，以及對UI、用戶的響應
  • Model負責數(shù)據(jù)獲取、存儲、處理
  • Presenter負責配合/連接兩者
• Presentation Model
  • 當UI顯示對于model的需求與數(shù)據(jù)源不一致時：最好的辦法是加一層wrapper；其次是為model加一些方法，產生需要的域；最差的是為model加上這些域；
• Navigation is a UI thing
  不同界面之間的跳轉應該由view負責
• onActivityResult() and MVP
  當result僅僅用于顯示時，無需涉及presenter；當需要額外處理時，例如圖片處理、上傳等，則需要放到presenter中去；
• MVP and EventBus - A match made in heaven
  EventBus常被用于業(yè)務邏輯事件、UI更新事件（fragment之間通信）
  • 前者presenter負責接收event，控制view顯示；
  • 后者有一種常見做法：Activity實現(xiàn)一個listener接口，讓fragment持有該接口引用（attach時賦值），使用該接口進行通信；然而使用EventBus更合適，解耦更徹底；
• Optimistic propagation
  用戶的操作，首先給其成功的反饋，然后在后臺進行處理，失敗后給出失敗的提示，并撤銷成功的反饋（顯示），這種做法對于用戶體驗或許更佳；
  如何看待內存泄漏：避免activity/fragment的泄漏，但對于presenter，如果希望操作執(zhí)行完之后再被GC，則subscriber/runnable持有的presenter引用，可以認為是合理的；
• MVP scales
  MVP的V可以是整個屏幕顯示的內容，也可以是屏幕上的某個模塊顯示的內容；
• Not every View needs MVP
  靜態(tài)的頁面并不需要MVP
• Only display one Model per MVP view
  一個V顯示多個M會為代碼增加復雜性，尤其是當需要保存ViewState時；合理的做法是將V拆分為獨立的V，每個V只負責顯示一個M；V可以是fragment，也可以是View/ViewGroup；例子： http://wiki.jikexueyuan.com/project/notes/images/menu-refactored.jpg" alt="menu-refactored.jpg" />
• Android Services
  Service顯然屬于業(yè)務邏輯部分，由presenter與之通信是合理的；
• Use LCE only if you have LCE Views
  LCE還包含loadData，setData，如果沒有這兩個語義，就不要使用LceView，因為對接口的空實現(xiàn)，有違接口的規(guī)范；
• Writing custom ViewStates
  當需要保存view的狀態(tài)時，定義好ViewState，并在view內維護、檢查；
• Testing custom ViewState
  View和ViewState都是純Java代碼，可以使用Java的單元測試方法進行測試；
• ViewState variants
  有可能View既顯示了數(shù)據(jù)，又在進行刷新操作，但是ViewState始終只會處于一個狀態(tài)，通常的做法是為原來的狀態(tài)再加一層修飾，加以區(qū)分；也可以定義一個新的ViewState；
• Not every UI representation is a ViewState
  例如：顯示空內容，并不是新狀態(tài)，而是show content，只不過content為空；
• Not every View needs a ViewState
  mosby的ViewState通過SavedInstance保存，限制大小為1MB；另外保存的數(shù)據(jù)有可能是過時的，需要注意；
• Avoid Fragments on the backstack and child fragments
  fragment的生命周期中可能會有一些問題，所以盡量避免將fragment放入back stack，或者子fragment；
• Mosby supports MVP for ViewGroups
• Mosby provides Delegates
  好處：
  • 可以把MVP模式應用到mosby未包含的類中，例如DialogFragment；甚至是第三方庫；
  • 實現(xiàn)自定義的Delegate，可以改變默認Delegate的行為；