Kotlin/Native and Multiplatform · Shared Build Script | raywenderlich.com

🎓 Courses & Articles
1
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1304635-kotlin-native-and-multiplatform/lessons/11
2

Hi Jay,

I am making my way thru the course (currently at Part 2, E11). It’s great so far. However, I wish I knew the reasoning why our “shared” module has to be an Android module. You briefly mentioned that it does not need to be and Android module but did not explain why you chose to do it (to me this approach does not feel right–shared code should be platform independent). Can you explain in more detail? Thanks!

3

Hi @jshvarts, thanks for the comment and question!

I think you’re referencing where we discuss using the android-library plugin in the shared project build.gradle file. If so, this is because we are accessing the Android SDK from the shared module in order to determine the Android OS version. This use case is somewhat artificial, but there could be other cases where you really do need access to the Android SDK from shared code. The iOS platform is wrapped in Kotlin/Native in a platform package, so we don’t need to do anything special for iOS.

For both iOS and Android though, we talk to platform-specific things in the shared project using the expect/actual mechanism. Ideally, the bulk of your shared code is platform-independent, and you only use expect/actual when you really need to. In the sample project, we also do so when setting up concurrency, since it is handled different between the platforms.

I hope that helps explain it and thanks again!

4

I appreciate the quick detailed response, Joe.

this is because we are accessing the Android SDK from the shared module in order to determine the Android OS version

I guess I will learn more about the need to access Android SDK from shared module later in the course. I am evaluating the Multiplatform approach to Mobile dev and was hoping to see that usually things are cleanly separated (shared, androidApp, iosApp similar to https://kotlinlang.org/docs/tutorials/native/mpp-ios-android.html) and if they are not, it’s an exception rather than the rule.

5

Sure thing @jshvarts!

Notice that in the official tutorial you linked to, they cheat a bit by only returning the string “Android” in the actual function platformName(). On iOS, they take advantage of the platform package to return the platform name and version.

In the course, since we access the Android SDK to get the Android version, we had to make the shared project an Android library. Note that this only affects the packaging for Android and the build process. In both cases, even the official tutorial, expect/actual is still used.

6

Thanks again! I totally get what you are saying. Good to know that “this only affects the packaging for Android and the build process.”! I am hoping that in my real world projects, the “shared” module will be of type “kotlin-multiplatform” only.