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.
Related
I am building an app using Android Studio version 2.1.
I am testing it on a Lollipop device and a marshmallow one.
I was suggested to use support libraries, and I would like to make sure that it runs smoothly on Jelly Bean devices too.
I have looked it up, but can't quite understand if using v4 o v7 guarantees Jelly Bean compatibility (I am assuming it does, but not sure).
This is the first app I am developing and I just realised that I mistakenly used support versions in some activities, and native in others. I am fixing that.
Is there any tool which analyses all the code and then determines the earliest Android version that can run my app? Possibly giving suggestions on changes to make the compatibility broader?
All the answers I found so far confused me, they possibly require knowledge I don't yet have. I am a Java developer quickly trying to put together an app for a start up.
The minVersion in your manifest or gradle file determines the minimum SDK version that can use it. If you lower that number, any API call that doesn't exist on that version will cause an error or warning. Fix them.
BTW, KitKat is 19. So to have KitKat as the minimum SDK you don't need to use any support versions most likely. The best reason to do so is that it will provide a more consistent interface going forward- fewer version specific oddities when using support versions.
So, consider the common scenario where you want to build an app using the latest Android APIs (up to 18), but you must also provide support back to Android 2.x.
This is the case for my current app. I had set my minSdk and targetApi levels accordingly and started work.
During testing on various device I noticed some crashes due missing functions/apis on older devices. I had to visit each bug and provide a workarounds on a case by case basis. A real pain as all these were only discovered during test.
So, my question is what is your process for developing in Android with this in mind. I haven't really explored lint but could that help point out any possible issues.
Thanks.
I haven't really explored lint but could that help point out any possible issues.
It will. Lint will report to you anything that you use that is newer than your android:minSdkVersion but is acceptable to your build target.
Lint will generally report this automatically for Eclipse, though you may want to run Lint manually from time to time, as sometimes it seems to miss some stuff. Lint is also available for command-line builds, and I presume that it is (or will be) integrated into Android Studio.
You can read more about Lint in the developer documentation.
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.
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.
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.