Kotlin Native può sostituire Swift come linguaggio di programmazione ufficiale di iOS?



di

La conferenza Mobius 2018 tenutasi a San Pietroburgo all'inizio di quest'anno ha ospitato un intervento dei ragazzi di Revolut - Roman Yatsina e Ivan Vazhnov, chiamato Architettura multipiattaforma con Kotlin per iOS e Android.

Dopo aver visto il discorso dal vivo, ho voluto provare come Kotlin/Native gestisce il codice multipiattaforma che può essere utilizzato sia su iOS che Android. Ho deciso di riscrivere un po' il progetto demo del talk in modo che potesse caricare l'elenco dei repository pubblici dell'utente da GitHub con tutti i rami di ogni repository.

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. Può anche contenere interfacce e dichiarazioni di classi/funzioni senza implementazioni che dipendono da una certa piattaforma. 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. } 

Guardate la parola chiave expect. Fa parte delle dichiarazioni expected e actual. Il modulo comune può dichiarare la dichiarazione attesa che ha la realizzazione effettiva nei moduli della piattaforma. 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. } 

Che altro potrebbe essere incluso nel modulo comune

Tra tutto il resto, la logica di analisi JSON potrebbe essere inclusa nel modulo comune. La maggior parte dei progetti contiene questa logica in una forma complicata. Implementarla nel modulo comune potrebbe garantire un trattamento simile dei dati in arrivo dal server per iOS e Android.

Purtroppo, nella libreria di serializzazione kotlinx.serialization il supporto di Kotlin/Native non è ancora implementato.

Una possibile soluzione potrebbe essere scrivere la propria o fare il porting di una delle librerie più semplici basate su Java per Kotlin. Senza usare riflessioni o altre dipendenze di terze parti. Tuttavia, questo tipo di lavoro va oltre un semplice progetto di test ♂️

Moduli della piattaforma

I moduli della piattaforma platform-android e platform-ios contengono sia l'implementazione dipendente dalla piattaforma delle UI e delle classi dichiarate nel modulo comune, sia qualsiasi altro codice specifico della piattaforma. 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. Invece, il codice suspendCoroutineOrReturn è chiamato dalla libreria standard Kotlin e ci permette di interrompere l'esecuzione e ottenere il callback di continuazione che deve essere chiamato al completamento del processo in background. Questo callback viene poi passato alla funzione che verrà nuovamente specificata nel progetto Xcode dove verrà implementata tutta l'interazione con il server (in Swift o Objective-C). Il valore COROUTINE_SUSPENDED indica lo stato di sospensione e il risultato non sarà restituito immediatamente.

App per iOS

Quello che segue è un progetto Xcode che usa il modulo platform-ios come framework Objective-C generico.

Per assemblare platform-ios in un framework, usate il plugin konan Gradle. 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 è un prefisso per il 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. }  

Coroutine Android

Nel modulo della piattaforma Android, le dichiarazioni sono mappate nelle loro implementazioni da kotlinx.coroutines:

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

iOS coroutines

Con iOS le cose sono un po' più complicate. Come detto sopra, passiamo la callback continuation(KMultiStdlibContinuation) alle funzioni che devono lavorare in modo asincrono. 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. } 

Per far sì che il risultato ritorni dalla funzione di sospensione, dobbiamo implementare l'interfaccia ContinuationInterceptor. Questa interfaccia è responsabile di come il callback viene elaborato, in particolare in quale thread il risultato (se esiste) verrà restituito. 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). Tutte le capacità delle piattaforme native sono disponibili attraverso Kotlin/Native.
  • Dannatamente funziona!

I contro:

  • Tutte le soluzioni Kotlin/Native nel progetto sono ancora in stato sperimentale. Usare caratteristiche come questa nel codice di produzione non è una buona idea.
  • Nessun supporto per le coroutine per Kotlin/Native fuori dalla scatola. Speriamo che questo problema venga risolto nel prossimo futuro. Questo permetterebbe agli sviluppatori di accelerare significativamente il processo di creazione di progetti multipiattaforma, semplificandolo allo stesso tempo.
  • Un progetto iOS funzionerà solo sui dispositivi arm64 (modelli a partire da iPhone 5S).