I've been building an app that untill recently had minSdkVersion="14", but i want to change that and add compatability for api 10. The first problem i had was with styles but i sort-off fixed it by using Theme.AppCompat. Now i have problems in my code, the first one is that i'm using a lot of fragments.
The first fragments that appear in my app are:
FirstRunNotice firstRunNotice = new FirstRunNotice();
firstRunNotice.show(getFragmentManager(), "WhatDoesThisStringEvenDo?");
//.show method gives an error
This is just an inner class within my activity that extends DialogFragment. How do i make this work on API 10? If i change it to android.support.v4.app.DialogFragment it seems to take the errors away (using Android Studio) but it's weird because if i use it on one inner class (i have the DialogFragments) it takes the error away on both. Why is that?
Also, if i were to change all Fragment extended classes to android.support.v4.app.Fragment, .DialogFragment, .ListFragment... What would that do in case i run my app on a higher API, let's say 19? Would the app use the compatability library or would it know to use the class from that API? And is there a difference?
Since now you want to support Gingerbread and lower, you have to use the android.support.v4.app.* Fragment classes for your app to compile and run.
The call to getFragmentManager() should also be replaced with getSupportFragmentManager()
It is also important to note that calling getSupportFragmentManager() is only part of FragmentActivity and ActionBarActivity (the latter is an extention of the former. It is a part of Google's ActionBarCompat library).
This is because since the support Fragments are an addition to the Android system, there needs to be a way to implement them without relying too much on the Android internals (since Gingerbread and lower have no notion of a Fragment).
but it's weird because if i use it on one inner class (i have the
DialogFragments) it takes the error away on both. Why is that?
It's likely you are encountering multiple Android Lint errors
What would that do in case i run my app on a higher API
Nothing, the support library works with new API versions as well. Of course, if you had previous code that required API 11+, then you need to figure out a way to backport that as well.
Would the app use the compatability library or would it know to use
the class from that API?
The support Fragment documentation says:
When running on Android 3.0 or above, this implementation is still
used; it does not try to switch to the framework's implementation.
Support Fragments will always be used. Usually, this isn't an issue.
Related
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.
from some of the answer such as
Using getFragmentManager() vs getSupportFragmentManager()?
I find that getFragmentManager() is used for API>=14,
and getSupportFragmentManager() will be used in support lib such as v4 which also support older API.
So my question is should I just use getSupportFragmentManager (import the support.v4 for each classes) so that my application can be used in any API version?
And are there any different I should know between these 2 FragmentManager?
If you are interested in supporting API versions that do not have Fragments, then by all means use the FragmentActivity and getSupportFragmentManager() patterns.
Even if you are not targeting an API below 14, it may be a good idea to use the support library. Classes in the support library can be updated by you, the developer, whenever Google releases a bugfix/feature in the library that you are interested in. If you use a framework class, you only get the updates when your users get a firmware update, which we all know can take a while. Using the support library means all users are using the same "latest-and-greatest" classes.
Yes, for Fragment, just use getSupportFragmentManager, then your app for Fragment can be compatible backward to old API levels, normally minSDKversion = 7 is enough. However if you really want your app to get compitability with most API levels, then there still many other components your app concerning need use support library, such as ActionBar, etc..
For more info, please go through Android Docs: Support Library Features
I tried to use almost all examples and source code from internet and all of them just doesn't work. I got this warning "The type TabActivity is deprecated", anyone have source code for Tabhost that is really working and doesn't crash?
You should not be using Tabs anymore. Look after Fragments instead. a good place to start is
http://developer.android.com/guide/components/fragments.html
From the documentation for TabActivity:
This class was deprecated in API level 13.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT.
You should learn how to use Fragments instead. TabHost/TabActivity isn't being actively supported any more, so if you're just learning how to do tabs, you should do it the new way. No point in learning something, only to have to replace it anyway.
From the link here:
This class was deprecated in API level 13.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT.
So the suggestion is obvious - use Fragments. But don't ask here how, create a new Question.
go through the link:http://developer.android.com/training/backward-compatible-ui/abstracting.html Download the Sample App: TabCompat.zip
I am working on an Android application that is currently targeting devices having a minimum API of 11. However, I want to modify the app to make it compatible with android versions lower than 3.0. The problem is, I have various UI elements that are only provided in the newer versions:
Action bar contains menu items. I read that one solution is using the ActionBarSherlock package. However, the activity already extends ListActivity. Is there any other solution?
Date picker dialog fragment throws an error saying:
"Call requires API level 11 (current min is 8): new android.app.DialogFragment"
This error occurs on the method newFragment.show().
This happens despite having followed the note given on the Android Developer page:
http://developer.android.com/guide/topics/ui/controls/pickers.html
What could be the problem?
However, the activity already extends ListActivity.
Use ActionBarSherlock and change from ListActivity to SherlockListActivity.
What could be the problem?
You are trying to use native API Level 11 fragments instead of the Android Support Library's backport of fragments. IOW, you are using android.app.DialogFragment instead of android.support.v4.app.DialogFragment.
"The type TabActivity is deprecated"?
I am making the Tabs of app following tutorial book.
I've checked from the android developer.com website, but i have no ideas on the significance of the following message : This class is deprecated.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT."* (http://developer.android.com/reference/android/app/TabActivity.html)
What is v4 support library?
How to finish the tab functions?
You can still use a deprecated package. It is however recommended to use Fragments, and thus the support package. You can read more about it here. However, if you are a beginner at java and android development, I would recommend ignoring the deprecation for now and come back to this when you have completed the tutorial you are currently using if you find it educating.
If you want to watch a nice example of tabbed navigation using Fragments, then create a new project in Eclipse using android 4.0 or later. Make sure your android-plugin is updated. You will get the option to create a project with basic navigation already implemented.
"Deprecated" means that the api developers don't recommend using it anymore, probably because its not a good model, or inefficient, etc. Fragments were introduced in Honeycomb and can be used to provide a similar functionality as tabs and is more in-line with android's current design philosophy.
Since Fragment was introduced in Android 3.0 Honeycomb, you might think you cannot use that for pre-Honeycomb devices. Enter Support Libraries. They are libraries which you can include in your application which needs to run on pre-Honeycomb and still use this class.
So if you want to, you can finish the TabActivity as described in whatever tutorial you are following, it'll probably work on a few more upcoming android versions. But it is recommended that you start using Fragments.