0

I am developing an application to SDK version 16 and above, As I understood the fragment framework is included in the OS framework in those versions.

I want to remove the support library fragment framework (now that the v4 support library is split) but all the other support libraries are using it (com.android.support:design:25.1.0 and more).

So what is the advantage of splitting the v4 support library?

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
Ovi
  • 60
  • 8
  • `android.app.Fragment` is included even without the support library. So, if you don't want `android.support.v4.app.Fragment`, then don't compile it. Remove all the support libraries. – OneCricketeer Jan 10 '17 at 15:57
  • Well I want the Material Design support library and it uses the `android.support.v4.app.FragmentActivity` – Ovi Jan 10 '17 at 15:59
  • And `AppCompatActivity` extends from that, so why exactly do you want to remove it? – OneCricketeer Jan 10 '17 at 16:01
  • @cricket_007 as I wrote the fragment framework already included in the OS since Android 3.0 so it is redundant. – Ovi Jan 10 '17 at 16:09
  • But if you are using Material Design, then you need an AppCompatActivity, which is a FragmentActivity, which more-or-less **should** use the support Fragments, which should be mostly compatible with the existing code. Just need to use `getSupportFragmentManager()` instead, for example – OneCricketeer Jan 10 '17 at 16:13
  • Exactly. This why I have asked.. The Material Design should use the native fragment framework when defining minSdkVersion 11 and above. – Ovi Jan 10 '17 at 16:16
  • 1
    Because there are still devices in the world running Android < 3.0 that could still use Material Design / Fragments? And I think the question you are asking is related to this. http://stackoverflow.com/questions/17295497/fragment-or-support-fragment – OneCricketeer Jan 10 '17 at 16:20
  • Thanks. This was helpful! – Ovi Jan 10 '17 at 16:27

1 Answers1

0

With respect to that particular library (com.android.support:design), they have not updated it to use the more-granular dependencies. With luck, they will do that someday.

In general, the advantage is to allow for flexibility. Not all apps use com.android.support:design, com.android.support:appcompat-v7, or other libraries that Google has not yet updated to use the more-granular dependencies. Apps that avoid those libraries can use individual dependencies (e.g., com.android.support:compat).

Also, you can use Gradle exclusion rules to attempt to block portions of the aggregate support-v4 that you feel that you are not going to use. For example, you could exclude support-fragment, then see if your app holds up under testing (though that will not work in your specific case, since the Design Support library requires appcompat-v7, which in turn requires FragmentActivity).

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • I have tried to exclude the support-v4 library but it ain't compile since the design library depends on `android.support.v4.app.FragmentActivity` – Ovi Jan 10 '17 at 16:05
  • @Ovi: You cannot use the Design Support library without using `appcompat-v7` and `AppCompatActivity`. That, in turn, extends `FragmentActivity`, and so you will not be able to block `support-fragment`. I updated my answer to match. – CommonsWare Jan 10 '17 at 16:07