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.
I'm a newbie to Android Development. Even though I referred the android developer website, I didn't figure out.
On the customize Activity dialog box, when I unchecked the Backwards Compatiblity(Appcompat) in Android Studio 2.3.1 It gave me a hint as:
If false, this activity base class will be Activity instead of AppCompatActivity
Generally, what do android developers prefer? enabling backwards compatibility or without it? Can anyone explain me which one is better.
Android apps can be backward-compatible without checking this checkbox.
If false, this activity base class will be Activity instead of AppCompatActivity
Android studio is letting you know that if you uncheck the "Backwards Compatability(Appcompat)" box, then you'll be including & using the library Activity instead of AppCompatActivity.
For a more detailed comparison between the two, check this: Activity, AppCompatActivity, FragmentActivity, and ActionBarActivity: When to Use Which?
Generally, what do android developers prefer? enabling backwards compatibility or without it?
A comment written by "CommonsWare" explains this best:
An activity created with that checkbox checked is no more backwards compatible than is one without that checkbox checked. Checking the checkbox gives your app a particular look and feel that will retain that look and feel on some older devices; leaving the checkbox unchecked means that some aspects of your look and feel will be different on pre-Android 5.0 devices. This does not impact the core functionality of the activity, though. – CommonsWare
Backwards compatibility allows you to use certain backwards compatible features in your app. They will be able to work on previous versions of Android.
The Android Support Library offers backward-compatible versions of a number of features that are not built into the framework. (Android Support Library website)
For example, instead of Activity, AppCompatActivity will be used and is something that is "backwards" compatible. It can be used all the way back to API level 15.
You should generally use AppCompatActivity to support older Android versions. If your app has no need for older android versions, then just use Activity.
Using AppCompatActivity is generally more recommended.
I am creating a new application and will have to deal with ActionBar. I know that I have to extend the AppCompatActivity because the ActionBarActivity is deprecated, however I still do not understand why I have to use the support.v7.widget Toolbar rather than the android.widget Toolbar even though I am using the latest API ?
Thank you
EDIT1:
I understand now that the support.v7.widgets are there to enable devices with old APIs to comprehend what are the new functionalities added in the newer versions and mimic them in their own way. Is that correct ?
If that is correct and I do not want to have any sort of backwards compatibility does this mean I can move forward and use the android.widget Toolbar ?
Also using the android.widget Fragment unfortunately I can not add it to a ViewPager. Why is that ? Why does it force me to use an older version which has been extended to mimic the behaviour of the new implementation of the component ?
I think I just getting lost in all of those "support" libraries. Can someone briefly ( or not ) explain all that - why are there things in the support libraries that are not included or updated in the newer versions of the API ?
Thank you
First of all you are asking Good Question, Android will add advanced features continuously in different API levels but those features are available from which level of API they are added
For Example: Consider android fragment functionality was added in API level 11 that means it will work for API level 11 and above but your application need for API level 10 devices also at that time it wont be work. For this reason android develop support library for cover a wide range of Android devices (support for low level API) to work those functionality.
Android always recommend developers to use support library for development for more information check here
Support.V7.widgets and widgets.android both are different libraries.
support.v7.widgets uses design library.
toolbar actually not an actionbar we are manually implementing a
ActionBar with support library.
And there are lot more new inbuilt properties are included like observableScrollActivity and More material designs...,
Why we aren't using default actionbar?
Because ActionBarActivity is depricated. Comparing old actionbar with our latest sdk actionbar it gives good look.
.setSupportActionBar(toolbar);
After Setting support to the toolbar gives actionbar properties to the toolbar like we can hide it by getSupportActionBar().hide();
I'm coming from iOS where it's easy and you simply use a UIViewController. However, in Android things seem much more complicated, with certain UIComponents for specific API Levels. I'm reading BigNerdRanch for Android (the book is roughly 2 years old) and they suggest I use Activity to host my FragmentActivities. However, I thought Activity was deprecated.
So for API Level 22 (with a minimum support for API Level 15 or 16), what exactly should I use both to host the components, and for the components themselves? Are there uses for all of these, or should I be using one or two almost exclusively?
I thought Activity was deprecated
No.
So for API Level 22 (with a minimum support for API Level 15 or 16), what exactly should I use both to host the components, and for the components themselves? Are there uses for all of these, or should I be using one or two almost exclusively?
Activity is the baseline. Every activity inherits from Activity, directly or indirectly.
FragmentActivity is for use with the backport of fragments found in the support-v4 and support-v13 libraries. The native implementation of fragments was added in API Level 11, which is lower than your proposed minSdkVersion values. The only reason why you would need to consider FragmentActivity specifically is if you want to use nested fragments (a fragment holding another fragment), as that was not supported in native fragments until API Level 17.
AppCompatActivity is from the appcompat-v7 library. Principally, this offers a backport of the action bar. Since the native action bar was added in API Level 11, you do not need AppCompatActivity for that. However, current versions of appcompat-v7 also add a limited backport of the Material Design aesthetic, in terms of the action bar and various widgets. There are pros and cons of using appcompat-v7, well beyond the scope of this specific Stack Overflow answer.
ActionBarActivity is the old name of the base activity from appcompat-v7. For various reasons, they wanted to change the name. Unless some third-party library you are using insists upon an ActionBarActivity, you should prefer AppCompatActivity over ActionBarActivity.
So, given your minSdkVersion in the 15-16 range:
If you want the backported Material Design look, use AppCompatActivity
If not, but you want nested fragments, use FragmentActivity
If not, use Activity
Just adding from comment as note: AppCompatActivity extends FragmentActivity, so anyone who needs to use features of FragmentActivity can use AppCompatActivity.
Activity is the base class of all other activities, I don't think it will be deprecated. The relationship among them is:
Activity <- FragmentActivity <- AppCompatActivity <- ActionBarActivity
'<-' means inheritance here. The reference said ActionBarActivity is deprecated, use AppCompatActivity instead.
So basically, using AppCompatActivity is always the right choice. The differences between them are:
Activity is the basic one.
Based on Activity, FragmentActivity provides the ability to use Fragment.
Based on FragmentActivity, AppCompatActivity provides features to ActionBar.
2019: Use AppCompatActivity
At the time of this writing (check the link to confirm it is still true), the Android Documentation recommends using AppCompatActivity if you are using an App Bar.
This is the rational given:
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.
The general directions for adding a ToolBar are
Add the v7 appcompat support library
Make all your activities extend AppCompatActivity
In the Manifest declare that you want NoActionBar.
Add a ToolBar to each activity's xml layout.
Get the ToolBar in each activity's onCreate.
See the documentation directions for more details. They are quite clear and helpful.
For a minimum API level of 15, you'd want to use AppCompatActivity. So for example, your MainActivity would look like this:
public class MainActivity extends AppCompatActivity {
....
....
}
To use the AppCompatActivity, make sure you have the Google Support Library downloaded (you can check this in your Tools -> Android -> SDK manager). Then just include the gradle dependency in your app's gradle.build file:
compile 'com.android.support:appcompat-v7:22:2.0'
You can use this AppCompat as your main Activity, which can then be used to launch Fragments or other Activities (this depends on what kind of app you're building).
The BigNerdRanch book is a good resource, but yeah, it's outdated. Read it for general information on how Android works, but don't expect the specific classes they use to be up to date.
Activity class is the basic class. (The original) It supports Fragment management (Since API 11). Is not recommended anymore its pure use because its specializations are far better.
ActionBarActivity was in a moment the replacement to the Activity class because it made easy to handle the ActionBar in an app.
AppCompatActivity is the new way to go because the ActionBar is not encouraged anymore and you should use Toolbar instead (that's currently the ActionBar replacement). AppCompatActivity inherits from FragmentActivity so if you need to handle Fragments you can (via the Fragment Manager). AppCompatActivity is for ANY API, not only 16+ (who said that?). You can use it by adding compile 'com.android.support:appcompat-v7:24:2.0' in your Gradle file. I use it in API 10 and it works perfect.
There is a lot of confusion here, especially if you read outdated sources.
The basic one is Activity, which can show Fragments. You can use this combination if you're on Android version > 4.
However, there is also a support library which encompasses the other classes you mentioned: FragmentActivity, ActionBarActivity and AppCompat. Originally they were used to support fragments on Android versions < 4, but actually they're also used to backport functionality from newer versions of Android (material design for example).
The latest one is AppCompat, the other 2 are older. The strategy I use is to always use AppCompat, so that the app will be ready in case of backports from future versions of Android.
Since the name is likely to change in future versions of Android (currently the latest is AppCompatActivity but it will probably change at some point), I believe a good thing to have is a class Activity that extends AppCompatActivity and then all your activities extend from that one. If tomorrow, they change the name to AppCompatActivity2 for instance you will have to change it just in one place.
When I created a new app, I got this
class NewApplicationActivity extends ActionBarActivity{... }
So I have read that, if you want to use a new feature from a newer API level, you better make it such that there is an alternative option for the App to combat any situation for the minSDKVersion that you plan to support.
Assuming this is true, lets say I decide to build my App against targetSDKVersion = 21(which I did in the above example), I would get the base Activity class as ActionBarActivity. Now this is from support library and works for older version(down to Android 2.1 I guess..).
The thing is, I am stuck with these alternative set of support libraries rather than platform libraries. Am I gonna miss something significant if this happens? Will I get a chance to incorporate the platform specific code from API 21 into my App ever? The majority of Apps are made with compatibility in mind. How do you people handle this?
Support Libraries such as AppCompat (which is what ActionBarActivity and its replacement AppCompatActivity are part of) are designed to reflect the latest platform changes and backport as much as possible. Thereby by using AppCompat, you are already using a large number of API 21 features (such as material theme).
Of course, there is nothing stopping you including any API from any level in your application: just make sure that they are guarded by the appropriate API level checks: this is exactly what many of the Compat classes in Support v4 such as NotificationCompat and ViewCompat do for you.