Good afternoon everyone. Hope all is well.... I h...

# multiplatform

[coachroebuck]

Good afternoon everyone. Hope all is well....

I have been building a mobile application using KMM, and I have an observation. I have been following the MVI (model-view-intent) design pattern as I create interfaces. Below is an example definition:

interface SomeInterface <T>{
   fun emit(intent: T)
}

The iOS files that are generated add one or more underscores to the parameter name. For example:

viewModel.emit(intent_________: myIntent)

I didn't really think much of this, until now. As I continue to add features to my app, this will be a problem.

Is someone able to provide insight on this?

[Jan Holešovský]

Have a look at the generated shared.h (or so - depending on the module name). The signature for Swift has to have different names for different types, so the Kotlin<->Objective-C interop adds the underscores when there are multiple overloaded versions of the same function.
Eg. in our case, the following is generated; and I suppose something similar has to happen for you when you use generics (that have some limitations in mapping too, from what I know):
- (SharedCrossoidIntent *)putExtraName:(NSString * _Nullable)name value:(id<SharedCrossoidParcelable> _Nullable)value __attribute__((swift_name("putExtra(name:value:)")));
- (SharedCrossoidIntent *)putExtraName:(NSString * _Nullable)name value_:(id<SharedCrossoidSerializable> _Nullable)value __attribute__((swift_name("putExtra(name:value_:)")));
- (SharedCrossoidIntent *)putExtraName:(NSString * _Nullable)name value__:(SharedKotlinArray<NSString *> * _Nullable)value __attribute__((swift_name("putExtra(name:value__:)")));
- (SharedCrossoidIntent *)putExtraName:(NSString * _Nullable)name value___:(BOOL)value __attribute__((swift_name("putExtra(name:value___:)")));
is generated from:
fun putExtra(name: String?, value: Parcelable?): Intent
fun putExtra(name: String?, value: Serializable?): Intent
fun putExtra(name: String?, value: Array<String?>?): Intent
fun putExtra(name: String?, value: Boolean): Intent

[Jan Holešovský]

Hopefully you'll be able to improve the situation by using ObjCName annotation, but I've never needed it so far, so no experience with that myself: https://kotlinlang.org/docs/native-objc-interop.html#name-translation

[Daniel Seither]

Objective-C doesn’t disambiguate methods by type, only by name (including argument names because they are part of the method name). Both Kotlin and Swift can disambiguate by type though, so if in the future Kotlin can interface directly with Swift without going through Objective-C, this won’t be a problem anymore. Until then, you need to make sure that the signatures differ in name, not just in type.

[coachroebuck]

The signature for Swift has to have different names for different types...

Nice one! That means I get to rename the parameter name. The good news is that my mobile app is small enough to where there won't be too much impact. Thanks for that insight.