Skip to content

darshna22/Android-Interview-ques-and-ans

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14 Commits
 
 

Repository files navigation

Android Interview ques and ans:

Q.1 What is the diff b/w View Binding and Data Binding?
Ans:

  • DataBinding

apply plugin kotlin-kapt // if youre using kotlin

android {
    dataBinding {
        enabled = true
    }
  • ViewBinding
android {
    viewBinding {
       enabled = true 
       }
   }

Different between them is how to initialize that,

//DataBinding
binding = DataBindingUtil.setContentView(this, R.layout.activity_main) as ActivityMainBinding
//ViewBinding
binding = ActivityMainBinding.inflate(layoutInflater)

Q.2 What is the diff in MutableLiveData, LiveData and MediatorLiveData?.
Ans:

java.lang.Object
  ↳android.arch.lifecycle.LiveData<T>
     ↳android.arch.lifecycle.MutableLiveData<T>
         ↳android.arch.lifecycle.MediatorLiveData<T>

Now it is clear that MediatorLiveData is a subclass of MutableLiveData therefore MediatorLiveData can access each and every property of MutableLiveData as well as LiveData.

Question no. 1 is answered partially and rest of the answer will be discussed at the end of Question no. 2's answer.

After researching on some sample projects as well as android developer's official site I found that MutableLiveData should be used only for notifying your UI when observing any data.

For example, you want to display two SeekBars on two different fragments(Fragment1 and Fragment2) and you also want them to be synced when operating from Fragment1.

Another scenario is that we have 2 instances of LiveData, let's name them liveData1 and liveData2, and we want to merge their emissions in one object: liveDataMerger (which is a MediatorLiveData object). Then, liveData1 and liveData2 will become sources for the liveDataMerger and every time onChanged callback is called for either of them, we set a new value in liveDataMerger.

LiveData liveData1 = ...; LiveData liveData2 = ...;

MediatorLiveData liveDataMerger = new MediatorLiveData<>(); liveDataMerger.addSource(liveData1, value ->liveDataMerger.setValue(value)); liveDataMerger.addSource(liveData2, value -> liveDataMerger.setValue(value)); In this case you cannot use MutableLiveData but on the other hand if you want to compare data into the first example (where MutableLiveData has been used) then you cannot because you will be unable to use the addSource property (as per class hierarchy).

Q.3 How to create instance of ViewModel class in Fragment?
Ans: In Fragment Use: viewModelRoutesFragment = new ViewModelProvider(requireActivity()).get(ViewModelRoutesFragment.class);

instead of viewModelRoutesFragment = new ViewModelProvider(this).get(ViewModelRoutesFragment.class);

Q.4 Difference Between MVP and MVVM Design Patter?.
Ans: Capture1 Capture3

Q.5 What is the life cycle method when fragment1 add over fragmet 2 in same screen?

Ans: In this case whatever fragment added last into the fragment stack android start that fragment first

frag fragnent life cycle

Q.6 Send data from one fragment to another fragment using interface?
Ans:

  • add frag1 and another with their tag or id so that we can get them when ever required
  • In this apporach we create one interface in fragment 1.
  • and same interface we implement in activity where thes fragment added
  • get the another fragment instance in activity by findbyId or findByTag in frag1 override method
  • set fragment 1 value to frag 2 method
    Follow Below for more
    https://github.com/darshna22/FragmentBehaviousApp/tree/master

Q.7 Send data from one fragment to another fragment using viewmodel class?
Ans:

  • In this approach create sharable viewmodel class and create mutable livedata variable to set value and livedata variable to get set value
  • get this view model instanse in both share and recieve fragment
  • set value to mutable live data variable from share fragment
  • observe frag1 value in frag2 using sharable view model class.
    For more ref plz follow below link:
    https://github.com/darshna22/FragmentBehaviousApp/tree/master

Q.8 Create view model class instance in fragment?
Ans:model

Q.9 Observe view model class data in fragment?
Ans:observe

Q.10 what happens when you create view model class object as normal class like below? val shareDataViewModel=ShareDataViewModel()
Ans: In this case this instance will not work observe viewLifecycleOwner
result observer will not work for view which is observing its value.

Q.11 what happens when fragment dialog in transparent background comes over another screen/fagment.?
Ans: Nothing happens all lifecycle works as they works.


For more ref plz follow below link:
https://github.com/darshna22/FragmentBehaviousApp/tree/master

Q.12 ViewModel lifecycle and internal working?
Ans:
Lifecycle
A ViewModel's lifecycle begins when its associated UI controller is created and ends when the UI controller is destroyed or removed from the foreground.
Lifecycle methods
ViewModels have two main lifecycle methods:
onCreate(): Called when the ViewModel is first created, this is a good place to initialize data or perform setup tasks.
onCleared(): Called when the associated UI controller is destroyed or the ViewModel is no longer in use, this is where cleanup tasks should be performed.
Internal workings
ViewModels use ViewModelStore and ViewModelStoreOwner to manage their lifecycle and data retention.
Data sharing
Multiple Fragments can share a common ViewModel to communicate and share data.
Configuration changes
ViewModels can survive configuration changes, such as screen rotations, and retain data. This means that the UI doesn't need to fetch data again when navigating between activities or following configuration changes.
ViewModelProvider
The ViewModelProvider class manages the lifecycle of a ViewModel. It can fetch or create a ViewModel, and will return an existing instance if one already exists within the lifecycle scope.
UI controller
Never store a UI controller or Context directly or indirectly in a ViewModel. This can lead to memory leaks.
image