https://kotlinlang.org
Join Slack
I have a class I am using GSON to convert into the body of a REST request. When the class is markete...
# compose
g
I have a class I am using GSON to convert into the body of a REST request. When the class is marketed @Model for compose it adds “$record” and “frameId” into the json which breaks the request. Any good way to get around this?
Copy code
Expected (without @Model):
{"public_key":"","user":{"email":"<mailto:me@me.com|me@me.com>","password":"fun"}}

Actual (with @Model): 
{"$record":{"user":{"$record":{"me":"<mailto:guy@me.com|guy@me.com>","password":"fun","frameId":1}},"frameId":1},"public_key":""}
z
@Model
is getting deprecated. Is your class immutable? Then you should mark it 
@Immutable
instead.
g
the app model needs to be mutable.
how is @Model going to be deprecated?
z
Check out that PR linked in the tweet, more info there.
👍 1
g
Any way around the problem in the short term?
Wow. Big change.
When is this going beta?
z
It seems a bit unusual to have your JSON model type double as a live app model. My first instinct would be to make your JSON model immutable, and store it in a 
MutableState
. If you need to change your json model, just put a new instance into the state. If you can’t use an immutable value for some reason, then you can make a wrapper that maintains 
MutableState
properties for every property on your JSON object.
The team has declined to give a date for beta. The 
@Model
deprecation is landing in the next dev release though.
g
I have a message that can go over multiple transports. For messages that go only over one transport the message data structure becomes a field in the model. This avoids lots of translation.
not an easy way to have a class be a @Model and not @Model
z
I still don’t understand why your can’t just put your message values in 
MutableState
holders in your UI layer. How are your JSON model objects mutated?
g
GSON
RequestData (user name, user pass, public key)
ResponseData (units (id, public key))
z
IIRC, GSON will return a new instance when deserializing, not mutate an existing one, is that not true?
g
Correct.
But I can’t have the ResponseData be both model and not model
z
So what’s mutating your ResponseData?
g
it gets copied into the app model, however it could be changed in other ways.
will @Immutable still change the compose view
for instance the user can change the name and password.
that’s on the outgoing though
meh
z
In general, it’s a good practice to decouple your UI state from your backend data transfer layer.
7 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by