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.
In my app I need provide this screen for tablets.
So when I choose Setings from ListFragment I need add appropriative fragment to activity e.g. PreferenceFragment, but there is no PreferenceFragment in support library.
Is there any "legal" way to use PreferenceFragment in platforms olter than 11 API level? Of cause there are projects on GitHub, which adding PreferenceFragment to android.support.v4.app.. For example that.
But usage of project like this is a good idea or not? Is there a better way to accomplish this?
EDIT
However I use sw to provide differend screens and it starts from the 3.2 version e.g. API level 13 and PreferenceFragment starts from API level 11.
So as far as I see I think that will be enought provide PreferenceFragment for tablets and PreferenceActivity for handsets.
I guess these are what you might be looking for:
PreferenceFragment-Compat
Android-support-v4-preferencefragment
I have a library of Android code that I use throughout my Android projects. I created it a while back, and it uses the v4 support library (any Fragment subclasses inherit its Fragment, and all my Activitys are FragmentActivitys).
In most of my projects I have a BaseActivity class that inherits from FragmentActivity so that I don't have to worry about accidentally defining a non-support library Activity and try to use one of the Fragments from the support library. I put a lot of my application specific boilerplate in this BaseActivity.
I'm now working out the logistics of dropping support for one of my apps for devices below ICS. I have found a few issues regarding how to continue to use my Android library, which mostly boil down to whether I should continue to use FragmentActivity and the support library's Fragment even after dropping support for HC-.
I'm stuck between the convenience of "native Fragment and ActionBar and the new capabilities they come with, and the backwards compatible nature of the support library (eg, nested fragments for 4.0-4.1).
Anyone have any input as to whether I should keep using the support library, or if it's worth it to find some way to have a ridiculous amount of version checking and code overhead to provide implementations for versions that needs the support library and versions that can use the current API?
I would suggest keeping the support library implementations. This allows you use things like ViewPagers without worrying or mixing and matching implementations. It also ensures that the underlying code won't change on you until you update the support library jar.
I've been thinking about the pros and cons of using Android's Support Package when targeting the latest API and setting the min SDK to 7, for example.
The Android documentation states "The goal is to simplify your development by offering more APIs that you can bundle with your application so you can worry less about platform versions"; however, I'm having some doubt on whether it will make it simpler.
Consider the TabActivity, which has been deprecated. The alternative to using TabActivity is through Fragments and by looking at the example to get a tabular view working, it doesn't look simpler. Besides, I have to use reflection anyways when deciding on to use the Fragments class versus the FragmentActivity class, so why not just use TabActivity. I was hoping to get your opinion on this. I'm leaning towards not using it, but I would like to know if I'm missing out on any benefits.
The alternative to using TabActivity is through Fragments
An alternative to using TabActivity is through Fragments, using the icky stuff in the example you cite. The better alternative to using TabActivity is to put your tabs in the action bar, perhaps using ActionBarSherlock's fork of the Android support library that offers a backwards-compatible action bar.
by looking at the example to get a tabular view working, it doesn't look simpler
It's not.
Besides, I have to use reflection anyways when deciding on to use the Fragments class versus the FragmentActivity class
If you are using the Android support library, you should not need this, as you always extend FragmentActivity.
I'm leaning towards not using it, but I would like to know if I'm missing out on any benefits.
If you plan on supporting tablets and/or TVs, you want to be using fragments. Fragments are useful even in phone-only apps, but not quite as visibly.
I'm trying to (correctly) implement a preferences screen, but the problem is that all the methods used to read preferences from xml files are deprecated (or I just don't recognize them). The official sample code on the dev site (PreferenceActivity) uses deprecated methods. Has anyone found out a way to implement a preferences screen with an xml file but without using either: addPreferencesFromResource(int) or findPreference(CharSequence)? Or have the methods just been marked deprecated without implementing the alternative yet?
EDIT: Developing for Android version 2.1
Why its deprecated and what is the alternative is pretty well explained in documentation:
This is the base class for an activity to show a hierarchy of preferences to the user. Prior to HONEYCOMB this class only allowed the display of a single set of preference; this functionality should now be found in the new PreferenceFragment class. If you are using PreferenceActivity in its old mode, the documentation there applies to the deprecated APIs here.
In other words, if you want to be HONEYCOMB compliant, then you should use PreferenceFragment for your PreferenceActivity. A detailed explanation on how to use fragments can be found in dev guide.
In Android 3, API Level 11, the fragment-based preference model was introduced, thus deprecating methods that "is not relevant for a modern fragment-based PreferenceActivity."
Since the online reference is the latest version, it shows the methods as deprecated. By manipulating the API Level dropdown, you can mark the methods that are not in the given Android version, but it doesn't update the descriptions to match, which is why it still shows up as deprecated.
If you don't plan on supporting Android 3+ you should just use the old methods, as the fragment-based solutions will not work to versions prior to this.