2015-09-27 65 views
0

在Big Nerd Ranch的Android編程中,它倡導AUF(始終使用片段)。具體來說,有這樣一段話:始終使用片段

」 ...添加片段後可以成爲一個雷區更改的活動 託管UI片段的活動並不難,但也有惱人的陷阱的 羣。因爲你要跟蹤這個毫無意義的區別保持由 活動管理的一些接口,並讓他人通過碎片管理只會使事情 更糟。 要容易得多利用碎片從一開始 編寫代碼,而不是擔心疼痛並在稍後重做它的煩惱,或者 必須記住您在每個中使用的控制器類型你的應用程序的一部分。「

這本書沒有闡述什麼惱人的陷阱。什麼是陷阱?

+1

「什麼是疑難雜症?」 - 顯然是成羣結隊的東西。由於他們居住在格魯吉亞,我想也許是g。。 :-)在開始使用片段的活動中,與開始時放入片段相比,我想不出任何特殊的挑戰。 – CommonsWare

+0

你會不會建議他們總是使用片段? – Boon

+0

@CommonsWare我可以想到一個 - 在活動中有片段,並使用'onActivityResult'回調。當以後交換片段的活動時,最終會產生嵌套片段,並且進一步片段路徑不會正確地獲得onActivityResult回調。如果我錯了,請告訴我(過去我確實遇到過問題),雖然你可以使它工作,但我肯定有資格作爲* gotcha * – wasyl

回答

1

最大的是上下文。因爲活動是由上下文驅動的(不是直接)。當你在一個活動中需要上下文時,你一直都在那裏。與片段的情況不同,在片段中,您可以調用getActivity方法來獲取父活動,但在將代碼從Activity移植到片段時,您必須處理將它提供給各處的情況。

另一個問題可能是Activity的生命週期。活動生命週期很簡單,像onResume這樣的函數,onPause使用同樣的樂趣不能說是片段。將針對活動生命週期設計的事情調整爲片段生命週期可能是一場噩夢。儘管如此,如果事情並不複雜,而且您只需要處理一項任務,那麼隨着活動開始就很安全。

1

因爲你是在決策的一開始,我要離開這裏了這一點: https://corner.squareup.com/2014/10/advocating-against-android-fragments.html

在底線,這個博客說,一個片段的生命週期是太複雜了,因此主張對使用片段,有利於模型 - 視圖 - 演示者模式

個人注意事項:來自CommonsWare的羅嗦評論觸目驚心。我盲目地使用片段,因爲他們在那裏,我從來沒有問過他們。但在閱讀了上述文章後,我改變了主意。