Android Jetpack: What's new in Architecture Components (Google I/O '18)
Why Stack Overflow recommends it
Stack Overflow users link it as a first-party reference for WorkManager (discussed around 21:44) and for fragment lifecycle guidance such as using viewLifecycleOwner when observing LiveData.
Recommended by 1 people across 1 different months, 2018 to 2021.
What it is
A Google I/O 2018 session by Lukas Bergstrom covering what changed in Android Architecture Components since I/O 2017. It introduces the new Navigation and WorkManager components alongside updates to existing Jetpack architecture libraries.
What people said
Recommends Annsh Singh · 2018-05 · Stack Overflow · on “Job manager in Android”
The new Workmanager [LINK] will help you schedule tasks in any order you want. You can easily set constraints to the job that you want to be en-queued along with many other advantages over JobScheduler API or alarm manager. Have a look at this video for a brief intro - [this video] (WorkManager at 21:44). EDIT: Updated my ans to show the capabilities of the new API You will not need ids to handle the jobs with this one. You can simply enqueue the task and the rest will be handled by the API itself. Some work case scenarios are WorkManager.getInstance() .beginWith(workA) // Note: WorkManager.beginWith() returns a // WorkContinuation object; the following calls are // to WorkContinuation methods .t
Recommends Annsh Singh · 2018-05 · Stack Overflow · on “How to schedule a job using Jobscheduler”
The new WorkManager API [LINK] will help you set necessary constraints for the task you want to schedule. Have a look at this video for a brief intro - [this video] (WorkManager at 21:44). EDIT: Adding an example to showcase the capabilities of the new API For eg: You can set constraints related to charging state of the device like this (along with other constraints like if the device is supposed to be idle for the task to run etc..) // Create a Constraints that defines when the task should run Constraints yourConstraints = new Constraints.Builder() .setRequiresDeviceIdle(true/false) .setRequiresCharging(true/false) // Many other constraints are available .build(); // ...then create a OneTimeWork
Cites Ali Nem · 2018-06 · Stack Overflow · on “When to use RxJava in Android and when to use LiveData from Android Architectural Components?”
In fact, LiveData is not an essentially different tool to RxJava , so why was it introduced as an architecture component when RxJava could have easily managed the lifecycle by storing all the subscriptions to observables in a CompositeDispoable object and then disposing them in onDestroy() of the Activity or onDestroyView() of the Fragment using only one line of code? I have answered to this question fully by building a movie search app once using RxJava and then using LiveData here [LINK] . But in short, yes, it could, but that would need first overriding the relevant lifecycle methods besides having the basic lifecycle knowledge. This still might not make sense for some, but the fact is th
Cites fernandospr · 2019-07 · Stack Overflow · on “LiveData observing in Fragment”
As of 2019, I'm trying to follow a best practice on where to start observing LiveData in Fragments and if I should pass this or viewLifecycleOwner as a parameter to the observe() method. According to this Google official documentation [LINK] , I should observe in onActivityCreated() passing this (the fragment) as parameter. According to this Google sample [LINK] , I should observe in onViewCreated() passing viewLifecycleOwner as parameter. According to this I/O video [this video] , I shouldn't use this but instead viewLifecycleOwner , but doesn't specify where should I start observing. According to this pitfalls post [LINK] , I should observe in onActivityCreated() and use viewLifecycleOwner . So
Cites Badhrinath Canessane · 2020-03 · Stack Overflow · on “I have a problem with Livedata observer called multiple time”
The lifecycle of the Fragment can be longer than the lifecycle of the View created. Replace this with viewLifecycleOwner for observing your liveData to avoid double subscriptions : cartProductItemViewModel.getCartProductItemList(x).observe(viewLifecycleOwner, new Observer<List<CartProductItem>>() { @Override public void onChanged(List<CartProductItem> cartProductItems) { product_categoriesFragmentAdpter.setArrayList(cartProductItems, getContext()); } }); Make sure you don't observe liveData before onCreateView(), when using viewLifecycleOwner. Source: [LINK] [this video]
Cites hardartcore · 2020-12 · Stack Overflow · on “Is it safe to observe LiveData inside onActivityCreated or onViewCreated”
It depends on which Lifecycle object are you going to pass to your Observer . Let's say you subscribe your Observer in Fragment's onCreate method. This solve the problems with observe called twice, but if the user press back button the Fragment A 's onCreate won't be called so no Observer subscribed. Or even in some cases your observe method can be called while your Fragment is now active and leads to crash. public void onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); viewModel.liveData.observe(this, Observer { myData -> {} }); } The second option you have is to subscribe in onCreateView() or onViewCreated() . The problem with these two options is that it will get cal
Cites Andrew · 2021-05 · Stack Overflow · on “Flow onEach/collect gets called multiple times when back from Fragment”
Reason It happens because of tricky Fragment lifecycle [this video] . When you come back from Fragment B to Fragment A, then Fragment A gets reattached. As a result fragment's onViewCreated gets called second time and you observe the same instance of Flow second time . Other words, now you have one Flow with two observers, and when the flow emits data, then two of them are called. Solution 1 for Fragment Use viewLifecycleOwner in Fragment's onViewCreated. To be more specific use viewLifecycleOwner .lifecycleScope.launch instead of lifecycleScope.launch. Like this: viewLifecycleOwner.lifecycleScope.launchWhenStarted { availableLanguagesFlow.collect { languagesAdapter.setItems(it.allItems, it.selec