The package structure in my Android library is better
I’m writing an Android library (with its own Activity) that will be imported into other Android projects using Android aar packages.
My
goal is to publish just one class (let’s call it MyPlugin) that does all the work of providing public methods (calling activities, etc.); But in my opinion, all activities must be public; So I want to separate the classes that users want to use from the classes I don’t want to use. Something like this:
com.mycompany.myplugin.api
|--> MyPlugin (public class with public methods)
com.mycompany.myplugin.activities
|--> Acitivty1
|--> ....
|--> ActivityN (public? activities)
com.mycompany.myplugin.mystuff
|--> Services (protected? class with protected? methods)
With this design, I can say to the user “you should only use API packages”.
The problem is the Serivice class: it’s used by Activities and MyPlugin if I want it (or its methods) to be protected (so end users can see it).
I
know anything can be done by the end user through reflection, but I want it to be as clean and simple as possible.
The only solution I found was to have only one package with all the classes, but, as I said, I want to separate MyPlugin from Activities.
Solution
A common convention is to use a package called internal for private implementation/inner classes.
com.mycompany.myplugin // all public stuff here and in its subpackages
com.mycompany.myplugin.internal // all non public stuff
Also, follow @Drew’s answer:
It’s often good idea to populate your package by feature, not by component
Citations: