一、最簡單：無界面
package study.android;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class HelloWorld extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
printf("hello,world\n");
}
}
二、復雜一點點：有界面、有邏輯
- Code Block：把UI和邏輯間放在一起，你在同一個地方可以同時維護UI和邏輯：
package study.android;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class HelloWorld extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
TextView tv = new TextView(this);
tv.setText("Hello, World!");
setContentView(tv);
}
}
- Code Behind：把UI和邏輯各自分開，你可以讓UI和邏輯各自做好各自的事情：
package study.android;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class HelloWorld extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.hello);
}
}
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:orientation="vertical" >
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="hello" />
</LinearLayout>
真正的分歧：
是按邏輯和UI劃分地管理，還是按單界面的事務進行劃分地管理
三、再復雜一點點：界面和邏輯很多，而且數據量也變大了
App從處理一件事務發展到了要處理許多事務，各事務間有包含、順序、主次等等的關系，變得越來越復雜。因為數據與邏輯龐大了，所以數據與邏輯就分離了，然后事件和業務分離了。最終分化成如下原子:
- 界面
- 數據
- 事件
- 業務
并形成了不同的設計思想：
1. Model-View-Controller（Model-View-Controller）
MVC的一般流程是這樣的：View（界面）觸發事件--》Controller（業務）處理了業務，然后觸發了數據更新--》Controller更新了Model的數據--》Model（帶著數據）回到了View--》View更新數據
在MVC中，當你有變化的時候你需要同時維護三個對象和三個交互，這顯然讓事情復雜化了。而實際狀況是View的界面樣式往往多變，而其內在邏輯很少變化。于是MVP產生：
2. Model-View-Presenter（MVP）
MVP定義了Presenter和View之間的接口，切斷了View和Model之間的調用關系，讓需求可以根據已有的接口協議去各自分別獨立開發，解決了界面需求變化頻繁的問題。上面兩圖都有接口，不過接口的實現和使用細節不一樣，但思想上是一致的。
- Android應用參考：淺談Andorid開發中的MVP模式
后來又發現了比MVP更省力的方法，就是：
3. Model-View-ViewModel
ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel間沒有了MVP的界面接口，而是直接交互，用數據“綁定”的形式讓數據更新的事件不需要開發人員手動去編寫特殊用例，而是自動地雙向同步。數據綁定你可以認為是Observer模式或者是Publish/Subscribe模式，原理都是為了用一種統一的集中的方式實現頻繁需要被實現的數據更新問題。
比起MVP，MVVM做了一件事情：直接讓界面元素和model雙向綁定。這樣一來，View的變動，自動反映在 ViewModel，反之亦然。這樣開發者就不用處理接收事件和View更新的工作，框架已經幫你做好了。
- Android應用參考：精通 Android Data Binding
