This series is about Kotlinx serialization library.

In the Part1 I wrote about the basic usage of the Kotlinx.serialization.

In the Part2 I wrote about how can we configure the Kotlinx.serilaization.

In the Part3 I wrote about Custom serializers and data classes.

Now I would like to write about using Custom serializer with 3rd party classes.

In the Part3 I had a data class with Date and BigDecimal data objects. But the class what I used in the serialization was own class. It was easy to annotate it with the proper annotation (with custom serializer).

Ok, but what can we…

This series is about Kotlinx serialization library.

In the Part1 I wrote about the basic usage of the Kotlinx.serialization.

In the Part2 I wrote about how can we configure the Kotlinx.serilaization.

Now I would like to show a real use case with some custom serialization:

Let's see an example: We have an object with some complex objects. Most times we are using Strings and primitives in our data classes. However sometimes we need to use some extra objects, like Date or Decimal objects. In this example we have a Warranty object. …

This is a series, you can find the first part of the story:

In the part1 article I have written about basic of the kotlinx.serialization.

As you know when you want to serialize or deserialize an object then we need a Json object. What is this ?

• Json is a configuration holder object

If you search in the Internet you can find a lot of article where there is a different syntax (JSON, or JsonConfiguration). The reason is API change in the RC release. …

Kotlinx.Serialization library a very interesting library. I have written an article about one reason why I recommend to use it in a Kotlin project.

Most of the serialization libraries using reflection (like GSON, Jackson, etc…). I think reflection is a hack. With reflection we are able to do lot of things what normal way is not possible. Like we can set null value to a non-nullable field. And reflection is not the most fast way how can instantiate an object. …

Well I have written an article about problem of using GSON (it will instantiate an object with null value(s) however object have non-nullable fields):

I wrote the solution is JetBrains serialization library: kotlinx.serialization

Let's see how can we use this library and I want to show some special cases too.

We need to annotate every class with "@Serializable" annotation which we want to serialize.

@Serializable 
data class Project(val name: String, val language: String)

After it we can use it in serialization or deserialization.

val string = Json.encodeToString(data)
or
val obj = Json.decodeFromString<Project>(string)

It is easy, isn't it ? And what…

When we are developing an android application earlier navigation was tricky thing because there was no any best practice how can we do the navigation between activities and fragments. Earlier I have seen lot of NavigationUtils and similar implementations. Any of that solutions was good (because there was no any alternatives) however all of them has some insufficiency:
- there is no any view in the IDE where we can see from which screen can we navigate to other screen
- adding transition (animation) is not too simple
- deeplink handling difficult (how and where to navigate)

Let's see how…

We can build a custom view easily when we developing Android applications. Why it is important ? Because sometimes we need more complex components like the built in components. For example we need an input field with a checkbox, or input field with a label.

You can find my project here:

There is a custom view component which contains a label, an input field, a radio button and a checkbox. Radio Buttons are in a Radio Button Group. It means only one could be selected.

And now let's see what will happen when we turn on the Don't keep activities…

I am working as an Android developer. Earlier most crashes was caused by NullPointerException (NPE). Why ? Because there was an object and one or many fields were not initialised in the object or any method wanted to use a field before we initialised it. Ok, how can we avoid from NPE ? For example we can wrote Unit Tests. Yes, however it is really hard to test all cases, especial when something is on the View side or it is really close to the OS.

Later there are some annotations -> @Nullable and @NonNull
It was useful to use…