Ktor. Benefits Over Retrofit.

This is a transcription of the video above


In this lesson, we’ll look at the networking library we’ll be using throughout the course: Ktor.

If you’ve worked with Android before, you’re probably familiar with Retrofit, which is widely used and loved for its clean interface and ease of use. But in Kotlin Multiplatform we use Ktor.


What is Ktor?

Ktor is a Kotlin-first asynchronous framework developed by JetBrains. It supports both server and client-side development. This means we can actually build servers with Ktor — but in this course we’ll only be focusing on the Ktor Client.

What makes Ktor awesome is that like many KMP libraries it is designed to work seamlessly across multiple platforms: Android, iOS, JVM, JavaScript, macOS, native, etc. This makes it a perfect fit for Kotlin Multiplatform, where we want to write as much shared code as possible.

Why We Can’t Use Retrofit in KMP

Retrofit is awesome — on Android. But, unfortunately we can’t use it in KMP. Let’s understand why by looking at the standard Retrofit code in Android. 👇


First up we have the standard interface declaration of an API called NewsService . This API call will fetch us the headlines via a GET REST call.

In the second piece of code, we have the creation of our Retrofit instance by invoking the Retrofit.Builder().build. Then we use the Retrofit instance to create our NewService implementation based on the interface that we have declared above.

Can you see a problem that we might have if we tried to use the code above in KMP? Give it a thought and then look at the image below.

Well, one problem is that we’re using a @GET annotation in the interface declaration. Retrofit relies on Java’s Annotation Processing API to process code annotations like @GET, @POST, @PUT etc. From previous lessons we know that we can’t use Java’s APIs inside our shared code.

Another problem lies in this provideNewsService() code block. Here I have the actual implementation of the retrofit.create() method as it is in Retrofit’s Github repository. And what’s the issue here?

This code is using Java’s reflection API - which is another feature that is only native to JVM.

Since we don’t have access to JVM-based libraries in commonMain - we can’t use Retrofit. Let me clarify that a bit - we can’t use it in our shared code. But if we wanted to have a separate networking implementation for each platform - then by all means we can use Retrofit in androidMain. But such approach defeats the purpose of sharing business logic.


Ktor Benefits

So why is Ktor a great choice for KMP projects?

Ktor has many benefits, but some of the most notable ones are:

  • Multiplatform Support - Ktor has platform-specific clients for Android (OkHttp), iOS (Darwin), etc. These engines are also highly configurable.
  • Coroutine Support - Ktor uses Kotlin coroutines natively and takes full advantage of its’ features.
  • Content Negotiation - You can automatically serialize and deserialize JSON, XML, or other types of data formats.
  • Extensibility with interceptors - Ktor provides a powerful interception mechanism that allows you to add custom behavior to your application.
  • Authentication, Websockets, Plugins, etc. - Ktor many more interesting features that go beyond the scope of this course.

We’ll get our hands dirty with many of these features in this course. In the next lesson we’ll build our own implementation of Ktor Http Client.


Additional reads: 

https://blog.jetbrains.com/idea/2024/09/ktor-101-efficient-jvm-http-toolkit/

Complete and Continue  
Discussion

0 comments