I need to add Preference in ICS using addPreferencesFromResource().
It is shown as deprecated in ICS.
I've added a preference layout in xml folder but this could not be added to the Preference activity.
How can I add it?
On API Level 11 and higher, the plan is for you to use PreferenceFragments to call addPreferencesFromResource(). You can see an example of this in the documentation for PreferenceActivity.
If you are trying to support PreferenceFragment on API Level 11+, yet still support older devices, you will need to do both the stuff shown in that documentation and call addPreferencesFromResource() directly in your PreferenceActivity... but only when you are on an older device. Even though addPreferencesFromResource() is marked as deprecated, that does not mean that it does not work, and more importantly it is your only option on API Level 10 and below.
Here is a sample project where I demonstrate supporting both API Level 11-style fragments and the classic PreferenceActivity from a single set of source.
Related
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 am new to Android development and I am following the training at http://developer.android.com to get into it. I am confused whether I do use the support library or not.
To make it clear: I do not need to support APIs older than 11.
Situation: Adding Items to the ActionBar I had to use my own Namespace to make it work (app:showAsAction="ifRoom" instead of android:showAsAction="ifRoom"), which is a normal behaviour using the support-lib, am I right?
First Question: Why am I using it? I did never activate it on purpose!
Second Question:
Is it normal that I can use both getActionBar().setDisplayHomeAsUpEnabled(true); and getSupportActionBar().setDisplayHomeAsUpEnabled(true); to make the "up"-functionality work? I thought the first one wouldn't work if I used the support-lib?
I'd be glad if one of you could help me. I don't want to mess around with these basics so I'd like to know what I understood or configured wrong.
EDIT: My "uses-sdk" in the AndroidManifest actually looks like this:
<uses-sdk android:minSdkVersion="11" android:targetSdkVersion="19" />
To answer your first question, depending on how you created your project in the first place, it was probably enabled for you automatically. There are lots of other things in the support library besides ActionBar, so even if your minSdkVersion=11, it's probably still a good idea to use it.
To answer your second question, yes, it's normal that both methods work. Framework methods are not disabled or removed when you enable the support library. They will still work as long as they are supported by the Android OS you're eventually running on. For example, if your minSdkVersion was 10 instead of 11 and you tried to run the app on a device running Gingerbread, it would crash on the getActionBar() call.
In your case, you should use the framework method (getActionBar()). The documentation for ActionBar says:
This class is included in the support library for compatibility with
API level 7 and higher. If you're developing your app for API level 11
and higher only, you should instead use the framework ActionBar
class.
The best way to know whether you need to use the support library for a given method or class is to refer to the documentation for that class and pay attention to the "Added in API Level ?" notation. Here is the documentation non-support-library version of ActionBar, where you can see that some methods were added after API 11. If you need any of those methods, you should use the support library.
Also, as I said before, there other things besides ActionBar to consider in your app. GridLayout is an example. It was added in API 14, but it also exists in the support library for backwards compatibility. If you want to use GridLayout, you should use the support library version of it.
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.
I am in the process of making my application compatible with the earlier versions of android using the Android Compatibility library. One of the integral parts of my application is to be able to highlight the user's selection permanently in a list fragment. I was able to do this conveniently using a selector drawable in API level 11 and above using the android:state_activated property. But as it turns out this property was introduced only in API level 11.
Now I plan to achieve the same in earlier API levels, but am out of ideas. Does anyone have any suggestions?
I believe I'll need to create a separate layout for older API versions - res/layout-v10/
Thanks!
Found an excellent solution here: http://udinic.wordpress.com/2011/07/01/selectablelistview-make-selection-work/
View.setSelected(boolean) (since api level 1) made the trick for me
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.