#livedata

Your data is constantly changing — your AI should adapt. SDH connects RAG systems to live databases and APIs for up-to-the-minute responses. Stop settling for outdated AI answers.

https://youtu.be/Qk2mIpE_riY

original source : https://blog.mindorks.com/livedata-setvalue-vs-postvalue-in-android

we can change the UI of an application when there is a change in some data. 

livedata를 통해 쉽게 데이터 변경을 ui에 적용할수 있다.

livedata 설명

LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services.

In a simple way, LiveData is basically a data holder and it is used to observe the changes of a particular view and then update the corresponding change.

So, LiveData is used to make the task of implementing ViewModel easier. The best part about LiveData is that the data will not be updated when your View is in the background and when the view will come in the foreground, then it will get the updated data only.

Difference between setValue() and postValue()

either you can update the data on the Main thread or you can update the data using the background thread. So, the use-case of setValue and postValue depends on these two situations only.

While using the Main thread to change the data, you should use the   setValue   method of the MutableLiveData class and while using the background thread to change the LiveData, you should use the   postValue   method of the MutableLiveData class.

So, the duty of the   postValue   method is to post or add a task to the main thread of the application whenever there is a change in the value. And the value will be updated whenever the main thread will be executed (여기서 mainthread가 실행될때 이부분이 중요한 부분). So, basically, it is requesting the main thread to set the new updated value and then notify the observers.

While the setValue method is used to set the changed value from the main thread and if there are some live observers to it, then the updated value will also be sent to those observers as well. This setValue method must be called from the main thread.

So, here are some of the points that you must think before using setValue and postValue:

If you are working on the main thread, then both setValue and postValue will work in the same manner i.e. they will update the value and notify the observers.

If working in some background thread, then you can't use setValue. You have to use postValue here with some observer. But the interesting thing about postValue is that the value will be change immediately but the notification that is to be sent to observers will be scheduled to execute on the main thread via the event loop with the handler.

Let’s take an example,

// setValue liveData.setValue("someNewData") liveData.setValue("againNewData") // postValue liveData.postValue("someNewData") liveData.postValue("againNewData")

In the above example, the setValue is called from the main thread and the postValue is called from some background thread.

Since the setValue is called twice, so the value will be updated twice and the observers will receive the notification regarding the updated data twice.

But for postValue, the value will be updated twice and the number of times the observers will receive the notification depends on the execution of the main thread. For example, if the postValue is called 4 times before the execution of the main thread, then the observer will receive the notification only once and that too with the latest updated data because the notification to be sent is scheduled to be executed on the main thread. So, if you are calling the postValue method a number of times before the execution of the main thread, then the value that is passed lastly i.e. the latest value will be dispatched to the main thread and rest of the values will be discarded.

THE ADVANTAGES OF USING LIVEDATA ARE AS FOLLOWS :

1. Ensures your UI matches your data state

LiveData follows the observer pattern. LiveData notifies observers objects when the lifecycle state changes. You can consolidate your code to update the UI in these observer objects. Instead of updating the UI every time the app data changes, your observer can update the UI every time there's a change.

2. No memory leaks

Observers are bound to LifeCycle objects and clean up after themselves when their associated lifecycle is destroyed.

3. No crashes due to stopped activities

If the observer's lifecycle is active, such as in the case of an activity in the back stack, then it doesn’t receive any LiveData events.

4. No more manual lifecycle handling

UI components just observe relevant data and don’t stop or resume observation. LiveData automatically manages all of this since it’s aware of the relevant lifecycle status changes while observing.

5. Always up to date data

If a lifecycle becomes inactive, it receives the latest data upon becoming active again. For example, an activity that was in the background receives the latest data right after it returns to the foreground.

6. Proper configuration changes

If an  fragment is recreated due to a configuration change, like device rotation, it immediately receives the latest available data.

7. Sharing resources

You can extend a  LiveData object using the singleton pattern to wrap system services so that they can be shared in your app. The LiveData object connects to the system service once, and then any observer that needs the resource can just watch the LiveData object. For more information, see Extended LiveData.

original source : https://stackoverflow.com/a/58663143/3151712

There are two different lifecycles because the Fragment itself lives longer than the Fragment's view.

There are a number of events that can cause the Fragment's view to be destroyed, but currently keep the Fragment itself alive:

Putting the Fragment on the back stack (i.e., when you navigate() to another Fragment)

Calling detach() on a Fragment

Calling setMaxLifecycle(Lifecycle.State.CREATED) on a Fragment

In these cases, the Fragment's view is destroyed, moving the Fragment view lifecycle to DESTROYED. However, the lifecycle of Fragment itself is not destroyed - it generally stays as CREATED. This means that the Fragment can go through multiple cycles of onCreateView() -> onViewCreated() -> onDestroyView() while only going through onCreate() once.

Where this becomes a problem is when it comes to how LiveData works. When you observe a LiveData, LiveData automatically unregisters the observer when the lifecycle reaches DESTROYED. But if you use the Fragment's lifecycle to observe in onCreateView(), etc., that registered observer will still exist after onDestroyView(), despite the view being destroyed. This means that the second time your Fragment goes through onCreateView(), you'll actually create a second active Observer, with both running simultaneously. Then three Observers the next time and on and on.

By using the view LifecycleOwner in onCreateView()/onViewCreated(), you ensure that you'll only have one active Observer running at a time and that Observers tied to previous view instances are correctly destroyed along with the view. Therefore, yes, you should always use getViewLifecycleOwner() as the LifecycleOwner when in onCreateView() or onViewCreated(), including when using Data Binding.

Of course, if you're registering an Observer in onCreate(), then the view LifecycleOwner does not exist yet (it is created right before onCreateView()) and you don't have the multiple registration problem, which is why the Lint check specifically does not apply to any registrations done at onCreate() time. In those cases, using the Fragment's lifecycle itself is absolutely correct.

As per the Fragments: Past, Present, and Future talk, one future improvements for Fragments is going to be combining the two lifecycles together, always destroying the Fragment whenever the Fragment's view is destroyed. This is not yet available in any shipped version of Fragments, alpha or otherwise.