I saw this class before but cannot use it and I don't see many sample that use it. What exactly is the difference of NotificationChannelCompat from regular NotificationChannel?
NotificationChannels are only supported on SDK 26+. So the idea is that NotificationChannelCompat gracefully handles the situation where you call methods related to NotificationChannels on unsupported SDKs. Rather than crashing your app, it simply does nothing or returns an empty list on an unsupported SDK. So this avoids the situation where you need to handle notifications differently on SDK 26+ and SDK < 26. In practice, this isn't a big deal so nobody bothers with it.
Related
I like to use the findAll/ findAllAsync method in android.webkit.WebView. findAll is deprecated and Google suggests to use findAllAsync which requires Jelly Bean or higher. However, I like my application to support 2.2+. I tried to the following, but I get warning for findAll (deprecation) and error for findAllAysnc (need to increment minimum SDK version):
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN) {
myWebView.findAll(query);
else
{
myWebView.findAllAsync(query);
}
What's the best way to deal with this? Should I just use findAll and ignore the deprecation warning?
I believe the answer goes in several ways:
What are you setting as min SDK version and target SDK version in the manifest ?
Same question, but in Eclipse (or whatever IDE you're using) for Android build API properties ?
(I'm answering as if your question is "how do I get rid of the android lint warning", rather than "how do I fix the warning correctly" .. )
Use findAll and if the warning is really too annoying add a #SuppressWarning("deprecation") annotation to suppress it explicitly.
One problem with this is that when you use this annotation on your method you might miss other deprecated calls as it will apply to the whole method.
There's a very interesting and powerful way of doing what you want, and it is called reflection. From the Oracle's Java documentation:
Reflection is commonly used by programs which require the ability to
examine or modify the runtime behavior of applications running in the
Java virtual machine. This is a relatively advanced feature and should
be used only by developers who have a strong grasp of the fundamentals
of the language.
In short, reflection allows you to find out if class is defined, you can find out its methods and properties, and invoke a class' functionality... all at runtime!
I have an app that needs to handle the audio focus on Android 2.1 devices but the Audio Focus is not available for those versions, so I use this technique. It is, by the way, a bumpy road. I would suggest reading carefully the documentation and try to follow some examples.
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).
how detect deprecated method in android application? which resource is needed, for example class files..
My problem is the derecated error is reported in local eclipse but not reported in server for same source. Then what should I check for this problem? please help
Your problem is not really clear.
If Eclipse says the method is deprecated, then it is.
The documentation often tells you what is the new and better way to do what the deprecated method did.
In android doc (http://developer.android.com/reference/packages.html), you can choose the target version on the top of the list on the left, so you should check the doc for the version you are targeting.
It might be acceptable for you to keep a deprecated method if you absolutely need it and want your min version to be an old one. You can also check the support package that provide you compatibility functions of newer versions
Extending #Toaster a bit, deprecated functions are those that are currently supported but may not be supported by future versions. In simpler words, current android versions such KitKat (4.4) will be able to run that function but another update may find that function doesn't exist anymore.
The eclipse gives us warning not show problem that this particular version is working fine now but may be removed in the future releases, so change that function with a function that is not depcrecated and will certainly be present in future versions so that your app may work properly even in case or an OS update.
As far as problem showing the deprecated functions on your server is concerned, i don't know it. Although you might not need it, if you upgrade your functions, but if you do then post a different question and i am sure someone will be able to help you. Happy Coding!!!
I have been making a project on Android 4.0 and I have faced some deprecated types for the newer versions of Android. A black line has occured on the name of the deprecated things. However, in spite of the black line and the deprecation warnings, I can still use those deprecated classes and project is running successfully. I got confused about the deprecation. If they are deprecated how can I still use them and what does deprecation mean exactly? If I use the deprecated classes in my project, what can be the possible disadvantages that the project users can encounter?
Thanks for reading.
Deprecated means that they are likely to be removed in a future version of the platform and so you should begin looking at replacing their use in your code.
If they just removed the types then builds would break and people wouldn't be happy!
In terms of the effect they will have on your application's users, there shouldn't be any effects at all. However, when you come to update your software to the next version of Android you may find that the deprecated types are no longer there and your build will break.
Wikipedia has a good article on it here: http://en.wikipedia.org/wiki/Deprecation
Long story short only use the deprecated method on systems running too low of an API to support the updated method. This way you can support a wider range of devices while only using the deprecated methods when you have to to support the older devices. Code example below.
int sdk = android.os.Build.VERSION.SDK_INT;
if(sdk < android.os.Build.VERSION_CODES.JELLY_BEAN) {
setBackgroundDrawable(); // deprecated method for older devices
} else {
setBackground(); // updated method for newer devices
}
CHEERS :)
Don't forget that there is probably a reason for these classes to be deprecated. It might affect the security or stability of your app.
If you find out there is a bug or a flaw it will probably never be corrected.
Also checkout what classes they advise to use instead, if any.
Concerning your worries about newer Android versions:
Android versions are backward compatible
Confirmed here by an Android engineer in a topic about an other deprecated class. Therefore you should be able to use your app on newer versions.
If you want your application to be compatible with older versions of android while using a "new" class in your code, check this related topic.
often some types of classes are deprecated but you can still continue using them because to update applications and implement those classes you would have to modify the source code.
But if you find that there are unused classes is better than in coming soon applications no longer use them, personally I spend it with ClipboardManager and use applications where previously it still works.
I see quite a few good old useful methods or even entire classes being "deprecated and obsolete".
But code that used to call those methods continues to work. So, what does this mean to me, as an Android applications developer?
Continue using this method as long as I want, because newer SDKs
will always remain backward compatible.
It will work as long as I build for older targets (e.g. API 8), but
if I build from API 14 up, the compiler will refuse to complete
the build.
Both (1) and (2)
Other?
This is especially confusing when no alternatives are provided, as in the case of WebView.PictureListener.html#onNewPicture.
It usually means that there's either a better way of doing things or that the deprecated functionality had some irreparable flaw and should be avoided. You can usually keep using deprecated methods, but you are advised to either switch to some new API (in the first case) or find some other way of doing what you want (in the second).
Regarding onNewPicture in particular, the entire PictureListener interface is deprecated. There's no sign of what, if anything, is supposed to replace it. A comment by #CommonsWare in this thread is food for thought:
It is conceivable that upstream changes in WebKit are driving the deprecation and that support for PictureListener might be totally lost in some future release.
I would go with 4:
It will basically tell you that the use of the method or class is discouraged; it is NOT 100% that they will keep backward compatibility (they can decide to not include that method in future releases), so you should try to use the replacement of the method or class. This is sometimes not possible to use the new methods (for instance, if you want to support devices running older versions).
Some other times it is actually possible. For instance, the showDialog method is now deprecated and they recommend to use DialogFragment class. You can achieve that even in older versions of Android by using the compatibility library.
Deprecated methods are not guaranteed to remain backwards compatible. They might remain in there for a few more releases just to give everyone a chance to migrate away from them before the developers remove them. The fact that they're deprecated means that the developers think that there's an easier, faster, neater, or otherwise better way to do whatever that class or method does.
It's probably better to change your code to use a non-deprecated interface now, since if you wait and it does get removed, your users will see crashes and errors.
Even when they are deprecated, they may compile but not work. Google has decided to delete various functionality at the low OS level.
Case in point. Google, at android release 2.3 deprecated many but not all method API's that allowed call recording. They compile OK but do not function since Android 2.3 and forward on any android phone device, or tablet with phone capabilities.
As an example for a deprecated interface that has been removed in a later API level, consider the org.apache.http package: It has been deprecated in API level 22 and removed in API level 23.
Of course on actual Android devices, the classes contained in that package will still be available in the system libraries (otherwise, applications targeting an older Android release would no longer run on that device).
They are however not available in the SDK anymore, so compilation will fail unless you either change the target/build SDK to an older version (or manually include the deprecated classes).
If Google were really determined to discourage use of those libraries, they could modify the implementation so that the affected classes check the target API version of the running application and complain and/or throw a runtime exception.