This is an efficient way to limit what is available to your consumers while fully allowing its usage inside your module. This visibility is similar to the package-private visibility in Java, but instead it's private to the entire module. Our best friend to keep implementation details out of the public API is the internal keyword. Let's take a look at some visibility options that Kotlin provides. Even when a module is meant to be consumed by a single application, it's best to treat it as a fully independent piece of software - as it is.

While this article is focused on libraries, the same is applicable to multi-module projects. Additionally, when changes are made to the actual implementations, it prevents making breaking changes by mistake. This will lead to more concise and easier to use APIs, indirectly, resulting in easier-to-maintain projects.

It is often good practice minimizing the libraries' functionality that is accessible to consumers. This means types, methods, properties, etc. Then, you annotate your test-only functions with that annotation so that whenever you try to use this function without explicitly opting in to using test-only code, you will get a compile-time error.When designing libraries, one important aspect is the public API surface. Internal annotation class VisibleForTestingOnly_DoNotUseInProductionCode

= 'This part of the API is visible only for testing.')

One of its intended uses is for 'Internal declarations that should not be used outside the declaring library, but are public for technical reasons', though in this case, the declaration should be private, but it is internal for technical reasons.įirst, you create an annotation with an obnoxiously long, specific name. You can do this by leveraging the annotation.

Kotlin internal fun