Kotlin Native peut-il remplacer Swift comme langage de programmation officiel d’iOS ?



par

La conférence Mobius 2018 qui s'est tenue à Saint-Pétersbourg au début de l'année a présenté un exposé des gars de Revolut - Roman Yatsina et Ivan Vazhnov, intitulé Architecture multiplateforme avec Kotlin pour iOS et Android.

Après avoir regardé l'exposé en direct, j'ai voulu essayer de voir comment Kotlin/Native gère le code multiplateforme qui peut être utilisé à la fois sur iOS et Android. J'ai décidé de réécrire un peu le projet de démonstration du talk pour qu'il puisse charger la liste des dépôts publics de l'utilisateur depuis GitHub avec toutes les branches de chaque dépôt.


Project structure

  1. multiplatform 
  2. ├─ android 
  3. ├─ common 
  4. ├─ ios 
  5. ├─ platform-android 
  6. └─ platform-ios 

Common module


common is the shared module that only contains Kotlin with no platform-specific dependencies. Il peut également contenir des interfaces et des déclarations de classes/fonctions sans que les implémentations ne dépendent d'une certaine plateforme. Such declarations allow using the platform-dependent code in the common module.

In my project, this module encompasses the business logic of the app – data models, presenters, interactors, UIs for GitHub access with no implementations.

Some examples of the classes

UIs for GitHub access:

  1. expect class ReposRepository { 
  2. suspend fun getRepositories(): List 
  3. suspend fun getBranches(repo: GithubRepo): List 
  4. } 

Regardez bien le mot-clé expect. Il fait partie des déclarations expected et actual. Le module commun peut déclarer la déclaration attendue qui a la réalisation réelle dans les modules de la plateforme. By the expect keyword we can also understand that the project uses coroutines which we’ll talk about later.

Interactor:

  1. class ReposInteractor( 
  2. private val repository: ReposRepository, 
  3. private val context: CoroutineContext 
  4. ) { 
  5.  
  6. suspend fun getRepos(): List { 
  7. return async(context) { repository.getRepositories() } 
  8. .await() 
  9. .map { repo -> 
  10. repo to async(context) { 
  11. repository.getBranches(repo) 
  12. } 
  13. } 
  14. .map { (repo, task) -> 
  15. repo.branches = task.await() 
  16. repo 
  17. } 
  18. } 
  19. } 

The interactor contains the logic of asynchronous operations interactions. First, it loads the list of repositories with the help of getRepositories() and then, for each repository it loads the list of branches getBranches(repo). The async/await mechanism is used to build the chain of asynchronous calls.

ReposView interface for UI:

  1. interface ReposView: BaseView { 
  2. fun showRepoList(repoList: List) 
  3. fun showLoading(loading: Boolean) 
  4. fun showError(errorMessage: String) 
  5. } 

The presenter

The logic of UI usage is specified equally for both the platforms.

  1. class ReposPresenter( 
  2. private val uiContext: CoroutineContext, 
  3. private val interactor: ReposInteractor 
  4. ) : BasePresenter() { 
  5.  
  6. override fun onViewAttached() { 
  7. super.onViewAttached() 
  8. refresh() 
  9. } 
  10. fun refresh() { 
  11. launch(uiContext) { 
  12. view?.showLoading(true) 
  13. try { 
  14. val repoList = interactor.getRepos() 
  15. view?.showRepoList(repoList) 
  16. } catch (e: Throwable) { 
  17. view?.showError(e.message ?: "Can't load repositories") 
  18. } 
  19. view?.showLoading(false) 
  20. } 
  21. } 
  22. } 

Quoi d'autre pourrait être inclus dans le module commun

Parmi tout le reste, la logique de parsing JSON pourrait être incluse dans le module commun. La plupart des projets contiennent cette logique sous une forme compliquée. L'implémenter dans le module commun pourrait garantir un traitement similaire des données entrantes du serveur pour iOS et Android.

Malheureusement, dans la bibliothèque de sérialisation kotlinx.serialization, le support de Kotlin/Native n'est pas encore implémenté.

Une solution possible pourrait être d'écrire votre propre bibliothèque ou de porter l'une des bibliothèques plus simples basées sur Java pour Kotlin. Sans utiliser de réflexions ou d'autres dépendances tierces. Cependant, ce type de travail va au-delà d'un simple projet de test ♂️

Modules de plateforme

Les modules de plateforme-android et platform-ios contiennent à la fois l'implémentation dépendante de la plateforme des interfaces utilisateur et des classes déclarées dans le module commun, et tout autre code spécifique à la plateforme. Those modules are also written with Kotlin.

Let’s look at the ReposRepository class implementation declared in the common module.

platform-android

  1. actual class ReposRepository( 
  2. private val baseUrl: String, 
  3. private val userName: String 
  4. ) { 
  5. private val api: GithubApi by lazy { 
  6. Retrofit.Builder() 
  7. .addConverterFactory(GsonConverterFactory.create()) 
  8.  
  9. .addCallAdapterFactory(CoroutineCallAdapterFactory()) 
  10. .baseUrl(baseUrl) 
  11. .build() 
  12. .create(GithubApi::class.java) 
  13. } 
  14.  
  15. actual suspend fun getRepositories() = 
  16. api.getRepositories(userName) 
  17. .await() 
  18. .map { apiRepo -> apiRepo.toGithubRepo() } 
  19.  
  20. actual suspend fun getBranches(repo: GithubRepo) = 
  21. api.getBranches(userName, repo.name) 
  22. .await() 
  23. .map { apiBranch -> apiBranch.toGithubBranch() } 
  24. } 

In the Android implementation, we use the Retrofit library with an adaptor converting the calls into a coroutine-compatible format. Note the actual keyword we’ve mentioned above.

platform-ios

  1. actual open class ReposRepository { 
  2.  
  3. actual suspend fun getRepositories(): List { 
  4. return suspendCoroutineOrReturn { continuation -> 
  5. getRepositories(continuation) 
  6. COROUTINE_SUSPENDED 
  7. } 
  8. } 
  9.  
  10. actual suspend fun getBranches(repo: GithubRepo): List { 
  11. return suspendCoroutineOrReturn { continuation -> 
  12. getBranches(repo, continuation) 
  13. COROUTINE_SUSPENDED 
  14. } 
  15. } 
  16. open fun getRepositories(callback: Continuation>) { 
  17. throw NotImplementedError("iOS project should implement this") 
  18. } 
  19.  
  20. open fun getBranches(repo: GithubRepo, callback: Continuation>) { 
  21. throw NotImplementedError("iOS project should implement this") 
  22. } 
  23. } 

You can see the actual implementation of the ReposRepository class for iOS in the platform module does not contain the specific implementation of server interactions. Au lieu de cela, le code suspendCoroutineOrReturn est appelé depuis la bibliothèque standard Kotlin et nous permet d'interrompre l'exécution et d'obtenir le callback de continuation qui doit être appelé à la fin du processus d'arrière-plan. Ce callback est ensuite passé à la fonction qui sera respécifiée dans le projet Xcode où toute l'interaction avec le serveur sera implémentée (en Swift ou Objective-C). La valeur COROUTINE_SUSPENDED signifie l'état suspendu et le résultat ne sera pas retourné immédiatement.

Application iOS

Ce qui suit est un projet Xcode qui utilise le module platform-ios comme un framework Objective-C générique.

Pour assembler platform-ios en un framework, utilisez le plugin Gradle konan. Its settings are in the platform-ios/build.gradle file:

  1. apply plugin: 'konan' 
  2.  
  3. konanArtifacts { 
  4. framework('KMulti', targets: ['iphone_sim']) { 
  5. ... 

KMulti est un préfixe pour le framework. All the Kotlin classes from the common and platform-iosmodules in the Xcode project will have this prefix.

After the following command,

  1. ./gradlew :platform-ios:compileKonanKMultiIphone_sim 

the framework can be found under:

  1. /kotlin_multiplatform/platform-ios/build/konan/bin/ios_x64 

It has to be added to the Xcode project.

This is how a specific implementation of the ReposRepository class looks like. The interaction with a server is done by means of the Alamofire library.

  1. class ReposRepository: KMultiReposRepository { 
  2. ... 
  3. override func getRepositories(callback: KMultiStdlibContinuation) { 
  4. let url = baseUrl.appendingPathComponent("users/(githubUser)/repos") 
  5. Alamofire.request(url) 
  6. .responseJSON { response in 
  7. if let result = self.reposParser.parse(response: response) { 
  8. callback.resume(value: result) 
  9. } else { 
  10. callback.resumeWithException(exception: KMultiStdlibThrowable(message: "Can't parse github repositories")) 
  11. } 
  12. } 
  13. } 
  14. override func getBranches(repo: KMultiGithubRepo, callback: KMultiStdlibContinuation) { 
  15. let url = baseUrl.appendingPathComponent("repos/(githubUser)/(repo.name)/branches") 
  16. Alamofire.request(url) 
  17. .responseJSON { response in 
  18. if let result = self.branchesParser.parse(response: response) { 
  19. callback.resume(value: result) 
  20. } else { 
  21. callback.resumeWithException(exception: KMultiStdlibThrowable(message : "Can't parse github branches")). 
  22. } 
  23. } 
  24. } 
  25. } 

Android app

With an Android project it is all fairly simple. We use a conventional app with a dependency on the platform-android module.

  1. dependencies { 
  2. implementation project(':platform-android') 

Essentially, it consists of one ReposActivity which implements the ReposView interface.

  1. override fun showRepoList(repoList: List) { 
  2. adapter.items = repoList 
  3. adapter.notifyDataSetChanged() 
  4. } 
  5.  
  6. override fun showLoading(loading: Boolean) { 
  7. loadingProgress.visibility = if (loading) VISIBLE else GONE 
  8. } 
  9.  
  10. override fun showError(errorMessage: String) { 
  11. Toast.makeText(this, errorMessage, Toast.LENGTH_LONG).show() 
  12. } 

Coroutines, apples, and magic

Speaking of coroutines and magic, in fact, at the moment coroutines are not yet supported by Kotlin/Native. The work in this direction is ongoing. So how on Earth do we use the async/awaitcoroutines and functions in the common module? Let alone in the platform module for iOS.

As a matter of fact, the async and launch expect functions, as well as the Deferred class, are specified in the common module. These signatures are copied from kotlinx.coroutines.

  1. import kotlin.coroutines.experimental.Continuation 
  2. import kotlin.coroutines.experimental.CoroutineContext 
  3.  
  4. expect fun async(context: CoroutineContext, block : suspend () -> T) : Deferred 
  5.  
  6. expect fun launch(context: CoroutineContext, block: suspend () -> T) 
  7.  
  8. expect suspend fun withContext(context: CoroutineContext, block: suspend () -> T): T 
  9.  
  10. expect class Deferred { 
  11. suspend fun await(): T 
  12. }  

Coroutines Android

Dans le module plateforme-android, les déclarations sont mappées dans leurs implémentations à partir de kotlinx.coroutines:

  1. actuel fun async(context : CoroutineContext, block: suspend () -> T): Deferred { 
  2. return Deferred(async { 
  3. kotlinx.coroutines.experimental.withContext(context, block = block) 
  4. }) 
  5. } 

Coroutines iOS

Avec iOS les choses sont un peu plus compliquées. Comme mentionné ci-dessus, nous passons le callback continuation(KMultiStdlibContinuation) aux fonctions qui doivent travailler de manière asynchrone. Upon the completion of the work, the appropriate resume or resumeWithExceptionmethod will be requested from the callback:

  1. override func getBranches(repo: KMultiGithubRepo, callback: KMultiStdlibContinuation) { 
  2. let url = baseUrl.appendingPathComponent("repos/(githubUser)/(repo.name)/branches") 
  3. Alamofire.request(url) 
  4. .responseJSON { response in 
  5. if let result = self.branchesParser.parse(response: response) { 
  6. callback.resume(value: result) 
  7. } else { 
  8. callback.resumeWithException(exception: KMultiStdlibThrowable(message: "Can't parse github branches")) 
  9. } 
  10. } 
  11. } 

Pour que le résultat revienne de la fonction de suspension, nous devons implémenter l'interface ContinuationInterceptor. Cette interface est responsable de la façon dont le callback est traité, spécifiquement dans quel thread le résultat (s'il y en a un) sera retourné. For this, the interceptContinuation function is used.

  1. abstract class ContinuationDispatcher : 
  2. AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor { 
  3.  
  4. override fun interceptContinuation(continuation: Continuation): Continuation { 
  5. return DispatchedContinuation(this, continuation) 
  6. } 
  7.  
  8. abstract fun dispatchResume(value: T, continuation: Continuation): Boolean 
  9. abstract fun dispatchResumeWithException(exception: Throwable, continuation: Continuation<*>): Boolean 
  10. } 
  11.  
  12. internal class DispatchedContinuation( 
  13. private val dispatcher: ContinuationDispatcher, 
  14. private val continuation: Continuation 
  15. ) : Continuation { 
  16.  
  17. override val context: CoroutineContext = continuation.context 
  18.  
  19. override fun resume(value: T) { 
  20. if (dispatcher.dispatchResume(value, continuation).not()) { 
  21. continuation.resume(value) 
  22. } 
  23. } 
  24.  
  25. override fun resumeWithException(exception: Throwable) { 
  26. if (dispatcher.dispatchResumeWithException(exception, continuation).not()) { 
  27. continuation.resumeWithException(exception) 
  28. } 
  29. } 
  30. } 

In ContinuationDispatcher there are abstract methods implementation of which will depend on the thread where the executions will be happening.

Implementation for UI threads

  1. import platform.darwin.* 
  2.  
  3. class MainQueueDispatcher : ContinuationDispatcher() { 
  4.  
  5. override fun dispatchResume(value: T, continuation: Continuation): Boolean { 
  6. dispatch_async(dispatch_get_main_queue()) { 
  7. continuation.resume(value) 
  8. } 
  9. return true 
  10. } 
  11.  
  12. override fun dispatchResumeWithException(exception: Throwable, continuation: Continuation<*>): Boolean { 
  13. dispatch_async(dispatch_get_main_queue()) { 
  14. continuation.resumeWithException(exception) 
  15. } 
  16. return true 
  17. } 
  18. } 

Implementation for background threads

  1. import konan.worker.* 
  2.  
  3. class DataObject(val value: T, val continuation: Continuation) 
  4. class ErrorObject(val exception: Throwable, val continuation: Continuation) 
  5.  
  6. class AsyncDispatcher : ContinuationDispatcher() { 
  7.  
  8. val worker = startWorker() 
  9.  
  10. override fun dispatchResume(value: T, continuation: Continuation): Boolean { 
  11. worker.schedule(TransferMode.UNCHECKED, {DataObject(value, continuation)}) { 
  12. it.continuation.resume(it.value) 
  13. } 
  14. return true 
  15. } 
  16.  
  17. override fun dispatchResumeWithException(exception: Throwable, continuation: Continuation<*>): Boolean { 
  18. worker.schedule(TransferMode.UNCHECKED, {ErrorObjeвыct(exception, continuation)}) { 
  19. it.continuation.resumeWithException(it.exception) 
  20. } 
  21. return false 
  22. } 
  23. } 

Now we can use the asynchronous manager in the interactor:

  1. let interactor = KMultiReposInteractor( 
  2. repository: repository, 
  3. context: KMultiAsyncDispatcher() 
  4. ) 

And the main thread manager in the presenter:

  1. let presenter = KMultiReposPresenter( 
  2. uiContext: KMultiMainQueueDispatcher(), 
  3. interactor: interactor 
  4. ) 

Key takeaways

The pros:

  • The developers implemented a rather complicated (asynchronous) business logic and common module data depiction logic.
  • You can develop native apps using native libraries and instruments (Android Studio, Xcode). Toutes les capacités des plateformes natives sont disponibles à travers Kotlin/Native.
  • C'est sacrément efficace !

Les inconvénients:

  • Toutes les solutions Kotlin/Native du projet sont encore au statut expérimental. Utiliser des fonctionnalités comme celle-ci dans le code de production n'est pas une bonne idée.
  • Pas de support pour les coroutines pour Kotlin/Native hors de la boîte. Espérons que ce problème sera résolu dans un avenir proche. Cela permettrait aux développeurs d'accélérer considérablement le processus de création de projets multiplateformes tout en le simplifiant.
  • Un projet iOS ne fonctionnera que sur les appareils arm64 (modèles à partir de l'iPhone 5S).

.