I want to build an application where the front camera of the device is used to project the current image to a SurfaceView. All the tutorials I found so far implement this by using a Camera object from the android.hardware package.
This method, however, seems to be deprecated. When trying the 'new' preferred way to implement this feature following the Android documentation, I get the warning it can only be used with API level 21, which is pretty useless.
So I would like to know the currently preferred way to implement camera functionality in an application. Or is there maybe some support library for API levels lower than 21?
Thanks in advance.
Deprecated interface does not mean you should not use it. It means you should know that it will be phasing out in the future.
As a general rule, it is better to use a newer interface if possible, in order to avoid the need to update the software later.
The fact that API level 21 does not yet have a large enough market share means that you are probably better off using the old interface for now, and keep in mind that in a year or two, you may need to update the implementation.
I think you can implement the camera function in both sets of API and check the device`s build version first then decided to call which one implementation.
eg:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP){
openCameraNewAPI();
}else{
openCameraOldAPI();
}
Related
I am going to be making a camera application, really simple, just add some new interface to the camera app, so nothing fancy, and I was wondering if I could still use the old android.hardware.Camera api since it is simpler and easier to use.
Yes, you should have no problem with this portion of your project.
It might. But...
The android.hardware.camera2 package provides an interface to individual camera devices connected to an Android device. It replaces the deprecated Camera class. - Source
It was deprecated as of API 21
I'm trying to format numbers to a default country code, and I know how, but when I do it, an error appears saying this is only for API 21. I am targeting API 16. If I use the old method, I get an error saying the method is deprecated? How can I use that method on API 16?
Thanks!
The docs: http://developer.android.com/reference/android/telephony/PhoneNumberUtils.html#FORMAT_NANP
Following example with deprecated method as mentioned by #qbix.
A good practice is to check the level of the sdk to use the correct method:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
yourTextView.setText(PhoneNumberUtils.formatNumber(yourStringPhone, Locale.getDefault().getCountry()));
} else {
yourTextView.setText(PhoneNumberUtils.formatNumber(yourStringPhone)); //Deprecated method
}
Your link to the documentation doesn't identify the format methods you are referring to. I'm guessing the deprecated method is formatNumber(String source).
While the general definition of "deprecated" includes the possibly of the feature being deleted at some future time, it has been the Android policy to not delete items from the API that will break existing code. An example of this is AbsoluteLayout, which was deprecated in API level 3, and yet remains a part of the API. In Android, "deprecated" is an indication that there is an alternative, better way to achieve the same result, and you are strongly encouraged to use it instead (if possible).
Here, the improved alternative method is only available in API level 21. To support devices with lower API levels, you can safely used the deprecated method. It's not going away anytime soon.
Another option is to examine the source code for PhoneNumberUtils to see if you can use pieces of it to create your own formatNumber() method that does what you want and supports API 16 -- probably not worth the effort.
This works for me for all version, may be because of backward compatibility support:
yourTextView.setText(PhoneNumberUtils.formatNumber(yourStringPhone, Locale.getDefault().getCountry()));
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).
I need to call a method in Android SDK v9 while maintaining compatibility with older versions.
The Android developer blog recommends using reflection or wrapper classes, but is that all really necessary? Why can't I just do this?
if (Build.VERSION.SDK_INT >= 9)
callNewMethod();
It seems to me this will work due to Java runtime linkage, since I am building with SDK 9. Is there anything wrong with this approach?
Thanks in advance...
No not at all. Actually it is promoted as best approach while developing applications with wide API level target.
Reflection class is the most solid way, if you have no idea what the class content is and the method exist. But in Android, you know what is supported and what is not supported.
As a result, i didn't like the blog you gave :p
Not necessarily a better answer, but the check you are doing there assumes that the builder of the OS/ROM set that value correctly. If it was not set correctly, then you may try to access a method in SDK 9 that really isn't there. Using reflection is the only way to be 100% sure you do not generate a runtime error by trying to call a non-existent method.
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.