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.
Related
I understand that I can use support libraries to add elements that aren't natively available. However, does the newest SDK version (Lollipop, for example) use these support libraries as well, or does it use native elements? E.g. if I run the app on a Lollipop device, will it use native or support elements? I'm asking because, when editing source code (in Android Studio), I'm only editing one version of the file, I can't, for example, chose to create one file for ICS, and other for Lollipop, so how does the system know which elements to use?
However, does the newest SDK version (Lollipop, for example) use these support libraries as well, or does it use native elements?
The Android framework does not use the support libraries.
if I run the app on a Lollipop device, will it use native or support elements?
If I am interpreting what you mean by "native", it uses native element. The Android framework does not use the support libraries.
I can't, for example, chose to create one file for ICS, and other for Lollipop
You are certainly welcome to detect the running API level and elect to instantiate some level-specific class. You will see this used occasionally in the framework, though it is much more common in the Android support package, particularly for ...Compat classes.
so how does the system know which elements to use?
There is only one version of Android per Android device. Hence, there is only one set of framework "elements" for the framework to use.
Some aspects of the look of the widgets are driven by themes, and each Android version ships with support for whatever stock themes existed, going back to Theme from API Level 1. If the developer has chosen to use a different theme based upon running API level (e.g., use Theme.Material as a base on Android 5.0+ but use Theme.Holo as a base on Android 4.0-4.4), that is driven by resource set qualifiers (e.g., res/values-v21/styles.xml).
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'm planning on writing an app and building against 2.2 Froyo (API Level 8). However, I want app users of 4.0 ICS to experience the app with the ICS user interface.
Currently my approach is to have the default activity of my app sense the version of the Android device.
If it is less than 4.0, use XML views written for Gingerbread and Froyo and, if it's 4.0 or higher to use ICS XML views. This however seems a bit haphazard and I'm not sure I can manage the separation of version views effectively.
What approaches, tools, and ideas can I use to help me make my app? Is it even something I need to consider? Is my idea of the view separation above correct? Do I have alternatives I could use instead?
Cheers!
If you just want to apply different resources for different OS version, you can let system do it for you by putting your resources into different resource folders with the "v" qualifer. Such as "layout-v8" folder for layouts used for Froyo and "layout-v14" for layouts used for ICS. I did not try this but from the document, that's what it supposes to do.
The Crunchyroll app (an anime viewer) has separate activities and layouts for Froyo vs. Honeycomb/Google TV, defaults to one or the other on initial startup, and thereafter allows the user to declare a preference for one or the other. I'm not affiliated with CR, but I use and have studied the app. One problem the app has, which may be encouraged by the level of separation it has between the two targets, is that the pre-Honeycomb interface has many features, and continues to receive updates, that the tablet/TV interface is only promised.
As for tools, you can use later features while targeting an earlier OS with the SDK's support package, which backports features (e.g., fragments) appropriately.
I currently have a application targeted at android 2.3 (api level 10), but went thinking that probably people using android 2.1/2.2 or older won't even be able to see the application in the market.
So I thought that using api level 3 would be the best to use, but I don't know if this will maybe make certain elements in my app work less good, and probably buggier, since it actually uses old android code. Is there a good way to find out which API level I should use, and also, how do I convert my application to that level?
You can find a breakdown of the different versions of Android in use here. Currently, if you target 2.1 (API 7) you'll only miss out on about 3% of the market. Targeting 2.2 will miss just under 20%, or a fifth of the market.
As for converting your app, you can check what API level things are available for in the Android Reference. You'll note a checkbox and dropdown menu on the top right of the browsing area that allows you to filter by API level - that's one way to help converting. The other is to set the target and minimum SDK versions which will help Eclipse know what to complain about in your code. The easiest way to see if something needs conversion, however, is to emulate and test.
EDIT: The API level dropdown moved from the top right to the top left, over the list of APIs.
This graph may help you make up your mind.
It is good to look at backward compatibility and in general, you should compile your application against the lowest possible version of the platform that your application can support.
You can determine the lowest possible platform version by compiling the application against successively lower build targets. After you determine the lowest version, you should create an AVD using the corresponding platform version (and API Level) and fully test your application. Make sure to declare a android:minSdkVersion attribute in the application's manifest and set its value to the API Level of the platform version. Good luck!
If you have
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="10"/>
then it will appear right down to 1.6, but make sure you don't use antyhing that they don't have in their API
edit: Don't bother with 3! :)
I started out developing for 1.5, but soon realized that only a small percentage of people still run 1.5. I generally develop at the 2.1 level, and leave it at that (unless you need features at a higher level). To change it, open your project properties, and while I don't have my environment open, there is an Android option where you will select what API level you want to target.
The Best API Level is contains follows
1) The best API covers 100% market but all are not prefect so our app should be covered at least 90% with all devices .
2)We have to care about backward compatibility issues and our code would adapt itself for upcoming versions.
3) Using the new Android SDK is a requirement to use any of the new APIs added in that level. It should be emphasized ... It is ultimately a business decision on whether supporting an additional 3% of devices is worth the development and testing .
4) check out this link https://developer.android.com/guide/practices/compatibility.html#defined
5) Finally choose the best API you will find best API
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.