Ignore null value and use the default value when deserializing from json string

Ignore null value and use the default value when deserializing from json string

[NightlyNexus]

See #762

It's not what i want.

My bean is:

class Foo @SuppressWarnings("unused") constructor() {
    @Json(name = "id")
    var id: Int = 0

    @Json(name = "name")
    var name: String = ""
}

And the serve return json :

{
"id": 1,
"name": null
}

About the "name" filed, I want to skip the null value and use the the default "", and also null array filed.
How can i deal with those cases?

[NightlyNexus]

there are a few ways to achieve what you want. here's a relatively short way that comes to mind:

class Foo {
  var id: Int = 0
  internal var name: String? = ""
  fun getName(): String = name ?: ""
  fun setName(name: String) {
    this.name = name
  }
}

@Test fun foo() {
  val encoded = """
    {
      "id": 1,
      "name": null
    }"""
  val decoded = Foo()
  val moshi = Moshi.Builder().add(KotlinJsonAdapterFactory()).build()
  val adapter = moshi.adapter(Foo::class.java)
  adapter.fromJson(encoded)!!.run {
    assertThat(id).isEqualTo(1)
    assertThat(getName()).isEqualTo("")
  }
  assertThat(adapter.toJson(decoded)).isEqualTo("""{"id":0,"name":""}""")
}

[leleliu008]

@NightlyNexus although it works fine, but I think it isn't a best solution. Because the Foo class generated by tools, not by hand usually, your solution is not convenient. I think the best solution is provide a ignore JSONNULL strategy by moshi lib itself.

[ZacSweers]

@ildar2 to answer your FR in #1000, the best solution is for you to either

• Work with your server folks on sending down more reasonable json. Using null values to indicate absence in a map isn't right since the key is what determines presence
• If the API is external, write a delegating adapter that reads the jsonValue map first and removes all keys with null values before passing it to the delegate.

I don't think it's in our interest to effectively break moshi's behavior to accommodate unscrupulous APIs that conflate absence and nullability.

[condesales]

@ZacSweers
In an ideal world, that would be the rule, but we all know that's not always the case.
The rule I follow in all apps I write is: "never trust the API responses"
So all my fields for API response models are nullable and I add default values in case they're not provided.

[ildar2]

@condesales default values are used only if api responce misses this field. If the field was explicitly null, then your field will be null, regardless of kotlin nullability. But you can work around that with reserialization - null fields get stripped. Here is a passing test, where preLoc?.mobileLoading was initially null, but after reserialization become default value, therefore we can set fields non-null, avoiding nullability issues:

    @Test
    fun `test null field should return default value gson`() {
        var preLoc = Gson().fromJson(
            "{\"mobile.loading\" : null, \"mobile.continue\" : \"Continue\"}",
            PreLocalize::class.java
        )
        assertNull(preLoc?.mobileLoading)
        val strippedOfNulls = Gson().toJson(preLoc)
        preLoc = Gson().fromJson(strippedOfNulls, PreLocalize::class.java)
        assertEquals("Continue", preLoc?.mobileContinue)
        assertEquals("City", preLoc?.commonCity)
        assertEquals("Loading", preLoc?.mobileLoading)
    }

[ZacSweers]

in case they're not provided.

This is the case (absent key) that Moshi's Kotlin support handles. However, null as a value is not such a case, as it's the server explicitly declaring the value.

[leleliu008]

@ZacSweers @condesales What does null mean? Obviously, different people have their own opinions about this question. Those people who want to ignore the null value, maybe they treat the null as a meaningless value. questions do not always have one answer.

[ZacSweers]

It has one answer in Moshi and this is Moshi's opinion :).

[leleliu008]

@ZacSweers a clear answer.

[ZacSweers]

his opinion that we can just ask for reasonable JSON across the entire internet is naive.

That's not what I said, so let me be clear.

Moshi's opinion in Kotlin is that present keys with literal null values are null (and therefore not candidates for default values) while absent keys are absent (and therefore candidates for default values). Moshi's got no opinion on how you do or don't collaborate with whoever is sending you JSON, so please don't take it that way. If you want nulls to indicate absence and can't make the sending API adhere to this, you can do a number of other options too pre-format this json before handing it to moshi.

Here's one that works via intermediary delegating adapter that manually removes nulls from the json blob:

@Retention(RUNTIME)
@Target(CLASS)
annotation class DefaultIfNull

class DefaultIfNullFactory : JsonAdapter.Factory {
  override fun create(type: Type, annotations: MutableSet<out Annotation>,
      moshi: Moshi): JsonAdapter<*>? {
    if (!Types.getRawType(type).isAnnotationPresent(
            DefaultIfNull::class.java)) {
      return null
    }

    val delegate = moshi.nextAdapter<Any>(this, type, annotations)

    return object : JsonAdapter<Any>() {
      override fun fromJson(reader: JsonReader): Any? {
        @Suppress("UNCHECKED_CAST")
        val blob = reader.readJsonValue() as Map<String, Any?>
        val noNulls = blob.filterValues { it != null }
        return delegate.fromJsonValue(noNulls)
      }

      override fun toJson(writer: JsonWriter, value: Any?) {
        return delegate.toJson(writer, value)
      }
    }
  }
}

class NullSkipperTest {

  @DefaultIfNull
  data class ClassWithDefaults(val foo: String, val bar: String? = "defaultBar")

  @Test
  fun skipNulls() {
    //language=JSON
    val json = """{"foo": "fooValue", "bar": null}"""

    val adapter = Moshi.Builder()
        .add(DefaultIfNullFactory())
        .add(KotlinJsonAdapterFactory())
        .build()
        .adapter(ClassWithDefaults::class.java)

    val instance = adapter.fromJson(json)!!
    check(instance.bar == "defaultBar")
  }
}

[djensen47]

Ah thank you for the clarification!

P.S., sorry, didn't mean seem so harsh ... definitely appreciate the great work you all do.