• Luoqiaoyou

    Luoqiaoyou

    2 years ago
    i got error "Unable to call non-designated initializer as super constructor", when i try to inherit WKWebView in ios.
    Luoqiaoyou
    Artyom Degtyarev [JB]
    3 replies
    Copy to Clipboard
  • spierce7

    spierce7

    2 years ago
    I’m in 1.3.70, and even though I clearly have a dependency declared, I’m not able to resolve the coroutines lib when compiling. Has anyone seen this issue?
    Unresolved reference: coroutines
    Unresolved reference: coroutines
    Unresolved reference: CoroutineDispatcher
    Unresolved reference: Dispatchers
    val iosMain by getting {
                dependencies {
                    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-native:${Versions.kotlinxCoroutines}")
    
                    implementation(Deps.ktor.client.ios)
                    implementation(Deps.ktor.feature.serialization.native)
                }
            }
    spierce7
    Kris Wong
    +1
    8 replies
    Copy to Clipboard
  • m

    magnumrocha

    2 years ago
    hello guys, anyone having problems with KMP project build with last version of XCode:
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld invocation reported errors
    m
    kpgalligan
    47 replies
    Copy to Clipboard
  • s

    Shawn Karber_

    2 years ago
    But the fetcher call cannot resolve launch, runBlocking, async, or anything in kotlinx.coroutines. Any ideas?
    s
    s
    +1
    5 replies
    Copy to Clipboard
  • Luoqiaoyou

    Luoqiaoyou

    2 years ago
    some strange errors in K/N target IOS string format. when i format string in this way:
    "id:$id,error:$error"
    i got error in runtime.both of them are object pass by ios framework callback. the second way is fine:
    "id:" + id +",error:" + error
    Luoqiaoyou
    Artyom Degtyarev [JB]
    13 replies
    Copy to Clipboard
  • c

    CLOVIS

    2 years ago
    I'm on Alpine Linux running JS tests. With
    CHROME_BIN=chromium-browser
    however it complains that
    Running as root without --no-sandbox is not supported.
    . I'm trying to add the
    --no-sandbox
    option, however I can't add it to
    CHROME_BIN
    . Is there an option somewhere in the multiplatform plugin to handle this? And if not, what are the solutions?
    c
    ian.shaun.thomas
    +1
    5 replies
    Copy to Clipboard
  • altavir

    altavir

    2 years ago
    @msink I followed your instructions and migrated from bintray to a regular maven-publish plugin. Mostly it works, but there are two problems: • For some reason Bintray treats platform directories as versions and creates versions with names like
    dataforge-meta-jvm
    alongside with normal versions. • When I try to push to a package which did not exist before, I get 404. Do you know some ways around those problems?
    altavir
    Robert Jaros
    +1
    12 replies
    Copy to Clipboard
  • c

    coletz

    2 years ago
    Hi everyone, I'm working on an android/ios project. I didn't used mpp in the last few months, so I'm not aware of the state of the art. Is there any way to use generics on kotlin and have them recognized in swift? I remember a draft from kpgalligan about that but I don't know if that's actually implemented in the latest k/n release
    c
    Jurriaan Mous
    2 replies
    Copy to Clipboard
  • dennis

    dennis

    2 years ago
    Currently trying to setup a Kotlin Multiplatform library, which should make use of another Kotlin (Native) library. The preferred way would be having the dependency as a submodule. Does anyone know if that’s possible and how to approach this?
    dennis
    1 replies
    Copy to Clipboard
  • krtko

    krtko

    2 years ago
    So I've been using Multiplatform for a while now and I have been enjoying the current set up. I think the features which would help me out the most are1. Inline platform specific code: Helps onboarding new users and beginners. Helps prototyping and simple platform calls 2. Abstract specific platform code: Helps library creators and reduces nesting1. Inline platform specific code: Ex.
    //LoginViewController is a pure kotlin class that inherits from the MPP class ViewController. ViewController contains several platform specific fields such as `context` on Android
    class LoginViewController: ViewController {
       fun someButtonWasPressed() {
          //A button was pressed callback
          //uh oh we need to drop into native code for some reason
          android { //An auto generated inlined lambda for the Android MMP
             this.context //we have access to LoginViewController's Android side
             this.androidDoSomething(this.context)
          }
          ios { //An auto generated inlined lambda for the iOS MMP
             NSLog("You have access to anything from the iOS MP project")
             val appDelegate = UIApplication.shared.delegate as AppDelegate
          }
       }
    
       @platform("android") fun androidDoSomething(context: Context) { //can have platform specific arguments
          //this method can only be called from an android context
          Log.d("hi","from android")
       }
       //this could also be nested in some "subclass" like structure like `android { fun androidDoSomething(context: Context) {} }`
    }
    This produces messier and harder to read code in most circumstances, however I think it provides huge benefits in these particular cases:1. Onboarding new users and beginners. Explaining the current MP project set up is not easy. I think if someone can start a project or contribute to a code base in the fashion above it will be significantly more clear to them. It's also a lot simpler to grasp out of the box vs the Actual/Expect system. Theres no indirection weaving back and forth between the different subproject for each platform. 2. Prototyping. The current Actual/Expect system works very well. It forces you to cleanly separate platform specific code from common code. Thats great except this can get in the way for when you are prototyping something and you just need to get the whole thing running in the most quick and simple fashion possible. I think the above system helps solve that as it reduces the need for nested platform code. 3. Simple platform calls.

    The current Actual/Expect system adds a lot of overhead for small platform specific methods. If the method is only ever going to be 1-3 lines per platform, its a lot of boiler plate to have a separate file for each platform specific instance of the method

    2. Abstract classes with the ability to declare abstract specific platform code: Ex.Library author
    abstract class ViewController {
       @platform("android") abstract fun getView(context: Context): View //even tho we are in common kotlin, the method declaration can access Android
       @platform("iOS") abstract fun getView(): UIView //even tho we are in common kotlin, the method declaration can access iOS
    }
    Library consumer
    class LoginViewController: ViewController {
        @platform("android") override fun getView(context: Context): View {
             //inflate and return a view
        }
    
        @platform("iOS") override fun getView(): UIView {
            val view = UIView()
            return view
        }
    }

    Library authors can currently do something like this by having an Actual/Expect abstract class with specific abstract methods for a given platform. My main issue with doing this is its not as clear to the library consumer and it requires more class nesting than the example above

    krtko
    Luoqiaoyou
    14 replies
    Copy to Clipboard