call me "courageous" but I stopped using packages ...

# android-architecture

[ghedeon]

call me "courageous" but I stopped using packages for my apps). I just have a root "app" package and the actual application ID is being replaced by gradle. Why have nested folders com.smoothie.gyroscooter if you can keep it flat.

[gildor]

Kotlin style guide actually recomments to emit empty package dirs and this what people from JB and Kotlin Team do, also they do not use standard maven layout: src/(main|test)/(kotlin|java)/, just src/ and test/

[gildor]

Found it

In pure Kotlin projects, the recommended directory structure is to follow the package structure with the common root package omitted (e.g. if all the code in the project is in the “org.example.kotlin” package and its subpackages, files with the “org.example.kotlin” package should be placed directly under the source root, and files in “org.example.kotlin.foo.bar” should be in the “foo/bar” subdirectory of the source root).

https://kotlinlang.org/docs/reference/coding-conventions.html

[ghedeon]

With all due respect to kotlin, I believe on android the project layout is dictated by the gradle plugin. And even tho you can redefine source sets in gradle, I doubt it's worth the trouble to mess with non-orthodox paths, considering build variants and flavors... But at least flat packages are easy and it's for free, with the help of the built-in applicationId support. Except for libraries. There is no applicationId for libraries and I'm not sure how to solve it yet.

[gildor]

dictated by the gradle plugin

not dictated, but gradle plugin has default layout and not only on Android, same with Java projects

[gildor]

why not just omit empty dirs, I don’t understand why do you need applicationId for that?

[gildor]

applicationId and app package are not related, it’s just common practice to have the same appId and basic package

[gildor]

also there is no requirement to have package equal to dir structure, it’s also just a common practice because of java

[gildor]

considering build variants and flavors

exactly, default layout is created to allow easily add some code to another source set and this source set can be used by particular build type or flavor, but if you don’t use it, I don’t think that there is any problems with it

[arekolek]

I stopped using packages for my apps

do you use modules though? or is it all in the same module in the same package

[gildor]

I don’t see any problem with packages, it’s just how you organize code. And “nested folders `com.smoothie.gyroscooter`” is not a problem of packages and separation of code, just a base package

[ghedeon]

@arekolek maybe I worded that poorly, assuming your default package is “org.example.kotlin.foo.bar” I reduce it to "app" or just nothing and set applicationId to “org.example.kotlin.foo.bar”. So, the source path is src/main/java/Foo.kt

[gildor]

applicationId is not related on your default package

[gildor]

and source path can be src/main/java/Foo.kt even if Foo package is com.smoothie.gyroscooter

[gildor]

all those 3 things are not related

[ghedeon]

that's right, but than you have to be more specific with the question. In my understanding, the question was about actual folders structure and by default, AS generates nested folders that reflect the package

[gildor]

you can just delete them (empty dirs with default package) and no need even change build config

[ghedeon]

that's what I do

[ghedeon]

not for the library, tho

[ghedeon]

because we're back to no applicationId for libraries

[ghedeon]

so, it's not really "completely unrelated"

[ghedeon]

in absence of applicationId, if you want to get rid of nested folders in a library, you have to explicitly specify the desired package for your files (ex: package org.example.kotlin.foo.bar). Which is not required for the app module.

[ghedeon]

>dictated by the gradle plugin

not dictated, but gradle plugin has default layout

tautology

[ghedeon]

@arekolek as for the modules, @gildor rightfully mentioned that it's up to you, how you want to organize your code. I've seen people even having different modules for every app layer: data, domain, ui. Probably depends on the project scale, but imho it's unnecessary.

[gildor]

explicitly specify the desired package for your files (ex: package org.example.kotlin.foo.bar)

Yes, it’s true, you have to specify package. But for library you can just use any package, like mylib instead org.example.mylib