exoplayer.setThrowsWhenUsingWrongThread(false) is deprecated in Exoplayer latest version, is there any alternative to it because when I remove it then it gives,
java.lang.IllegalStateException: Player is accessed on the wrong thread.
Current thread: 'DefaultDispatcher-worker-1
Expected thread: 'main'
exoplayer works fine if I use it, but it's deprecated.
Thank you for your Help!
setThrowsWhenUsingWrongThread() has become deprecated for the following reason according to the official documentation: "Disabling the enforcement can result in hard-to-detect bugs. Do not use this method except to ease the transition while wrong thread access problems are fixed." The official release notes extend on this commentary by mentioning the method will be removed entirely upon the next major release.
There's no alternative outside of complying to the library's strict single-thread paradigm. Please see the Hello World's note on threading and the threading model section of the official documentation. You can employ setThrowsWhenUsingWrongThread(false) in the meantime as it's only deprecated, but you'll need to comply if you would like to utilize upcoming features.
Related
What is the benefit of adding annotations suggested by the lint such as "#ExperimentalApi" or other recommended stuff like this?
Does it mean in the future it can warn us if the API changed?
Yes, it means that the API can change or be removed in future.
Experimental APIs are good for testing around new functionalities but usually their use is discouraged in production code.
PS: Kotlin now uses #RequiresOptIn (and #OptIn) instead of #Experimental which is deprecated. You can find more info here
So I have been following the Android ViewModel Overview as I need to communicate between fragments, when creating the ViewModel, it uses ViewModelProviders which requires you to add dependencies. Upon looking at the documentation for ViewModelProviders I saw this:
Should I continue to follow the Overview, adding the required dependencies, or should I modify it to use ViewModelProvider? What are the benefits of either?
Thank you.
You should avoid using deprecated APIs. Deprecation means that it's planned to be removed and it's not going to be maintained.
If you check the commit that added deprecation: https://android-review.googlesource.com/c/platform/frameworks/support/+/1009889/6
If you check the diff of the deprecated commit you can see that ViewModelProviders.of internally uses the suggested API. (see diff)
Release notes: https://developer.android.com/jetpack/androidx/releases/lifecycle#2.2.0-alpha03
ViewModelProviders.of() has been deprecated. You can pass a Fragment or FragmentActivity to the new ViewModelProvider(ViewModelStoreOwner) constructor to achieve the same functionality.
So what that means is that you can achieve exactly the same thing using the constructor instead of the ViewModelProviders.of().
My take on this is to avoid using deprecated methods as much as possible. There is a good discussion about it here.
As to benefits, I think the later might be better because is it part of a more recent iteration. I have tried both with an infinite vertical scrolling recyclerView, and I have not notice any big difference a part from the naming.
I was about to use the android class Sound Pool when I noticed it has become deprecated. Should I try to find the newest version every-time or just use the deprecated method?
Real answer? Never.
It is deprecated for a reason. Deprecated methods are methods that will not be updated and may cease to be supported at all. Try to find the newest way of doing what you want to do with the most up-to-date API.
From: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Deprecated.html
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
There is a better way to do it, but that doesn't mean you cant do it. You are probably safe, but you will have to keep an eye on performance, especially for android.
I read Android documents and also I find deprecated methods and classes in that.Can I use deprecated methods and classes in android studio?
Can I use them like other methods and classes that are not deprecated?
Yes you can use deprecated methods as long as the depreciated method exists in the framework. By deprecating a method the platform developers are trying to tell you that either something is wrong with the method or there is already better way for doing the task.
Depricating a method is like giving a warning to the developers not to use that method as the chances are high that the deprecated methods will be removed in the future release and your application which uses that method may no longer work when your users updates the platform to the latest release.
Of course you can use deprecated methods, they should still work as intended. But you have to be careful, because they could be removed in future versions. So read the comments.
This discussion gives you further information Is it wrong to use Deprecated methods or classes in Java?
The description of the Java Deprecated annotation can be found here http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Deprecated.html
It says
A program element annotated #Deprecated is one that programmers are
discouraged from using, typically because it is dangerous, or because
a better alternative exists. Compilers warn when a deprecated program
element is used or overridden in non-deprecated code.
Of course you can use them just that they can be removed in future update which makes it dangerous for your apps and end user.
To get more info read the android documentation on it. https://developer.android.com/reference/java/lang/Deprecated
As a victim, my advice for you is NO because there's a time i used a deprecated method of androidx ViewPager instead of the modern one. Although it worked fine but after keeping the app idle for some days, then it could no longer open if i tried to open it
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.