I'm writing an Android app that relies heavily on checking whether a given moment in time belongs to a certain time range. Usually I would use the java.time library, however this limits my app to API 26 or higher. It is absolutely necessary that my app runs on devices using at least API 16. Everywhere I look on the online documentation and forums I find only references to java.time, how can I perform these kind of checks in a backward-compatible way?
Edit: after some more research I found the proper way to do it through gradle desugaring.
One of the way to manage dates and times in Android is adding Joda Time Android. It provides concise, flexible and easy API for replacing standard time API. Hope it'll be helpful.
Related
I was going through the Android documentation and I came across below lines:
In a very small number of cases, parts of the API may be modified or
removed, although typically such changes are only needed to ensure API
robustness and application or system security.
Is there an example of such removal of public API?
It would be interesting insight for all of us, developers, to understand why an API is removed and what can possibly be removed in Future based on this previous history.
The Apache HTTP client was deprecated in API 22 and removed in API 23. In this case it appears that they only removed it from the stub library, so apps using it will still run on Android M. You just can't compile them for Android M.
Google has also effectively removed features by changing the way APIs work. An example of this was the change to ActivityManager#getRunningTasks(int) in API 21. The method is still there, but it no longer allows you to discover what other apps are running, which is what many developers were using it for. Another example is how network activity on the main thread started throwing a NetworkOnMainThreadException in Android 3.0. In both of these examples, the documentation described the intended use of the API long before they began enforcing 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).
The minimum SDK version for my project is 7, I am not able to use TrafficStats out of the box. Therefore, currently I am using an approach based on reflection as shown here. The main problem with that is that I cannot have this stats on devices with earlier than Android 2.3, it just gives me the possibility to do not Force Close on a 2.1 device.
Then now I am looking for a way to use the TrafficStatsCompat as it is described on the doc as "Helper for accessing features in TrafficStats introduced after API level 14 in a backwards compatible fashion."
My main problem is that I could not find any example on how to use this compatibility class. I've been looking for other classes inside the support library so I could try to mimic the behavior on how to use it, but I was not successful. Can someone provide an example on how to use the TrafficStats methods, e.g., getTotalTxBytes, but with TrafficStatsCompat.
Can someone provide an example on how to use the TrafficStats methods, e.g., getTotalTxBytes, but with TrafficStatsCompat.
No, because that class has nothing to do with accessing traffic stats on API Level 7. It does precisely what you quoted: it helps developers use methods added to TrafficStats after API Level 14.
There is no way for you to get traffic information prior to API Level 8 when TrafficStats was introduced.
UPDATE
Since trying to answer the comment in a comment was going to be painful...
You only need to play reflection games like that if you are continuing to support Android 1.x (and if you are, you are a saint).
If you are sticking to Android 2.x and higher, you can simply route using Build:
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.FROYO) {
// do something involving TrafficStats
}
You should add to your project (into lib folder) following library android-support-v4.jar (android-sdk\extras\android\support\v4)
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.
I am making application which is using a deprecated API. I have to submit it on Apple and Android App Store next month.
In this case, is there any chances to reject the application from app Store of Iphone And Android.
Don't use a deprecated API. Almost nobody deprecates something without providing an alternate means to accomplish the same task. Use the documentation to discover these alternatives, and adjust your code accordingly. What happens if iOS 5 comes out tomorrow, for instance, and all of a sudden your code breaks on those devices. You'll be scrambling to fix it. Fix it now while you have some time.
Android should not be a problem due to the fact that they won't look at your code. Apple will probably check your code and if they see it, they will most likely tell you that you are using deprecated API, but I don't think they will reject it if it is working flawlessly with it.