I have an app that works fine in Android 1.x but not in Android 2.x
i need to do things different based on the version of Android the app is running on (querying contacts).
is it possible to have two separate methods within the one app that i can choose based on the version of Android the app is running on?
many thanks
Ed
Use reflection and class loaders. See this post on the Android developers blog: http://feedproxy.google.com/~r/blogspot/hsDu/~3/9WEwRp2NWlY/how-to-have-your-cupcake-and-eat-it-too.html
Edit:
Thanks to CommonsWare for pointing out a sample project which uses both the new and old contacts content providers and conditional class loading: http://github.com/commonsguy/cw-advandroid/tree/master/Contacts/Spinners/
you can get the sdk version with BUILD.VERSION, check
How to retrieve the android sdk version?
however, i am wondering what function is runnable on 1.x and not available on 2.x.
did you use any of the internal classes?
I really suggest that you fix the function issue, rather than doing different things with different versions, if it can be avoid.
You can read out the OS version of the device.You can have different methods in your app depending on the device OS version, but you can only compile against one SDK version. Therefore, you need to choose the minimum, which at the moment currently is 1.6 (I think 1.5 is rarely used anymore)
see:
http://developer.android.com/reference/android/os/Build.VERSION.html
developing for multiple screens / devices:
http://developer.android.com/guide/practices/screens_support.html
The Business Card example that comes with the latest Android SDK was a big, big help. I recommend it to those that like me might not be a professional full-time developer. Thanks everyone for your kind input.
Related
Iam an android beginner. I couldn't understand when we have to use imports statements starting with android.support.content and android.content?
I used content as an example.
The Support Library is generally used when you want to easily support a wider range of OS versions with less version specific source - with it you can use features introduced in higher version of the OS on older platforms without having to worry and check whether this platform has that feature and do something in case it doesn't.
For more information: it has already been discussed and this was a part of the answer, there are many more and they are useful so read them if you want to know in depth how,why and when. Hope this helps. Support library android
I created an Application about 1 year back on Android version 2.1 and made available to all the other versions of Android. At that time Android mobiles with versions 2.1, 2.2 and 2.3 were very common.
So I tested my application on all available versions and there was no issue.
Now Android with versions 4 has become the hottest mobile in the market. When I test my application on the versions of 4 it started crashing.
My question is how to ensure that the application that we develop now should be compatible with the later versions which are not available now ?
How to write applications [OR] what are the things that I need to consider so that with minimal code changes it should work on all the versions ?
By testing your applications on the new versions. I'm sorry that is really the only half fool proof solution. The versions get out in plenty of time to test on the emulator so there really isn't any excuse.
My guess is that you've done some nono like downloading data on the main thread. That isn't allowed any longer. Your application then don't get the data and you get a bunch of null pointer exceptions (which you'd also have gotten if data access had been missing).
There is no perfect answer. Android will forever be evolving and changing. Hopefully it will continue to do so for the better like it has been. Google forsaw this issue, which is a small part of the reason they made it so easy to update an app. you will just have to update as it comes. it is its greatest strength, that it can always change, grow, and get better.
I have developed some application in android 2.2. I have read http://developer.android.com/sdk/android-4.0-highlights.html. But I need to know what are the new features in android 4.0 against 3.0 and 2.2. If there will be any such tutorial which will give details about android features by comparing two old version and latest version, then that will be more easy to remember the feature wise difference between any two releases. Is there any such tutorial which gives version wise comparison between android features.
I don't know of a pre-made API-level comparison (although a change history would include it).
You could always run any of several JAR diff tools, like the one in depfind (details in the user manual section) if you're looking for a summary view. There are a few others, but I'm not as familiar with them.
why don't you just download the code tree, including tags and mount this locally with git/svn/other and use the graphical tools of those csm to explore the code, docs, etc?
I know that it's a bit buggy, but i use eclipse EGIT for that.
I have an app which I want to run on as many Android phones as possible. My current solution is to just compile it with the newest version and doing the critical code in sections that will only be used on devices with the correct Android version. This worked fine until I started using Android 2.2. Now running the app on older phones gives me an error.
So I am thinking about using reflections, this would mean however that I would be compiling for version 1.5. So my question is will I suffer from any disadvantages? Apparantly compiling for a different version makes a difference as I can see at my error. So would I for example loose the JIT support or something?
Some insight from you guys on this topic would be great! Thanks in advance.
I am sorry if I'm telling you obvious things, but are you sure that you really need reflections?
You will have run-time exceptions when you try to instantiate class that uses higher version of SDK then one installed on device/emulator.
To avoid it you need to check for SDK version in run-time.
Example:
//check for multitouch support (Android 2.0+)
inputSystem = android.os.Build.VERSION.SDK_INT < 5 ? new InputSystem() : new MultitouchInputSystem();
There are no inherent disadvantages of using Java reflection to support different SDK's. However, there is a more elegant way described here that uses lazy class loading that is more maintainable. This I feel is a more robust way of handling different SDK support.
Will Titanium work properly on all android sdk versions (1.5, 1.6, 2.0, 2.1, 2.2).....
Based on the research I've done, yes, I believe so. I'd recommend trying it out.
Yes it is.
But be warned that while Titanium has its strengths, it also has its weaknesses (ie; memory).
If you're working on a project for a client or are just starting your journey into mobile development, I would recommend learning how to code a native application. At least that gives you some options if you run into troubles. I've been burned a couple of times.
Titanium works with all android SDKs .You just have to make some changes to make it work with all SDKs. Titanium works with sdk 2.1 and below without any changes. But in order to make it work with 2.2 and above you have to add a symbolic link of adb file which is in
platform-tools(source) folder to tools(target).
Occasionally the platform-level support for a particular feature is different between the iOS and Android. For instance, the underlying audio support is significantly better on iOS; many features are simply missing on Android (we eventually patched them ourselves).
In addition, the way that the underlying platform's primitives are wrapped differs, so that code that is correct Javascript will result in incorrect Java on Android. An example we came across was related to the treatment of null and undefined when used with the Ti.App.Properties.setXXX functions. This issues are becoming fewer and farther between, as mentioned, but there are still issues not just related to UI.
I suggest you make a point of continuously developing and testing on both platforms; you'll find incompatibilities (mostly related to leaky abstractions) and their workarounds more easily that way.
Well it works great for the cross platform Execution.
The Only problem is that when user want to compare the iphone version & Android Version by developing same code.
iphone is excellent as per its gesture supports & fine UI works.While Android is still improving the terms.
So you should firstly check your terms and requirement then Go a head with Titanium. OtherWise
Appcelerator consistently working around all the native support as well as common features.
you need to find the possibilities in proposal for the Framework.it will be great approach & future perception as well.