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
Related
I'm looking into slowly migrating an existing view-based Android app to a Jetpack Compose app. I figure I will take the opportunity to totally refactor the app, so I'm starting the Compose app from a blank slate, and trying to adopt the latest best practices as I go.
I've created a new project in Android Studio, using the "Empty Compose Activity" that's recommended in some of the docs I've read.
The project it creates lacks a MainApplication.kt file, and the manifest jumps straight into MainActivity, which defines only class MainActivity : ComponentActivity()
I note that the Android docs say "There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way." which has me thinking that, as part of this refactor, I might try follow this implicit recommendation and see where it leads.
So my question is, is there anything that must be done in the Application class that would make me regret the structure that Android Studio has given me?
Does Koin dependency injection work fine outside of the main Application class? My app has services which have Room dependency injections I now do in Application class. All of that can be done elsewhere, presumibly in MainActivity?? (All Koin's examples use the Application class for DI!)
Can setting user permissions like location and file access can be done outside Application class??
I know I'm asking for an opinion here, but do you regard it as best practice to not subclass Application if you can avoid it, as the Android docs seem to suggest?
And lastly, is not subclassing the Application class (ie not having MainApplication.kt) somehow related to the new Compose way of building apps?
thanks!
John
The skeleton code that you get from creating a Compose project from Android Studio does not subclass Application because it just gives you the bare essentials to have a functional compose app.
The Application class is still the right place to initialize your dependency injection graph, plus other libraries that need a one-off initialization, like for instance Timber.
Requesting runtime permissions should be done locally, at the time you need those. If you need some permission to start your application from the get go, ask for those in your activity, the Application is not the right place for that.
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.
Am working on a huge android project that has more than 50 APIs request
and using the MVVM pattern, My question is:
can I add all the requests in the same app repository or I must create a repository for each service?
As others suggested in the comments you should first define the modules of your app and then create the corresponding Repositories. This way you can easily maintain and test your application.
I strongly suggest you to have a look on this https://github.com/nickbutcher/plaid and mostly this video https://youtu.be/Sy6ZdgqrQp0
A good solution to this problem is, You must not implement all your API calling code to the same repository as it will become a massive single repository class. It will also be violating design principles i.e. rule of 30 as you are saying you have at least 50 APIs to work with.
Also, it is not a good practice to modify a class, again and again, see Open Close Principle.
You can make multiple API calling classes under the same package name.
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've started using Architecture Components in my application and I'm still learning how to use it.
In my app I have an Activity showing different Fragments sequentially. In some of them I need to communicate with a background service in order to receive data from external BLE sensors. Since I need to interact with the service in more than one Fragment, I'm wondering if ViewModel is the right place where to make the binding. I've looked around but I didn't found an answer.
Are there any problems binding a service inside a ViewModel?
It is not advisable to use Android framework classes inside ViewModels.
Here is the link on Google Developers blog post with the detailed explanation: ViewModels and LiveData: Patterns + AntiPatterns
Ideally, ViewModels shouldn’t know anything about Android. This
improves testability, leak safety and modularity. A general rule of
thumb is to make sure there are no android.* imports in your
ViewModels (with exceptions like android.arch.*). The same applies to
presenters.
Don’t let ViewModels (and Presenters) know about Android framework
classes