在Android上編程時,我最終編寫了由其他人擴展的父活動。有點像ListActivity
。我的父母活動延伸至Activity
。如果我打算使用Map
或List
,我不能將父母活動用作超類 - 子活動顯然只能擴展一個活動。因此,我最終以Activity
,ListActivity
,MapActivity
等等相同的邏輯寫我的父母活動。擴展Android活動的設計模式?
我在尋找什麼樣的特徵功能/設計模式,這將有助於在這種情況下。有什麼建議麼?
在Android上編程時,我最終編寫了由其他人擴展的父活動。有點像ListActivity
。我的父母活動延伸至Activity
。如果我打算使用Map
或List
,我不能將父母活動用作超類 - 子活動顯然只能擴展一個活動。因此,我最終以Activity
,ListActivity
,MapActivity
等等相同的邏輯寫我的父母活動。擴展Android活動的設計模式?
我在尋找什麼樣的特徵功能/設計模式,這將有助於在這種情況下。有什麼建議麼?
我已經結束了具有併入共享邏輯鹼MyAbstractActivity extends Activity
和MyAbstractListActivity extends MyAbstractActivity
模仿ListActivity
(膨脹layout.R.id.list
,layout.R.id.empty
等;沒有多少對那裏發生的)。
我真的很不喜歡ListActivity
,MapActivity
等等。基本上他們是以一些靈活性爲代價簡單添加單個視圖元素的活動。通過適當地將MapView
或ListView
添加到您的XML中,您最終會得到一個可以直接擴展派生超類的相同事物。所以,大多數情況下不要使用任何SomethingActivity類。
我正在使用具有所有共享功能的delegate。這使我能夠爲所有不同的活動在一個類中提供所有共享功能。
我所有的活動擴展了他們的特殊活動,然後實現了一個通用界面。這種方法的問題是我需要實現接口中定義的所有方法,並在委託對象中調用匹配方法。這段代碼目前共有30個重複的代碼行,我認爲這不是什麼大問題。
這不僅是添加視圖。您擁有地圖生命週期/遊標處理程序等等,具體取決於您使用的活動。好處可能不會平衡靈活性,但一些代碼肯定是通過使用傾向性類獲得的。 – charroch 2010-05-14 17:48:59