In my company, we have an abstraction that abstracts Activities/Fragments/Composables so the caller ...

# detekt

[juliocbcotta]

In my company, we have an abstraction that abstracts Activities/Fragments/Composables so the caller does not need to have a reference to the called. With that we can set the screen classes/functions and the related classes (data classes, VMs, retrofit services..) as internal , but this is a manual work and it is very easy to forget to do so, which tool could be used to verify the visibility of those classes ? Would detekt with a custom rule be a good fit to create these checks?

[Brais Gabin]

Sorry, I don't understand what are you looking for.

[juliocbcotta]

I wanted a lint rule (?) that would say "this class should be tagged as internal because the only usage you have is bound to this Activity/Fragment/Composable"

[Brais Gabin]

How would you identify "this class"? Does it extend some known abstract classes?

[juliocbcotta]

Imports? Public field? Method parameter?

[juliocbcotta]

The ViewModel is a subclass that we know of

[Brais Gabin]

Then sure, detekt can do that.

[Brais Gabin]

You can create a custom rule to find those type of things and then check their visibility and if it is not internal report an issue.

[juliocbcotta]

Nice, I will read detekt docs.

[Brais Gabin]

Perfect. I also recommend you to think about which issues can do things similar to what you want to see how they find that code. In general all the rules have those two parts. Search for the code that can have the issue, then check if the issue is there and report if that's the case.

For example, UnnecessaryLet first looks for all the usages of let and then it do its "magic".