Ctrip Technical Salon: Mobile Development Practices and Performance Optimization – MVC, MVP and the Extended MVCPI Architecture

The author, Zhao Weilin, shares his experience from Ctrip's hotel division where rapid feature changes and a massive codebase demand a clear separation of responsibilities among components.

He first reviews the classic MVC pattern, showing a typical Android activity that directly accesses model data and UI widgets, which quickly leads to a bulky Activity acting as both controller and view.

To address MVC's shortcomings, the article moves to MVP. The official Android MVP reference defines an IHotelView interface with getters for UI elements, an IHotelPresenter to bind the view and model, and a concrete HotelPresenter that updates the UI. Sample code snippets illustrate these interfaces and their implementations.

Despite MVP's benefits, the author points out practical issues: loss of Context when showing a Toast , lifecycle mismatches, memory leaks, and long callback chains. A problematic presenter example is shown where a background thread tries to display a toast without a valid context.

He proposes an improved solution that injects a Fragment into the presenter to obtain a context, and adds a callback interface for the activity to handle actions, but notes that fragment lifecycle changes can still cause null‑pointer exceptions.

Finally, Ctrip's extended MVCPI architecture is introduced. It defines a weakly‑typed IView interface that only lists view IDs, a Presenter that binds these IDs to actual widgets, and a new Interactor component that centralises all UI interaction listeners, eliminating long callback chains. The full flow—initialising the interactor, creating the presenter, setting the view, and binding data—is demonstrated with concise code blocks.

The conclusion emphasises that MVC remains viable, MVP adds useful decoupling, and the MVCPI extension further improves maintainability, scalability and testability for complex Android applications.