Shahzad Aslam
11/19/2019, 11:19 PMApproach 1
is better because in option 1 caller of interactor (which is viewmodel) don’t have to worry about which dispatcher the interactor will use. And interctor knows if it is doing network or some computation it knows about the context and which dispatcher it should use.
While in Approach 2
interactor is performing the operation in parentContext and the caller should know about the right context/dispatcher it should use before calling the function.ursus
11/21/2019, 8:27 AMursus
11/26/2019, 9:17 PMursus
12/03/2019, 4:08 AMSergey B
12/04/2019, 3:56 PMursus
12/05/2019, 7:12 AMursus
12/07/2019, 3:24 AMMadalin Valceleanu
12/09/2019, 9:37 AMAnastasia Finogenova
12/09/2019, 8:29 PMubu
12/12/2019, 9:22 PMsanmi
12/14/2019, 1:20 PMJason
12/17/2019, 3:09 AMBrendan Weinstein
12/17/2019, 7:43 PMAdam Hurwitz
12/19/2019, 11:00 PMursus
12/23/2019, 5:23 AMJérôme Gully
12/25/2019, 6:18 PMViewModel by viewModels()
to avoid boilerplate code, so I'm a bit confused about it.Daniel
12/25/2019, 10:21 PMclass Preferences(private val sharedPreferences: SharedPreferences) {
private companion object {
private const val GENERATED_LEVEL_INFO_SEEN_KEY =
"generatedLevelInfoSeenKey"
// ...
}
var generatedLevelInfoSeen by BooleanPreference(
GENERATED_LEVEL_INFO_SEEN_KEY, false)
// ...
private inner class BooleanPreference(
private val key: String,
private val default: Boolean) {
operator fun getValue(thisRef: Preferences, property: KProperty<*>) =
sharedPreferences.getBoolean(key, default)
operator fun setValue(thisRef: Preferences, property: KProperty<*>, value: Boolean) =
sharedPreferences.edit { putBoolean(key, value) }
}
}
Hitanshu Dhawan
12/28/2019, 9:29 AMViewModel/Repository
fun getData() = liveData {
val a = getFromDB()
emit(a)
val b = getFromNetwork()
emit(b)
}
View
viewModel.getData().observe(this, Observer{
// do ui stuff
})
This works perfectly fine. But the problem is now I want to add Swipe to Refresh feature, and want that the entire liveData {}
block to run again.
How do I trigger a refresh call to the getData()
LiveData?
One solution which is mentioned here (https://stackoverflow.com/a/58689791) is to introduce another MediatorLiveData
and remove and re-add the liveData {}
block on refresh. But I don't want to add 2 LiveDatas and it also seems like a hack.
Any good and elegant solution for this guys? Thanks.ursus
12/29/2019, 2:45 AMKashif
12/31/2019, 11:46 AMursus
01/03/2020, 7:15 AMIvann Ruiz
01/03/2020, 5:34 PMViewModel
be a LifecycleObserver
so it can react to the view's lifecycle? There's some good arguments for each scenario: on one hand we don't want the ViewModel
to "_know"_ about the view's lifecycle, however, it may also help make the View
as dumb as possible and have more logic be done on the ViewModel
.ursus
01/06/2020, 2:22 PMivano
01/07/2020, 1:02 PMclass Car() :MovingObjects{
val carParts = CarParts()
val carFunctionalities =CarFunctionalities()
}
class CarParts():MovingObjects(){
fun engine(): Engine
fun wheel(): Wheel
fun doors():Doors
}
}
class CarFunctionalities():MovingObjects{
fun switchOn()
fun maxVelocity(): Int
}
ghedeon
01/13/2020, 10:53 PMursus
01/17/2020, 5:21 PMSlackbot
01/21/2020, 9:46 PMRohit Surwase
01/23/2020, 12:11 PMclass MainViewActVM(val repository: AppRepository) : ViewModel(){
}
//...Our Activity/Fragment
private val mainViewActVM: MainViewActVM by lazy {
ViewModelProviders.of(this, ReminderViewActVM.Factory(AppRepository.getInstance(this))).get(MainViewActVM::class.java)
So instead of doing this why can’t (don’t) we use following
class MainViewActVM(application: Application) : AndroidViewModel(application) {
private val repository: AppRepository = AppRepository.getInstance(application)
.....
}
What are the downside of using second approach?ursus
01/26/2020, 12:14 AMmoizest89
01/29/2020, 5:31 PM