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.
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
I have been using the SingleLiveData class which can be found here. My questions are:
Is SingleLiveData is actually part of the Android Architecture Components?
Is it a good idea to use it?
Is SingleLiveEvent actually part of the Android Architecture Components Library?
No, and it won't be: https://issuetracker.google.com/issues/122413110.
Basically, the official answer is "Yes, regular livedata wasn't enough, so we introduced it in our examples but it's too hacky to be in the library".
Looking at Live data and its Parent/Children inheritance there is no such thing as SingleLiveData. Reading link provided by #Raghu, I find statement:
The SingleLiveEvent class was created for a sample as a solution that worked for that particular scenario. It is a LiveData that will only send an update once.
So to answer your questions:
Is SingleLiveData is actually part of the Android Architecture Components?
No, it is not!
Is it a good idea to use it?
This depends on many factors. Since I haven't used it I will give general idea. Using classes that you find in demo app or other way might not be guaranteed to be updated or bug-fixed. So if you understand the class so well that you can fix any bug you might find, and if it fits your need, then use it.
But generally I would avoid that if I can find something that is well maintained and does the same job.
Since from skimming the article I get impression he is trying to make some sort of observer pattern, I will suggest you check out rxjava
I'm using ObservableField for single UI events but it requires some hacking to use with Fragments to subscribe/unsubscribe automatically.
I want to be able to use the Lifecycle components from the new Android Architecture Components in my Wearable app (same as I do in my Android app).
In my main Android app I put LiveData fields in a ViewModel. This ViewModel can then be accessed/bound from both my Activity and my Fragments. To do this I use the method ViewModelProviders.of which expects either android.support.v4.app.Fragment or android.support.v4.app.FragmentActivity. So far so good...
The problem I'm facing is that my Wear app is based on the WearableActivity class which extends from android.app.Activity rather than from android.support.v4.app.FragmentActivity. This prevents me from using ViewModelProviders.of in my wearable app.
I've asked around and tried to find alternative solutions, but I don't know the internals of ViewModelProviders so I can't get around this problem right now. If there isn't an answer I hope someone who works on these components can have a look at this. It would be awesome to be able to use ViewModel & LiveData throughout my applications (mobile and wear).
Update:
AmbientMode seems to be the new way to handle this.
As #codingjeremy mentioned in his post, they have now introduced this with Android Support Library 27.0.0.
Original:
I got around this by copying the implementation in WearableActivity verbatim to a new WearableFragmentActivity class defined in my own project and then changing it to extend FragmentActivity. Getting this supported by Google directly would be the ideal solution, but this should work if you're looking for a workaround in the meantime.
This is not yet possible as ViewModel depends on Support Fragments (i.e., FragmentActivity).
Please file a feature request for a WearableFragmentActivity equivalent at issuetracker.google.com
I got it to work using AmbientMode.AmbientCallbackProvider instead of WearableActivity.
It is the new preferred method and it still gives you the onEnterAmbient(), onAmbientUpdate(), and onExitAmbient() but also lets you use Activity (or any sub classes... FragementActivity, etc.)... which allows you to support the Architecture components.
Official docs call out the details and code.
You can use this porting of architecture component: LifeCycleData
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
Are there any disadvantages to using deprecated methods in my code?
For example, I am using view.setBackgroundDrawable(background) in api 19 and it's working fine, but I want to know the proper way.
The main disadvantage is that the API might not be available in future versions, which will increase the cost of updating your application. It's also an indication that the SDK developers believe that there is a "better way" to do what you want to do.
Thus, in the end, it's a cost/value tradeoff: If the deprecated method is easy to replace, use the replacement. If it isn't, it's up to you to decide whether developing the "future-proof" way is worth the additional effort.
For example:
setBackgroundDrawable can easily be replaced by setDrawable (see the comment in the documentation of setBackgroundDrawable).
On the other hand, startManagingCursor is much harder to replace, so one might put off transitioning to ContentProvider until there is no other option.