https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
j

Jon Bailey

02/16/2023, 5:55 PM
hey all, I have a multiplatform project that is made up of multiple modules. There is one called "networking" and one called "shared", shared depends on networking. I have some functions in networking that are public so they can be accessed in shared. is there a way to make them non public for the resulting shared library so they can't be access from the android and ios apps?
a

Adam S

02/16/2023, 6:00 PM
perhaps you’re looking for a custom OptIn annotation? https://kotlinlang.org/docs/opt-in-requirements.html#require-opt-in-for-api it won’t make elements private, but it’s the closest thing I can think of. It’s used in a lot of JetBrains libraries.
m

mbonnin

02/16/2023, 6:02 PM
If you make
network
an
implementation
dependency of
shared
it shouldn't be visible from your iOS and Android apps
l

Landry Norris

02/16/2023, 6:04 PM
The message above is good if there’s nothing in network that you want to expose to the app.
c

Casey Brooks

02/16/2023, 6:05 PM
Alternatively, keep it as an
api
dependency, but mark everything
internal
in your
:network
module that you don’t want accessible in
:shared
or your app projects
l

Landry Norris

02/16/2023, 6:05 PM
I don’t know if there’s a way to do this in Gradle, but the command line compiler has a ‘friend-module’ field.
j

Jon Bailey

02/16/2023, 6:05 PM
@mbonnin the problem with that is there are some types in networking that need to be visible in the app, eg some types that are returned by the functions, that get passed through logic to the apps
c

Casey Brooks

02/16/2023, 6:06 PM
ignore my comment, I ddn’t read the question closely enough 😅
m

mbonnin

02/16/2023, 6:06 PM
@Jon Bailey Ah oh well sounds like you need more modules then 😅
networking-api
and
networking-impl
(or so, don't trust me on naming)
Or else the
@OptIn
annotation from @Adam S would work too if you enable it module wide on
shared
, it's just more work to maintain these annotations
j

Jon Bailey

02/16/2023, 6:08 PM
ah I was hoping to avoid that because then it gets chaotic as I have more modules, would the OptIn work hiding things to ObjC?
l

Landry Norris

02/16/2023, 6:08 PM
If the netwprk/shared modules are in the same repo, I’m almost certain that
internal
things are accessible to anything in the same project, even across modules.
j

Jon Bailey

02/16/2023, 6:09 PM
@Landry Norris do you have a link to more info on the friend-module thing?
m

mbonnin

02/16/2023, 6:09 PM
If the netwprk/shared modules are in the same repo, I’m almost certain that
internal
things are accessible to anything in the same project, even across modules.
Nope, internal is "accessible in the same module only"
l

Landry Norris

02/16/2023, 6:10 PM
Just marked a class in foo module as internal in a project I have open, and it’s accessible in bar module. Edit: AS as usual takes forever to process changes
c

Casey Brooks

02/16/2023, 6:10 PM
internal
acts like
public
within a single gradle module, but is private to others that depend on it
m

mbonnin

02/16/2023, 6:10 PM
doc is quite clear about it:
Copy code
If you mark it as internal, it will be visible everywhere in the same module.
Unless you're dealing with some Java interop stuff/reflection
l

Landry Norris

02/16/2023, 6:11 PM
Looks like I was wrong. Just took a minute for AS to recognize the change.
m

mbonnin

02/16/2023, 6:12 PM
ah I was hoping to avoid that because then it gets chaotic as I have more modules, would the OptIn work hiding things to ObjC?
Not sure about ObjC.
@OptIn
is read by the Kotlin compiler so the Swift compiler might very well ignore it
j

Jon Bailey

02/16/2023, 6:13 PM
Also with OptIn it would still be visible to the Android app, you'd just have to explicitly opt in to use it?
m

mbonnin

02/16/2023, 6:14 PM
Yea you can't prevent users to opt-in
l

Landry Norris

02/16/2023, 6:14 PM
Can’t find any real docs on the friend module. Looks like it’s K/N only. Found this in the kotlinc-native compiler help output, but I haven’t done any testing with it.
Copy code
-friend-modules <path>     Paths to friend modules
m

mbonnin

02/16/2023, 6:15 PM
But same with modules, you can't prevent anyone to add
implementation(project("network-impl"))
to your android App (saying this to play the devil's advocate, I'm still pretty convinced multiple modules is the good solution for you)
j

Jon Bailey

02/16/2023, 6:16 PM
I think that more modules looks like the best way (or move everything into one module 😞), but that would still be difficult for internal functions on public types
m

mkrussel

02/16/2023, 6:18 PM
OptIn is not enforced from Objective-C. Kotlin 1.8 added
HiddenFromObjC
that you can also use.
m

mbonnin

02/16/2023, 6:19 PM
internal functions on public types
This way is "easy". You can have public types in internal functions signatures. The other way is not possible (public functions exposing internal types)
8 Views