I'm using DragShadowBuilder in my application. http://developer.android.com/reference/android/view/View.DragShadowBuilder.html
In AndroidManifest, I've set the minimum supported API level to 8. However, DragShadowBuilder was introduced with API 11. Eclipse usually warns me when something is below the minimum API level, but it seems fine with me using DragShadowBuilder. Should I be included some support library or something along those lines to ensure that the code runs on older versions of Android?
No your code may not run in older version of Android. You may want to write Drag logic of your own using AbsoluteLayout, if at all if you want to achieve drag feature in older versions. Hope it helps
I believe this is a bug with Eclipse. I would suggest that you simply make the minimum supported API level to 11. AFAIK, you could always create it to support API 11 first, and then try to recreate it with a new project and by adding the library you want.
I have tried this and if you were to create a new project, set it to a lower API, import a "Drag and Drop" like library, and try to write the code for it, you will most likely get an error saying that it won't work and/or that the Drag and Drop function is set for API's 11. If you Clean the project after, the error might "disappear" go away but once you try to run the application, it will reappear and say that it can't run with errors.
It is weird even though you have the library embedded with the code. Perhaps you could try renaming the classes and such if the machine can not differentiate which "DragEvent" you are trying to call forth.
I just looked through the published contents of what is in the library and I didn't see anything about DragShadowBuilder.
You can check the contents of what's in there at http://developer.android.com/tools/extras/support-library.html
I also looked in the source some and didn't see anything mention about it. How do I attach the Android Support Library source in Eclipse?
If there is no backwards support then you are basically on your own for this. You can also look at the source for DragShadowBuilder and try to recreate that in your application.
Related
I am new to Android development and I am following the training at http://developer.android.com to get into it. I am confused whether I do use the support library or not.
To make it clear: I do not need to support APIs older than 11.
Situation: Adding Items to the ActionBar I had to use my own Namespace to make it work (app:showAsAction="ifRoom" instead of android:showAsAction="ifRoom"), which is a normal behaviour using the support-lib, am I right?
First Question: Why am I using it? I did never activate it on purpose!
Second Question:
Is it normal that I can use both getActionBar().setDisplayHomeAsUpEnabled(true); and getSupportActionBar().setDisplayHomeAsUpEnabled(true); to make the "up"-functionality work? I thought the first one wouldn't work if I used the support-lib?
I'd be glad if one of you could help me. I don't want to mess around with these basics so I'd like to know what I understood or configured wrong.
EDIT: My "uses-sdk" in the AndroidManifest actually looks like this:
<uses-sdk android:minSdkVersion="11" android:targetSdkVersion="19" />
To answer your first question, depending on how you created your project in the first place, it was probably enabled for you automatically. There are lots of other things in the support library besides ActionBar, so even if your minSdkVersion=11, it's probably still a good idea to use it.
To answer your second question, yes, it's normal that both methods work. Framework methods are not disabled or removed when you enable the support library. They will still work as long as they are supported by the Android OS you're eventually running on. For example, if your minSdkVersion was 10 instead of 11 and you tried to run the app on a device running Gingerbread, it would crash on the getActionBar() call.
In your case, you should use the framework method (getActionBar()). The documentation for ActionBar says:
This class is included in the support library for compatibility with
API level 7 and higher. If you're developing your app for API level 11
and higher only, you should instead use the framework ActionBar
class.
The best way to know whether you need to use the support library for a given method or class is to refer to the documentation for that class and pay attention to the "Added in API Level ?" notation. Here is the documentation non-support-library version of ActionBar, where you can see that some methods were added after API 11. If you need any of those methods, you should use the support library.
Also, as I said before, there other things besides ActionBar to consider in your app. GridLayout is an example. It was added in API 14, but it also exists in the support library for backwards compatibility. If you want to use GridLayout, you should use the support library version of it.
For my new assignment, I wanted to use some library that can provide a "Posterize effect". I found many library like Aviary SDK and jhlabs, Yes, these are easy to use, but these making the code heavier. SO I keep searching for Android's API itself which can do the similar task. And after a lot of RnD, I finally found one my time saver class EffectsFactory which provides the same as I wanted. I applied it in my assignment also. But the bad thing it was added in API level 14, And my app should be compatible with at least API level 8.
So, My question is,
Can I use EffectsFactory class for lower version? If Yes then How?
Or, If No, Then Do we have any API in Android SDK itself which do similar to effectfactory ?
Please avoid referencing any library or NDK's open cv library.
No, there is not an Android API that will posterize an image below API 14. Even above API 14 EffectsFactory may not work, as it says in the Android documentation:
Some effects may not be available on all platforms, so before creating a certain effect, the application should confirm that the effect is supported on this platform by calling isEffectSupported(String).
However, you could easily make a lightweight solution yourself. Posterization is a simple process. For example, the code behind JHlabs' posterize filter is less than 50 lines (and most of them are sugar). In your shoes, if using a 3rd party library was out of the question, I wouldn't hesitate to write my own.
Edit: If you happen to be posterizing images your app takes from the camera, there is also Camera.Parameters.setColorEffect(), but again this is not supported on all devices, as it says in the documentation:
For example, the application should call getSupportedColorEffects() before calling setColorEffect(String).
My old android project(with sdk 2.2.3) cannot be compiled with sdk 4.2.2, because it seems that 4.2.2 does not have "android.webkit.CacheManager".
So how would I solve it? What can be its replacement?
It seems that CacheManager was deprecated in API level 11, and the following commit in Android 4.2.1_r1 shows that many of its APIs were removed.
A basic implementation of a replacement would be to save the file locally, along with a tag specifying the last used time. Then, after a (certain) period of time, check if the asset is too old and delete it, if true.
This article and this article seem to provide with example implementations. There are also plenty of libraries, as this one.
I'm creating an app that uses the clipboard manager. Since the way of working with this has changed since API level 10 but I still want it to work on all versions, I would like to use both APIs if possible. I would then like to code some kind logic like this:
if androidVersion < 10
use code x
else
use code y
Is this possible?
When I create a project in Eclipse, it either gives me the Android 1.6 jar file or the Android 3.0 jar file depending on the min SDK version I selected. My question is if it's possible to import and use both and if so how? Or will I simply need to make separate projects for different versions? Thanks.
Is this possible?
Sure. Use android.os.Build.VERSION to find out what version you are running on and use the appropriate code based upon that.
If you are supporting Android 1.x, the story gets a bit more complicated.
When I create a project in Eclipse, it either gives me the Android 1.6 jar file or the Android 3.0 jar file depending on the min SDK version I selected.
No, it does not. It gives you 1.6, 3.0, or whatever based on the build target you selected. By default, it also makes the android:minSdkVersion match that, but you can change that, so the minSdkVersion is the oldest that you are willing to support and the build target is the oldest whose APIs you are directly referencing.
My question is if it's possible to import and use both and if so how?
You do not need to import both, and you can't do that anyway.
Or will I simply need to make separate projects for different versions?
You do not need separate versions.
I'm developing an Android app which will target 2.1/2.2 devices, so I have my project set up to use the 2.2 SDK (API level 8), but allow for installation on devices with at least API level 7.
The problem is that during my daily development, I'm not always paying close attention to which API level of the methods/classes/constants that I'm using, which makes it very easy to break code on older devices. I have got dynamic classloading working, and as much as I dislike having a ton of extra factory classes and interfaces in my project, I'm willing to deal with that solution. Currently, the only way I have to check an older API level is to set my project's settings to the given level, rebuild, see what breaks, and then refactor. It's quite a pain.
What I would really like is the ability to scan my code and check compatibility for a given API level without changing my global project build settings. Is there some easy way to do this?
Android API Analysis Plug-In for Eclipse:
http://adt-addons.googlecode.com/svn/trunk/apianalysis/
Ok, so based on my research and the comment by #CommonsWare, there's no static analysis tool or some other easy way to do this. Shucks.