Adapt layout to Android platform or API level - android

For the application I am currently developing, I need to adapt the layout of the different activities to the user's Android API level.
Is there a way to do this?

If what you're trying to do is show a different layout depending on which API version is available on the device, you want to use configuration qualifiers. The specifics for alternative resources are also documented.
The most basic way to do it is to create a layout folder for each API level you want to use, formatted as follows:
res/layout/mylayout.xml (Default)
res/layout-v4/mylayout.xml (Android 1.6)
res/layout-v11/mylayout.xml (Android 3.0)
and so on, where vN is the API level. The specific API levels can be found on this page.

As Andrew Koester said you can use the different version folders, but I found this to be a lot of work because it would not fall back to the default layout. If you used layout-v14, it will work,but any api after 14 will also have this layout and you must use another layout-v? to override it again. It all depends on what your doing, but I found if your doing a lot of stuff programmatically this works wonders:
if(Build.VERSION.SDK_INT == Build.VERSION_CODES.ICE_CREAM_SANDWICH || Build.VERSION.SDK_INT == Build.VERSION_CODES.ICE_CREAM_SANDWICH_MR1){
//ex. if ics is met then do this
}else{
//if api is not ics then do this
}

If you already have drawable resources for each of the platform level, you can use the information provided in http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
More specifically, look at the 'Platform Version (API Level)' row in Table 2.

Related

How to work with two layouts in android at runtime if i am having two different layout

hi guys i am working on switch wants to implement. The real problem is switch is available in API 14 and wants to implement same functionality for below level.one solution is to use bullets for on and off option for below 14 level.another solution for above API 14 to use to use switch but the main problem is how i check API level at run time in layout file.
Thanks in advance
it is not possible to check the version through XML.
you have to do it through the java code, you can get the API level with Build.VERSION.RELEASE
you can see another question here:
Programmatically obtain the Android API level of a device?
You can use different resources buckets to "check the api level for the layout file:"
http://developer.android.com/training/basics/supporting-devices/screens.html#create-layouts
However where this example talks about different screen sizes you want different API versions.
For example:
MyProject/
res/
layout/
main.xml
layout-v14/
main.xml
gives you a different main.xml for ICS and above
you can create two different layout and check api level in java code. then if api level less than 14 use one of layouts and if greater than 14 use another layout.
for checking api level in java see this

Exclusive Layouts for certain api level - Android

I have a Layout that I would like to use only for tablets. I know that if create a folder "layout-v(api level)" that layout will be used only for that specific api. the thing is, for tablets, either you have api 11, 12, or 13. Is there a way I can create a folder that includes all of these instead of creating layout-v11, layout-v12, layout-v13 ?
Hope my question is not confusing, i just dont know how to put my question any other way.
Thanks
If you use layout-v11 it will be used for all versions >= 11 unless a higher version is specified (e.g. layout_v14). So you should only need to make the one folder, layout-v11.
Don't forget that you can have a 4" android device with API lvl 14. So using API version to distinct tablets and phones is not a good way.
Prefer the distinction with screen resolution. A good post about it is on the Android developers blog:
http://android-developers.blogspot.fr/2012/07/getting-your-app-ready-for-jelly-bean.html

Alternatives to list indicators in Android API Level 10 and below

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

Android application limiting features to support backwards compatibility

I have an Android app that has a minimum API level of 4 (Android 1.6) and I have some users who use this version of Android. However, I would like to implement a feature that uses NFC, which requires Android 3 or higher (API level 9+). This means that I would have to change the minimum API level in my manifest file, which will alienate users using older versions of Android. So is there a way to programmatically disable the feature that uses NFC if the device is incompatible and still allow the use of other features instead of locking out users using older versions of Android?
Set the min-sdk to 4 and the target-sdk to 9 and use something like this in your code:
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB){
//your API-9 specific code here
}else{
// an alternative code
}
this for the java part, in XML the newer attributes are ignored so its safe to add what you need
Read this http://developer.android.com/resources/articles/backward-compatibility.html . You can check if method exists using reflection API. Read previous questions: Check if method exists
You need yo encapsulate API level specific code to external classes and use reflection for calling them (using interface for example)

Support 3.0 and lower levels in the same project

I have a level 9 app on android, and I want to know if I can use new features from level 11 (Android 3.0) in the same project?
For 3.0 tablet version, my layouts will contain fragments. How do I use these fragments and allow the level 9 version to build and run successfully?
Can I define different layouts for different API levels (in the res/layout)?
If I keep 2 versions, one for tablet other for phones, can I add that to the android-marketplace with the same package name?
I have a level 9 app on android, and I want to know if I can use new features from level 11 (Android 3.0) in the same project?
Yes, via reflection or conditional class loading, as suggested by Mr. Willis. Here is a sample application that demonstrates this for the action bar, also new to API Level 11.
For 3.0 tablet version, my layouts will contain fragments. How do I use these fragments and allow the level 9 version to build and run successfully?
Use the Android compatibility library.
Can I define different layouts for different API levels (in the res/layout)?
Yes, via the -vNN resource set suffix (e.g., res/layout-v11). However, you should try to minimize this.
If I keep 2 versions, one for tablet other for phones, can I add that to the android-marketplace with the same package name?
No.
This question and answers seem helpful.
The official documentation also overs solutions in Backward Compatibility for Applications.
Try: http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
Using reflection is advised, which allows you to programmatically search for the existence of classes and methods at runtime.
As for layouts, try checking out Supporting Multiple Screen Sizes. There are different layout sizes such as layout-xlarge that you can use.
If I keep 2 versions, one for tablet
other for phones, can I add that to
the android-marketplace with the same
package name?
You can't use the same package name for two different apps.
If your code is sufficiently different depending on the API version you're using, you might want to fork your code and then merge it again later when you are confident most of your user base has upgraded to the API level you need.

Categories

Resources