https://kotlinlang.org logo
Join Slack
Powered by
How do you "bind" your LiveData objects to a corre...
# android-architecture
a
How do you "bind" your LiveData objects to a corresponding TextView, if you're supposed to expose all your LiveData objects as immutables? (Without DataBinding)
o
With viewmodel.livedata.observe ...
a
@Orhan Tozan I mean the other way around, if we have a firstName 
EditText
for example and want to keep our LD updated with its 
text
.
o
Edittext.ontextchanged
a
@Orhan Tozan So we make the LiveData mutable?
o
Give the viewmodel a method like 
fun onUsernameTextFieldTextChange(newText: String)
👍 1
r
Ummm your not suppose to Bind Live Data to Views. That's a Anti pattern. Your views are only suppose to observe your live data
o
Sure Views also need to be able to emit events. Something like a textinput can be abstracted away to simply two way binding.
r
Yea but liveData isnt ment to handle those view events. Because think about it, the view gives data to live data just to be observed by the view all over agian. There is no real reason for that unless its triggering something else that is being observed... but it def should not just be emitting the same character that was entered into the text listener?
o
That's what MutableLiveData is for. Since something like a text input is really straight forward, the view could get the responsibility to update it's input
r
Not exactly. Livedata , is a data holder that a lifecycle owner can observe.MutableLiveData is just a livedata that you can write to.. but if you end up with a pattern where the lifecycle owner gives a livedata data just so the owner can turn around and observe it, than you end up with a pattern like this (LifecycleOwner <----> livedata]... which to me seems like a clear anti pattern
o
It's called two-way binding yes, and isn't an anti pattern if used with decency. Android Docs cover this topic here: https://developer.android.com/topic/libraries/data-binding/two-way
r
I thought we were talking about livedata
o
Yeah we are
r
Two way databinding is something completely different
o
Two way binding is a concept on its own that exists outside of Android's databinding library. You can still apply the concept of two way binding with lets say regular view binding
r
Mmmm yes but it's completely different
Livedata and 2 way databinding are not even the same concept
o
OP asked about how to bind livedata to a text input, which could be solved with two way binding
Two way binding isn't an anti pattern, that's my point
r
Yes but not with live data
That component isnt ment for that
o
The linked docs perform two way binding with livedata
r
Not the way your thinking. For instance 1 way data binding the data just updates the view correct. 2 way databinding the view can update the data and vise versa correct. But in the case of just using livedata unless your trying to observe the transmission for a particular reason, let's say another event happens when you type there is no real reason to use a livedata for that
Dont get me wrong not trying to say your idea is bad or 2 way databinding is bad. I love databinding lol, and your approach makes sense . But just saying the general idea of attaching a livedata to a view listener seems to be a bit of a anti pattern, unless it's to trigger another even in which the view needs to obserse
And if the livedata doesnt need to be observed than livedata is the wrong data structure to be used
o
I find it hard to understand your point lol, two way binding of livedata without databinding would just someting be like:
Copy code
viewmodel.textInputLiveData.observe(this) { text -> textViewInput.setText(text) }

textViewInput.onTextChangedListener { newText -> viewmodel.textInputLiveData.value = newText
}
r
Lol ahhh wait that wouldnt that be a infinite loop or I'm trippong
That's def a infinite loop.like I said anti pattern
o
That would be an issue w/ the Android framework itself, an implementation detail from the viewmodel's standpoint
r
Set value would trigger the textview onChangeListener which would update the live data which in turn would update the livedata all mover agian
This is exactly why I said it doesnt make sense. Livedata isnt ment for this
o
ViewModel should be able to expose MutableLiveData textfield livedata, just saying that hey this is the textfield just keep it up to date with the users input
r
With the code snippet you just entered. You press one key on the keyboard and your program will be in a world of hurt lol.... that's not a issue of the android framework that's a misuse of a component
o
That's just android's framework not offering a listener for when text is input by a user
r
It has onTextChangeListener.... it's not the framework . The code is incorrect because that's not how livedata is ment to be used
o
onTextChangeListener wouldn't be the right event, there should be like onTextInputListener, which doesnt exist
r
Why, just so it could be re observed by live data?
Lol come on
o
Well, that's how MVVM works
r
Absolutely not
o
Keep the state in the VM, instead of the view managing its own state
Well lol how would you handle this?
A screen with a text input
MVVM
go
r
Mvvm every level is being observing something else. Umm I would ask first what he is trying to accomplish with the listener
o
Very simple, a screen with a text input, it should act like how you would think a text input acts
Let's say a login screen, but let's hide the login details for now, just handling text input
r
Ok one sec let me get on my computer. My fingers hurt from typing on my phone lol
What does the login screen need to do
o
username and password text field w/ login button. correct username=123 & password=123. If login button pressed w/ correct credentials entered, go to other screen
r
you dont even need a text change Listener in that example
sorry for the crazy sudo code
o
Yeah so with this example you are letting the view hold the state
You are letting the view hold the username and password text input state
r
if you need to perverse through rotations , you don't need liveData for that. you can set the text directly in two strings in your Viewmodel
o
You want the view to be recreated at any time given the viewmodel. If a view would be recreated by your viewmodel, it would always start blank. The ViewModel should always reflect the View's state
r
Your viewModel is lifecycle aware already
o
I'm talking about MVVM in general, I don't know the details how Android handles view retaining, but the fact is that your ViewModel doesn't reflect the state of your View
r
Viewmodel and state are not the same thing
maybe your thinking Redux or MVI. VM , is not state
o
It is state
lol
r
nope
o
It is state for the view
Your view can't be correctly build from your viewmodel
It would lose data
r
Not really . you consider it state because the View is normally a reflection of what happen in the viewModel. But in essence that because the view observes the viewModel and updates accordingly . There is such thing as State. but they normally call it "State" lol
what
if data is in your viewModel it will survive configuration changes . thats for sure
o
A view should be able to be constructed at any time given the viewmodel at any point
I'm not talking about configuration changes, let's omit the Android details
I'm just talking about that, given I am a view builder and I want to build the login view, I need the login viewmodel for that
r
Umm , maybe . maybe not lol .ViewModel and state are differenr
o
Right now my login viewmodel only tells me what I need to do on login button click, but not about what the username and password text input is
Your example is more MVC tbh
r
Like consider this
A View and a State are a 1 to 1 relationship
lets keep this in mind
to clarify this
let me write some code
That is a View and its state
o
Yes
r
HappyViewState can always rebuild HappyView yes
o
Yes
r
However its a 1 to 1 relationship , if SadView comes in it may not have sunshine or a flower count
However ViewModel has a 1 to N relationship
o
Nope
r
in which many views can use the same viewmodel
it does
even in android
o
I mean, it's very vague in what one describes to be a view
r
You can share viewModels
o
But let's call it a screen
One screen = one viewmodel
r
sure let me write more sudo code
nope
not at all
because views only observe viewModel
they don't base there state directly from them
o
This is just one example, majority agrees that 1 screen = 1 viewmodel
r
Majority can agree, but it doesn't make it correct lol
o
Lol idk what you are trying to portray, but the point was that you couldn't build your view from your viewmodel
r
The snippet up there is a 1 to 2 relationship right . both happyview and sadView used the same viewModel , and observe the countCloud
This is proof that ViewModel and state are not the same
o
That's a viewmodel with a too abstract data to begin with, viewmodel should say how the title, buttonText etc. look like directly instead of the view make decide that
But that's a different discussion
r
lol it doesn't . if it did it would be called State lol
o
Instead of countClouds: Int, it should be screenTitle: String = "The count is $countClouds"
Model is state
r
Its like me saying a Presenter is State lol
o
It is in the name, viewmodel
It is the model of the view
It is a serialized version of the View
r
💀
lo
we just agreed that state and View is 1 to 1 . and I just showed you a situtation where viewModel and view can be 1 to many . If you can accept the premise why not the conclusion lol
hahaha its all fun I think we are off topic anyway. but its just my opinion
o
Dude lmao it's called viewmodel, not viewsmodel
😂 1
It's a model of a single view
r
Sure it is lol
o
Why would you make a model for multiple views, that is just uneccessary breaking the seperation of concerns rule
or the SRP rule
r
lol of course not
o
It's in the name man, viewmodel
the name itself states there is a 1-1 relation of view and model
r
Viewmodels, are not 1 to 1 lol
and they are not State
if they were they would be called State
o
Haha ok dude I give up, you can use it however you want, no problems w/ me
🤣 1
r
you can conduct network calls from ViewModels, but you shouldn't from a state class
lol , i win . But Yea for the original question . Reconsider how the livedata is being utilize and make sure its within the right usecase
😂 2
o
long live viewsmodel
😂 1
r
And the State , that wasn't a State . Sort of reminds me of Washington DC 😂
a
I'm inclined to agree with @rkeazor here 😅 I mean, isn't that what shared viewmodels are for?
😅 1
34 Views
Open in Slack
PreviousNext
Powered by