AppCompatActivity設計

爲什麼AppCompatActivity的getFragmentManager()返回片段管理器的支持版本？相反，您必須同時讓您的活動爲AppCompatActivity，並特別呼叫getSupportFragmentManager()。其他十幾種方法也是如此。它讓我感到奇怪，你必須神奇地知道你可以稱爲自己的哪些方法，以及哪些方法需要重新命名爲「支持」版本。當你仍然支持較低版本的Android時，是否還有任何需要調用「正常」版本而不是「支持」版本的用例？如果AppCompatActivity與Activity的後續API版本無法區別地運行，那麼對我而言會更有意義 - 畢竟，這就是它所支持的，不是嗎？提供與Activity的後續API版本相同的功能？AppCompatActivity設計

是否有某種設計原則或隱藏的Java限制阻止他們這樣做？

來源

2017-02-09 Erhannis

爲什麼AppCompatActivity的getFragmentManager（）返回片段管理器的支持版本？

因爲它不能。

Activity，在API級別11+上，將getFragmentManager()定義爲返回android.app.FragmentManager。 AppCompatActivity可以覆蓋它的唯一方法是如果重寫的方法也返回android.app.FragmentManager。這是不可能的。 AppCompatActivity旨在回到API級別7，其中沒有android.app.FragmentManager返回。因此，我們有getSupportFragmentManager()，返回android.support.v4.app.FragmentManager。

請注意，AppCompactActivity確實從FragmentActivity獲得了片段，該片段旨在回溯到API Level 4，這是API Level 11和本機片段實施前的兩年。

來源

2017-02-09 22:03:41 CommonsWare

爲什麼不，例如，有支持庫定義他們自己的'android.app.FragmentManager'版本？（我預測了「那麼支持版本會與後來的API中的本地版本衝突」或「安全原因」）的原因，但我不確定） – Erhannis

@Erhannis：「例如，爲什麼不支持支持庫定義他們自己的android.app.FragmentManager版本？「 - 因爲那時使用該庫的應用程序在API Level 11+上崩潰，而android.app.FragmentManager的實現發生衝突。 – CommonsWare

嗯。如果在ClassLoaders和反射方面沒有一些棘手的方法，我會感到驚訝，但我會留下這個。另一種解決方案發生在我身上的將是他們具有子類別的活動，而不是添加方法，所以AppCompatActivity和Activity11或任何都實現了getFragmentManager（）與他們自己的版本的FragmentManager。儘管如此，我不能說我喜歡那種方式。煩人的不整潔。好，我屈服;謝謝。儘管如此，我仍然不太喜歡所有的「支持」方法;它也是不整潔的。 – Erhannis

AppCompatActivity設計

回答

相關問題