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()));
Related
does TargetApi mean that code must be called under a specific version or
must be called greater than or equal specific version?for example
TargetApi(23) means that use for (23 and below ) or (23 and above)?
Target Api 23 means that the annotated method should run only on api 23+ devices. You should use it with IF check for api level of the device. If your app's minimum api level is lower than 23 consider providing a method for older devices.
From TargetApi docs:
Indicates that Lint should treat this type as targeting a given API level, no matter what the project target is.
It's used purely for the linter. Instead of using targetSdkVersion specified in your build.gradle, it will use this API.
When should you use this?
Perhaps when you're using a deprecated API, but you don't want the linter to continue warning you. You explicitly tell the linter, I know that this is deprecated but I don't care, I am using it as if I was on an older API level. You might (should) also add a comment nearby.
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();
}
I am developing an app which has to support at minimum level 10 sdk. Today, I was coding when I came across a method setLayerType() which I need to use. But this method is introduced in API level 11. So, I used a workaround and used Reflection to use this method.
So, my question is, won't my application still crash on device which runs on API level 10?
This question came to my mind because, even though I am using Reflection here, still, I am calling a method that was introduced in API level 11. Will this method run successfully when I run my app on Android devices that run on API level 10 or will it crash?
As stated in source, the method will run independent of OS level. But, why should it run successfully on API level 10 device which is still using Android.jar of API level 10 and that file doesn't even contain this method?
I tried to search it but couldn't find an explanation.
P.S. I wanted to test it on a device with API level 10, but as building full app will take some time, so it is not possible to test app on API level 10 device right now.
No, of course the app will crash if you call a method that is not present in its API level. This is true whether you call by reflection or not.
The point of reflection is that you choose whether or not to call it based on the API level. Compare http://developer.android.com/reference/android/os/Build.VERSION.html#SDK_INT to http://developer.android.com/reference/android/os/Build.VERSION_CODES.html in your code and only proceed with the reflective call if the SDK number is high enough.
The point is that you isolate code with bytecode references to any method or constant or class that's not present in all API levels into a separate class that is only loaded by reflection.
Here's an example of some utility code I created just to manage this kind of thing; it loads one or the other implementation of an interface based on API level:
https://code.google.com/p/zxing/source/browse/trunk/android/src/com/google/zxing/client/android/common/PlatformSupportManager.java?spec=svn2361&r=2361
EDIT: #FD_'s answer works too which surprises me. Reflection is safer, but much more code. And it seems like the reflection approach is in fact unnecessary on recent, if not all, Android JVMs.
You don't even need Reflection for that. Just specify your target sdk as high as possible, and your min sdk as low as it is now. Then, before calling a method that was introduced after the min version, just check which api version your app is running on:
if (android.os.Build.VERSION.SDK_INT >= 11) {
//Your code here
}
Trying to use methods that were introduced in a later api version will lead to a crash otherwise, whether you call it using Reflection or not.
The method is ImageButton's setImageAlpha(), and it says in the documentation that it was "Added in API 16."
But it doesn't give me an error when I try to use it, unlike some other methods that get underlined red and tell me it's not supported by the API I'm supporting?
One of the largest reasons Android will not error out these methods is that some methods introduce a cleaner/faster way to accomplish a task, which is great to include for users with a higher API level. A simple API level if check can allow users with a higher API level to user the cleaner/faster approach while not crashing the app for a device with a lower API level.
Erroring out the method would prevent you from supporting newer methods for users with a higher API, while still supporting devices with a lower API.
If an element was deprecated in API level 11, is it considered a deprecated element (not to be used if it can be helped) in API levels below 11 also or just 11 and above? If I am writing an app for API level 8, should I care about an element that was deprecated in API level 11?
This is slightly confusing to me. In Android API, for the SQLiteDatabase class for example, the method setLockingEnabled(boolean lockingEnabled) says:
This method was deprecated in API level 16. This method now does nothing. Do not use.
Does that mean it does nothing for all API levels below also or just API level 16 and above?
And if you are working on professional, commercial software, how important is it to avoid deprecated elements?
If an element was deprecated in API level 11, is it considered a deprecated element (not to be used if it can be helped) in API levels below 11 also or just 11 and above?
Just 11 and above.
If I am writing an app for API level 8, should I care about an element that was deprecated in API level 11?
"Deprecated" in Android usually means "we think that there is a better solution that you should consider, but we will support this old approach as best we can as long as we can". While you should endeavor to stop using deprecated methods, that's not something you should panic about and drop everything to address right away, and often times you need the deprecated materials for older Android OS levels, before they were deprecated.
Does that mean it does nothing for all API levels below also or just API level 16 and above?
Since they said "now does nothing", it is safe to say that it did something (non-nothing?) previously.
And if you are working on professional, commercial software, how important is it to avoid deprecated elements?
In the specific case of this method, I'd skip using it, though that's more due to the nature of this method.
As a counter-example, the way preference screens are set up differs substantially in API Level 11+ (PreferenceFragment and PreferenceActivity) versus before (PreferenceActivity alone). You can't avoid the deprecated element on older devices, simply because there is no viable alternative (e.g., backport of PreferenceFragment).
From the Docs
Annotation type used to mark program elements that should no longer be used by programmers. Compilers produce a warning if a deprecated program element is used.
I would suggest trying not to use them at all when possible. When you do I would take into consideration that this object, method, etc...may not work at some point in the future. When you build an app you typically want to build it so it can be easily maintained and flexible in the future. For this reason, I wouldn't use them if not necessary and there is almost always another way to do something
It's worth mentioning that sometimes a method may become "undeprecated" (if that is a real word). For example, the WebSettings setLayoutAlgorithm method was deprecated in 4.0.1, then later reinstated in 4.0.3 just with one of the algorithms deprecated.
But in general it's safe to use the method on versions of the API prior to when it was deprecated, and not recommended afterwards. Just be aware that it may not always be as simple as that.
When an item is deprecated that means that it should no longer be used after the API level in which it was deprecated. It is safe to use it for earlier API levels but if you are developing for newer API levels it should not be used. A deprecated method/element/etc. can be removed at a future point, so though it may still work now, you could end up with unwanted results in the future.
When it says that the method now does nothing that means that it no longer does anything in API 16 and above (or above 16 can't remember but to be safe I'll say 16+).