雖然我說它"沒那麼有誠意", 不過我也想不出有啥方法做的比它更好
我想, 這東西的起因在於SDK 3.0 (Honeycomb SDK)為了Duo Panel的設計引入了Fragment, 當然還有Loader和Drag and drop等其他的新東西, 新東西本身並沒啥問題, 但問題在於, 如果要把原本Android的軟體porting到Honeycomb, 勢必要把很多的Activities改寫成Fragments, 但, 這引發了一個問題, Fragement並沒有向前相容, 軟體勢必要為Honeycomb跟pre-honeycomb分兩套寫法來維護, 這的確很不經濟, 因此有Google導入Fragment造成Android API的Fragmentation
所以可能因為如此, Google便有了“Android Compatibility package”這個解決方法:
Google Releases Compatibility Package to Address Fragmentation Issues
這解法就是把這些class包裝成一個static java library (jar), 讓你可以在你的程式內含入, 所以在1.6以上的版本都可以享受Fragment的好處
但問題在於, 如果用過Honeycomb的Fragment一定會發現, 它跟Activity緊緊的綁在一起, 他們要怎解決替換這個Framework裡很重要的class, 答案是…沒有替換, 用另一個東西來取代 - FragmentActivity
也就是說, 要在pre-Honeycomb裡用Fragment所用的方式跟Honeycomb並不相同, 它的package不是android.app而是另一個android.v4.support.app, 目前也似乎只有把Fragment, Loader和新的CursorAdapter含進來:
也就是說, 跟Honeycomb比起來算是另外一套, 雖然也可以直接在Honeycomb上用, 但等於就是捨棄原生的用Compatibility package
使用的方法很簡單, 只要把jar檔加的classpath裡就好(在Sdk/extra目錄內):
還有一些要注意的:
- 要用Fragment的Activity要變成繼承自FramentActivity (那原本需要繼承其他的ListActivity之類的就很麻煩)
- 要用getSupportFragmentManager取代原先的getFragmentManager
- 有些framework裡的resources只在Honeycomb存在
- 附的ApiDemos是Honeycomb的, 不能直接用這個package, 要改
其實也還要一點工, 這也就是我說不是那麼有誠意的原因
以下是我用ApiDemos裡的FragmentLayout改出來的結果 (在Ver 2.X上):
