I am looking for a way to get different UI design for different API's. Google search gave me a link:http://developer.android.com/guide/google/play/publishing/multiple-apks.html#CreatingApks
In this link it states it is better to create different Apk's for different API and play store will take care of choosing the best one for the phone.
Is this the only method or is there any easy way?
Well thats possible if you are ready to write more code,
One thing you can do if you want it to achieve different API levels with different UI is to detect API level runtime by using this constant: android.os.Build.VERSION.SDK_INT. It returns one of these values.
Now according to this version you can have different layout xml to be set as contentView of your activity.
Note : This has more maintenance hazard. In case you want to add/remove any UI element you have to modify all of your layout XMLs in your application.
It's not necessary to build multiple APKs to achieve this.
Look into the links at: http://developer.android.com/training/multiscreen/index.html.
Try not to use different APKs if at all possible; it creates a mess.
To use a specific layout for API 14, for example, use the folder /res/layout-v14 instead of /res/layout. /res/layout-v8 for API 8, and so on…
Android will take resources from the folder that most closely matches it. The folders act as sort of a requirement. So, if you have API 15 and no layout-v15 folder, it will take it from layout-v14. If you have layout-v14 and layout-v8, if it's using API 10, it will use layout-v8.
Related
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
I would like to build two different versions of my app using different android:minSdkVersion. In the lower sdk version I would simply omit the function that needs the higher sdk. (Disable the user interface item that needs the higher version)
I understand that I can "Publishing Multiple APKs with Different Filters" (for different sdk versions) (http://developer.android.com/guide/google/play/filters.html#MultiApks). In my code and AndroidManifest.xml file I would need something like "#ifdef", but this doesn't seem to work in xml files.
What would be the best approach to minimize (error-prone) manual changes for each rebuild?
Or is there a way to specify the lower sdk version in the manifest and nevertheless use the methods of the higher version when available, i.e. dynamically enable the call to the method depending on the current android version?
Yes, you can create one APK with conditional blocks that execute different statements depending on the API version of the device. For example, you can check the value of android.os.Build.VERSION.SDK_INT and take appropriate actions.
I've been trying to figure this out for a little while and I'm sure I've seen something on this before either on the Android dev blog or SO but it's fleeing me currently. I was wondering the best way to target different API levels with a single APK, if possible.
For example, I would like to be able to take advantage of the new Ice Cream Sandwich features and UI patterns but also want to support Gingerbread and below. Would the best solution be to make different projects with a similar code base but rewriting specific features to use the specific features and posting multiple APKs in the Market or could I use a form of reflection to scale back?
Any help would be greatly appreciated, thanks! Mainly, I would like to know if multiple APKs are necessarily bad or if I'd be better off with a single APK.
This is the canonical blog post for backwards compatibility: http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
ICS -> Gingerbread can get complicated if you're using custom themes or want to use fragments.
I'm in the process of writing an article for developer.android.com that goes into more detail about this, but the short version is:
Create a res/values-v11 and a res/values folder. The v11 folder should hold themes which inherit from android.theme.Holo and the non-v11 folder should hold themes which inherit from android.theme. If you don't use custom themes, you can skip this step -- setting targetSdkLevel >= 11 will do all the magic for you.
Use the support package to provide Fragment/Loader support on pre-Honeycomb devices: http://developer.android.com/sdk/compatibility-library.html
I have a published app for Android 1.x and 2.x, and now I want to make it support 3.x.
But Android 3.0 has massive API change, especially on UI, thus if I want to make one app compatible to 2.x and 3.x, the code will be ugly and package file will be huge.
On the other hand, if I make another app for 3.x, then I need to maintain two copies of their common codes. That's really annoying.
What should I choose, or does anyone have a more smart solution? Thanks!
If you package them together you could still maintain everything separately - For example: put a prefix in front of every layout and class for 3.x, such as honeyMain.class, and honeymain.xml
Or you could do it a way that makes more sense for you.
Or keep them partially together.
It WILL make your app larger, but then when 15 people with 3.x download it and 60 people with 2.x download it, you get 75 downloads, instead of 15 for one app and 60 for the other. The 75 cumulative will look better on the apps over all ranking on the market.
On the other hand, if the 3.x is really ugly or FCs, then negative ratings will impact both 2.x and 3.x, but that is easily controlled for by testing, testing, testing.
Also, I personally hate managing code for two different apps. It's overly repetitive.
So, my recommendation is to package them together.
Make use of resource qualifiers, e.g. -xlarge, -v11, etc.
Use reflection where necessary or other techniques to avoid pulling in stuff not supported by API level.
Use the compatability library, that way you can fragmentize your code regardless, avoiding duplication, and with little effort handle different screen sizes.
See providing resources
See multple screens
See compat lib
Right click on your project and select "properties",select "android" from window,and which type of version you want check it and apply
On this page: Is given on this page: http://developer.android.com/resources/tutorials/views/hello-listview.html. , the below tip is given.
Tip: You can use list item designs
provided by the platform instead of
defining your own layout file for the
ListAdapter. For example, try using
android.R.layout.simple_list_item_1
instead of R.layout.list_item.
However, is it safe to use "simple_list_item_1"? Is it guaranteed that all platforms will provide a list item with this id?
Edit - yes, apparently these are bundled with Android and they should be supported on all platforms.
In any case, I believe what happens is that they are copied from the SDK into your project when you reference them.
As Felix pointed out, they are included on the device itself and they are considered to be part of the API.
You can see layouts available within the SDK on the Android gitweb. For example, simple_list_item_1.xml.
Those layouts part of the SDK and should be included on all devices.