詳細的Fragment初階可以參考 Developer Document
Developer document裡面的Design Philosophy提到, Fragement的設計是為了讓大尺寸的螢幕(比如說Tablet), 有更動態更彈性的UI設計, 從那個範例圖來簡單的說, 就是想達到iPad上那種Multi-panel的UI設計
在實際設計上, 似乎想要把Fragment設計成一個比較通用的design, 因此看起來比較不像是把一個Activity的話面分屍切成等份, 而是把Fragment當成UI上一個個有自己生命週期的獨立個體, 因此它的實踐未必是以Multi-panel的形態, 因此也有類似像DialogFragment的存在
如果以Web design的觀點來看, Fragment可以類比成<frame>或是<iframe>, <frame>或<iframe>可以看成一個HTML document的一個pagelet, 而Fragment也是可以看成一個Activity裡面受Activity裡的FragmentManager所管理的lightweight inner Activity, 我個人其實對Fragment這設計並不是很欣賞, 如果用它來implement multi-panel UI感覺頗tricky, 尤其在landscape/portrait轉換上, 而Fragment的角色定位似乎介於View以及Activity之間, 你可以將之看成一個有生命週期的複雜View的包裝(好拗口 = =“), 也可以把它看成一個簡易到不行的Activity, 對照ActivityGroup/LocalActivityManager來說, Fragment/FragmentManager 雖然顯得相對的light, 但特別為了這些目的把FragmentManager給整進Activity內, 感覺只是肥化Activity而已
Fragment並不是implement multi-panel UI的唯一途徑, Romain Guy有一個叫做x-large demos/PhotoAlbum的範例, 在這範例中, 他實作了一個Multi-panel based的Album, 但卻沒有用到任何一個Fragment
在初看到這個API時讓我比較感興趣的是, 目前在Android market上已經有相當多的phone based的軟體了, 如果是要把自己原有的架構在Phone based的軟體轉成同時也支援Fragment架構的tablet軟體(就兩者通吃), 在code的重用性, 以及porting的effort到底大不大?
基本上, 這也不是太大的問題, 只是要把原本Activity裡面的東西抽出變成一個Fragment來implement, Activity變成只是Fragment的封裝
例如說, 原本的layout假設是 main.xml, Activity裡面原本是以
setContentView(R.layout.main)
把原本的layout抽出獨立成另一個layout, 比如說mylayout.xml, 並新增一個新的Fragment(比如說叫MyFragment), 原本的main.xml內容改成:
MyFragment只要implement onCreateView:
這樣Activity跑起來就跟原本還沒用Fragment沒啥兩樣…呃, 那這樣還多此一舉用Fragment幹嗎? 其實這只是一個簡單的靜態範例, 新創造出來的Fragment, 還可以重複在別的Activity被使用(比如說一個for tablet 的multi-panel activity), 也可以動態被創造出來應用