I want to know when deprecated classes become unusable.
How can I find out about it?
Example, I used below.
android.widget.TabHost
androidx.fragment.app.FragmentPagerAdapter
androidx.fragment.app.FragmentTabHost
android.os.AsyncTask
Framework classes, such as the ones that you cite, cannot be removed without breaking backwards compatibility.
It is entirely possible that at some point Google will break backwards compatibility and remove these classes from a future version of Android. IMHO that is unlikely, and if it happens, the community will be very noisy about it, so hopefully you will not miss it.
Library classes, such as the androidx ones from the Jetpack, can and do get removed from the library in future versions. However, usually, you have some control over when you take on new library versions.
Related
I am using some libraries in my android project, which currently are stable. But in further version, if the library developers made some mistakes or removed the earlier functionality, then how can I make my app handle this change and avoid breaking? I am looking for some such strategies to make my app more robust and consistent even if the library functionality changes.
Firstly, if you will update version of library, it will not be changed, but library developers later may remove version you used from support and use.
Also, you can import library by yourself.
Moreover, it is better to develop functions by yourself, if you are not sure about library future.
When I try to use UInt I get this warning message:
This declaration is experimental and its usage should be marked with '#kotlin.ExperimentalUnsignedTypes' or '#OptIn(kotlin.ExperimentalUnsignedTypes::class)'
Aso the same happens when I try to create inline classes (which is what UInt is):
The feature "inline classes" is experimental
Those features can be really helpful but these warning messages are just stopping me from using them in case something will break the code in the future. Is this fear realistic?
Experimental features are released by Kotlin for the community to try out and provide feedback. They are by definition not completely Stable features, and hence
may not have backward compatibility
be at an early or late stage of the evolution process
may be completely changed or even dropped in a future release
Hence you should definitely not use experimental features in critical projects as
they are not stable and may have issues
in case the experimental feature gets modified or dropped in a future release, you'll have the extra work of refactoring that when you upgrade Kotlin to a newer release
That being said, in case the project where you intend to use UInt is not critical, go ahead and use it, but just be wary of the above.
The stability of Kotlin components is very well explained here.
The version 27.0.0 of the Android Support Library introduces the class FragmentCompat.PermissionCompatDelegate. I wondered what it was exactly and how it should be used (reading the docs without any example didn't help much).
I dived a bit deeper, and discovered FragmentCompat.OnRequestPermissionsResultCallback, introduced back in 24.1.0, and also noticed that these two nested interfaces have ActivityCompat variants, introduced in the same Support Library versions.
Do these interfaces finally allow any class to manage permissions requests and grant results without having to do ugly hacks like are done in most of these libraries that often required to extend a "BaseActivity" or "BaseFragment"?
How to use them? If you answer with code, Kotlin snippets are appreciated, but Java ones are accepted too!
Action Bar Sherlock, while being a neat library, as you might know, has two to three pretty invasive elements:
It forces you to inherit your Fragments and Activities from SherlockFragments and SherlockActivities. This is a sparse resource which you can't use for another handy library that might require you to do the same. Luckily the compat library isn't one of them (actually it is, but Sherlock builds on it).
It uses an Android library project. Since the tooling for these can't quite be called very stable yet, you might run into problems sooner. In fact, I have run into Eclipse bugs.
It's yet another library that makes Proguard's job harder and adds to your apk's size. Apk sizes are still a huge limitation for some users, among which Google TV users.
As such, what other possible (future) libraries, including 3rd party ones, would I be excluding if I choose to use Action Bar Sherlock? Any other limitations I'm missing?
As such, what other possible (future) libraries, including 3rd party
ones, would I be excluding if I choose to use Action Bar Sherlock? Any
other limitations I'm missing?
Frankly, I don't know of any. Most libraries which are making the use of a custom implementation of Activity(like ActionBarSherlock is doing as well) will most likely extend SherlockActivity(since almost everybody uses ABS) or if not then you could just modify it yourself. So no, as far as I can tell there won't be any limitations.
As #Jake Wharton himself pointed out this is just not true. Using the existing code and examples, it is a simple and fairly quick implementation for creating custom ABS activities and fragments.
I use library projects extensively, including having library project references that go multiple levels deep. I've run into a few issues, but nothing that was a deal breaker. Eclipse gets confused sometimes on rebuilds, but usually cleaning all the projects gets everything sorted out. Library projects are getting more stable all the time.
This is actually two points, but with a similar theme -- for any library, not just ABS, you have to tradeoff the value you get from including the library's features against the cost of doing so. I feel the value of the interface right now is worth the extra effort and apk size. This is a value decision that needs to be made on a per app basis.
#Ahmad is correct, ABS poses obvious no limitations on 3rd party libraries. It might take some coding to integrate, but they should work together. Furthermore, ABS use will fade naturally in the future. It is a compatibility library, so as the device distribution shifts more and more to Android 3+ devices, the need to support action bar UIs on 2.X devices will be less of an issue.
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.