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.
Related
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.
I am working on an Android project where MVVM is the architecture being used. There is a use case where a Flow in my Repository needs to be updated based on the results of a callback which is triggered when something in my Data Source changes. The most appropriate choice for this problem seems to be callbackFlow. However, it is still experimental. I am very tempted to use callbackFlow, however, I understand that any future changes might break some code and I don't want that to happen in a production app. Considering the above scenario, what should be a replacement for callbackFlow? Or should I consider going ahead with callbackFlow?
callbackFlow is runtime stable - it works just as it is supposed to and it exists exactly because it is exactly the right tool to use in many cases.
I understand that any future changes might break some code and I don't want that to happen in a production app"
The only change that would affect how it functions is when upgrading your version of coroutines. That has nothing to do with runtime stability.
I know that new versions both support NDK for android applications.
But many plugins doesnt work with gradle-experimental.
What is gradle?
Gradle is an advanced build system as well as an advanced build toolkit allowing to create custom build logic through plugins.
What is gradle-experimental?
The new experimental plugin is based on Gradle’s new component model mechanism, which allows significant reduction in configuration time. It also includes NDK integration for building JNI applications. This user guides provides details on how to use it and highlights the difference between the new plugin and the original plugin.
WARNING: Note that this is plugin is at the experimental stage. The Gradle API for the new component model is not final, which means it’ll only work with a specific version of Gradle until the APIs are final.
Additionally, the DSL is likely change significantly, as APIs to create the DSL are finalized.
This is a very early preview of the plugin for feedback on performance and NDK integration.
Essentially, gradle-experimental is a work in progress (as stated above this plugin is at the experimental stage) of what gradle itself should become in the future.
An analogy:
A house was built some years ago and has been through alot of improvement. Everything is in place, and it appears done. Today, it is a place where you know you'll be safe if you live in it.
Another house is being built at this very moment, because the owners of the house above have plans to move. Some rooms have been constructed, some haven't. Some doors and windows are already in place, some have not even been ordered yet. Some areas they don't even know yet what they are going to do with. Some rooms might appear done, but they may very well be refurnished at any point in time. The ceiling may collapse, the floor may disappear, you'd only know about it when it has already happened. This house is not currently safe to live in.
Gradle is the first house.
Gradle-experimental is the second house.
I don't think there is much use in comparing them at this stage. If you don't absolutely need to use gradle-experimental for whatever reason, just stick with the current and stable gradle.
I have been making a project on Android 4.0 and I have faced some deprecated types for the newer versions of Android. A black line has occured on the name of the deprecated things. However, in spite of the black line and the deprecation warnings, I can still use those deprecated classes and project is running successfully. I got confused about the deprecation. If they are deprecated how can I still use them and what does deprecation mean exactly? If I use the deprecated classes in my project, what can be the possible disadvantages that the project users can encounter?
Thanks for reading.
Deprecated means that they are likely to be removed in a future version of the platform and so you should begin looking at replacing their use in your code.
If they just removed the types then builds would break and people wouldn't be happy!
In terms of the effect they will have on your application's users, there shouldn't be any effects at all. However, when you come to update your software to the next version of Android you may find that the deprecated types are no longer there and your build will break.
Wikipedia has a good article on it here: http://en.wikipedia.org/wiki/Deprecation
Long story short only use the deprecated method on systems running too low of an API to support the updated method. This way you can support a wider range of devices while only using the deprecated methods when you have to to support the older devices. Code example below.
int sdk = android.os.Build.VERSION.SDK_INT;
if(sdk < android.os.Build.VERSION_CODES.JELLY_BEAN) {
setBackgroundDrawable(); // deprecated method for older devices
} else {
setBackground(); // updated method for newer devices
}
CHEERS :)
Don't forget that there is probably a reason for these classes to be deprecated. It might affect the security or stability of your app.
If you find out there is a bug or a flaw it will probably never be corrected.
Also checkout what classes they advise to use instead, if any.
Concerning your worries about newer Android versions:
Android versions are backward compatible
Confirmed here by an Android engineer in a topic about an other deprecated class. Therefore you should be able to use your app on newer versions.
If you want your application to be compatible with older versions of android while using a "new" class in your code, check this related topic.
often some types of classes are deprecated but you can still continue using them because to update applications and implement those classes you would have to modify the source code.
But if you find that there are unused classes is better than in coming soon applications no longer use them, personally I spend it with ClipboardManager and use applications where previously it still works.
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.