When writing an Android library, should I use the AppCompat or Support variants provided by the support library?
For example, should a method take an Activity or an AppCompatActivity? support.v4.Fragment or android.app.Fragment?
In general you should use the AppCompat libraries wherever possible. The library provides backporting for some new features (whatever is practical), and fixes bugs in various version specific versions. For Activities and Fragments its particularly important, as Fragments at least had major differences between versions.
AppCompatActivity is the base class that support Support library ActionBar while Activity is actually the parent of AppCompatActivity. Depending on your purpose of library, if you have no intention of using the Support library ActionBar / Fragment related feature in your library, I would say, in general, the activity class is sufficient for your library.
android.app.Fragment has been deprecated now with API 28. So just go for the support Fragment version.
Related
I am quite new to Android and Android Studio. I have created a new project and I have specified the minSdkVersion as 21 and target to 23.
After AS is done with creating the activity I see that MainActivity is extending AppCompatActivity by default.
I read about AppCompatActivity here
It says that it is the Base class for activities that use the support library action bar features.
Now my question is:
Since my app's minSdkVersion is 21 why do I need my activity to extend AppCompatActivity?
Why does AS make my activity extend AppCompatActivity by default?
Is it necessary for my activity to extend AppCompatActivity or just extending Activity is enough considering my minSdkVerion?
What would I miss if my actvity don't extend AppCompatActivity?
Any explanation would be very helpful. Thanks
I think you should extend AppCompatActivity if you are using action bar
Read more here
Beginning with Android 3.0 (API level 11), all activities that use the default theme have an ActionBar as an app bar. However, app bar features have gradually been added to the native ActionBar over various Android releases. As a result, the native ActionBar behaves differently depending on what version of the Android system a device may be using. By contrast, the most recent features are added to the support library's version of Toolbar, and they are available on any device that can use the support library.
For this reason, you should use the support library's Toolbar class to implement your activities' app bars. Using the support library's toolbar helps ensure that your app will have consistent behavior across the widest range of devices. For example, the Toolbar widget provides a material design experience on devices running Android 2.1 (API level 7) or later, but the native action bar doesn't support material design unless the device is running Android 5.0 (API level 21) or later.
AppCompatActivity gives you the additional functionality of ActionBar after api level 7.
Activity helps you avoid extra libraries but doesnt provide actiobBar feature.
Prior to revision 22.1.0 the Action bar was provided by extending ActionBarActivity which is deprecated now
Well, as you said, indeed it is. We don't have to extends AppCompatActivity. But a lot of open source libs using AppCompatActivity to grab the feature to lower API level projects, and the third part libs are going to ask your MainActivity to extends AppCompatActivity. So, either you can implement your own lib or extends AppCompatActivity.
AppCompatActivity is a part of support library, so you also have the benefit of using support library. In short, your activity which extended AppCompatActivity will have the capability of the Activity in the recent API (but as long as the implementation of the capability is builded in the support library).
You can read the following from documentation:
Using Support versus Framework APIs
Support Libraries provide classes and methods that closely resemble APIs in the Android Framework. Upon discovering this, you may wonder if you should use the framework version of the API or the support library equivalent. Here are the guidelines for when you should use support library classes in place of Framework APIs:
Compatibility for a Specific Feature - If you want to support a recent platform feature on devices that a running earlier versions of the platform, use the equivalent classes and methods from the support library.
Compatibility for Related Library Features - More sophisticated support library classes may depend on one or more additional support library classes, so you should use support library classes for those dependencies. For example, the ViewPager support class should be used with FragmentPagerAdapter or the FragmentStatePagerAdapter support classes.
General Device Compatibility - If you do not have a specific platform feature you intend to use with your app in a backward compatible way, it is still a good idea to use support library classes in your app. For example, you may want to use ActivityCompat in place of the framework Activity class, so you can take advantage of newer features later on, such as incorporating the new permissions model introduced in Android 6.0 (API level 23).
The current minSdkVersion for my app is 16, targetSdkVersion,compileSdkVersion are 21.
When I first started the app, minSdkVersion was 10, and the book I was learning from used the v4 Support library.
I've gone through my app and I found that these are the imports I have been using from the v4 support library:
ActionBarDrawerToggle
DialogFragment
DrawerLayout
Fragment
FragmentActivity
FragmentManager
FragmentStatePagerAdapter
ListFragment
NavUtils
ViewPager
Since I have raised the minSdkVersion, I don't think I need to use the support versions of most of these anymore. I believe I still have to use ViewPager and DrawerLayout, though.
The developer pages say:
Caution: When using classes from the Support Library, be certain you import the class from the appropriate package.
For example, when applying the ActionBar class:
android.support.v7.app.ActionBar when using the Support Library.
android.app.ActionBar when developing only for API level 11 or higher.
So, my question is:
1) May I simply use an import similar to android.app.Fragment for all of the above, since my API level is minimum 16? (Except ViewPager and DrawerLayout)
2) For ViewPager and DrawerLayout, is there a difference between using v4 or v7 or another support library version?
Any advice is appreciated. Thanks!
First, with Fragment and all its related paraphernalia (FragmentManager, FragmentTransaction, &c) the most important thing is to use the imports consistently (that is, don't mix and match). That, I think, is the point the documentation wants to make.
That said...
You could swap out usages of android.support.v4.app.Fragment with android.app.Fragment if you wanted to use the native versions of these classes instead of the support ones, but be careful: the support library also adds some methods and callbacks that were not present in API level 16 (one important example being getChildFragmentManager(). So, basically, it comes down to whether all the features of Fragments that you're using are available for the native Fragments in all the API levels you will support.
Also, using the support library Fragments means that they should behave exactly the same in all Android versions, while they might be differences in the native implementations.
In our particular case we decided to keep using the support library, but YMMV.
As for the second question, I don't think there is a v7-specific ViewPager (at least, I think so). The v7 libraries are add-ons (appcompat, gridlayout, &c).
My new project is gonna be of API 14 min level. I'm going to use the compatibility library because it holds a lot of cool stuff. Wouldn't I bump into any compatibility issues if I use android.app.Fragment instead of android.support.v4.app.Fragment?
I don't want to use the later because I would like to use new (Honeycomb) animation framework to animate fragments transition (and to use FragmentManager from SDK), for instance. Just afraid it wouldn't work with some components from the compatibility lib where android.support.v4.app.Fragment must be used.
Wouldn't I bump into any compatibility issues if I use android.app.Fragment instead of android.support.v4.app.Fragment?
Not generally. Use the v13 version of the base library, not the v4 one, so that you can pick up v13 editions of classes like FragmentPagerAdapter, which will work with the native API Level 11+ edition of fragments.
I am implementing fragments with a DrawerLayout. I have 2 options when I import Fragments
android.support.v4.app
android.app
Which one should I use ? I dont see any difference except it seems like the android.support.v4.app has no support for objectAnimator.
What do you suggest ?
Edit: I only plan on supporting API level 14 and higher...
It depends on whether you are using Support Library.
If you are using fragments below api level 11 then use android.support.v4.app. In this case you will extend FragmentActivity which is the base class of support based fragments.
If you are using fragments in api level 11 and above use android.app. In this case you will extend standard Activity.
Take a look at the below link and decide on what versions your app should run. Depending on that decide whether you need support library or not.
https://developer.android.com/about/dashboards/index.html
I only plan on supporting API level 14 and higher...
Then there is no need to use support library. Use
import android.app.Fragment
and extend standard Activity.
If you are using support libary for drawerlayout then you should use android.support.v4.app for fragments.
You can use open-source "AndroidX" Support Library nowadays.
You can start from here AndroidX
Android support library v13 is supposed to provide support for newer APIs from Android 3.1. However, as far as I can tell there is no support for child fragments. Specifically, where is getChildFragmentManager()? The v13 support library relies on native fragments, which didn't add this method until API level 17. I have an app with minimum SDK level 14 so I should be able to use the v13 support library, but it seems I can't.
I don't want to go all the way back to the v4 support library and take on all it's weight. The v13 library is perfect otherwise.
If you want to use nested fragments within a native Fragment. use getFragmentManager().
If you want to use nested fragments within a support library Fragment, use getChildFragmentManager().
Just found this out by accident. It works. :)
Android support library v13 is supposed to provide support for newer APIs from Android 3.1
Not really.
However, as far as I can tell there is no support for child fragments
Correct. You cannot change existing classes from an external library in Java. android.app.Fragment already exists, therefore the library cannot add methods to Fragment.
I have an app with minimum SDK level 14 so I should be able to use the v13 support library, but it seems I can't.
You can simply not use nested fragments. Or, use the fragments backport.
I don't want to go all the way back to the v4 support library and take on all it's weight
android-support-v13.jar is larger than android-support-v4.jar.
If v13 included all of v4 then what is its purpose?
It adds some classes, like native-fragment implementations of FragmentPagerAdapter and FragmentStatePagerAdapter, that are not needed for apps who do not have native fragments, because their android:minSdkVersion is below 11.
the v13 library uses the native fragments and activities, not support fragment
android-support-v13.jar contains all of the android.support.v4 and all of the android.support.v13 classes from the SDK.
you should just use the v4 support library fragments. then you can use nested fragments w/ api 14. There is no real downside to doing so. They are already included in the v13 support library (it includes all of v4)