@mg6maciej why they are heavyweight? I wonder because I have 13 Gradle modules in my Android project 😱

What's your compile time?

It gets longer if I change several modules (sometimes I need clean/rebuild). But compilation after changing a single class leads to a build in several seconds. If it’s heavyweight only in terms of compile-time, I’d prefer better separation 🙂

@miha-x64 You’re not alone. I prefer highly modular design to my projects as well.

@darkmoon_uk I’m not familiar with Git submodules. All modules of a single project are under a single Git repo, but unpublished libraries (

project(’:someLib).projectDir = ...

) are located and versioned separately.

@miha-x64 Interestingly, when I ‘encouraged’ the team at work to adopt a more modular design; there was some dissent because ‘we never end up reusing code’.

We must reuse. Otherwise, our object-oriented design skills are bad. Developing a single project, which is about 10% done, I’ve made these: https://github.com/Miha-x64/LiveLists4GreenDAO https://github.com/Miha-x64/VkAuth https://github.com/Miha-x64/Blitz https://gist.github.com/Miha-x64/c3b0cff4f38690455d85d5c415024ebe And found my old code which I’m also enhancing and reusing: https://github.com/Miha-x64/Validation The more we reuse, the more we object-oriented 🙂

Completely agree; unfortunately I seem to spend my working life around people who would rather copy, paste & edit, every time. It’s bad for the soul.

@darkmoon_uk I was not aware of SOLID or even MVC for a long time. I was coding PHP websites in procedure fashion from scratch every time, copy-pasting and editing my previous functions to new projects sometimes. I knew what is OOP and polymorphism, but it looked not applicable for me and my development environment. I also didn’t like exceptions since I was able to check errno/errstr and be happy. One time (actually, about 1.5 years ago) someone showed me MVC and I’ve became really excited. He is using objects, as data models! This possibility was obvious for me, but I didn’t know what to do with it. As it turns out, this approach (and many other things) are really useful. And they’re even more useful in static languages (interfaces in PHP are not popular, programmers just invoke methods by their names). Since that moment, understanging of object-oriented design started to raise. And there’s even more ahead 🙂 So, maybe it makes sense to show some good examples to copy-pasters.

For Java app you do need separate modules to introduce modularity in your app, there are packages with package private scopes to separate your code. Unfortunately Kotlin is missing package private scope.

@dariuszbacinski depends on the project scale IMO. We’re in a moment when project with ~5600 Java files in a single Gradle module just doesn’t scale anymore. Single line change takes ~1-1,5min on MacBook Pro 13’’ (early 2015). Moreover, keeping 4-5 devs team strict about packaging is non trivial too. Regarding package-private scope, it doesn’t support nested packages what was always a blocker for me. Separating codebase into Gradle modules seems like a good idea in terms of code separation and project build time, especially when common, everyday changes are made within single “module” (in abstract meaning). Unfortunately, it’s neither easy in our codebase (yes, we’re not 100% SOLID), nor well-supported from Gradle point of view. AFAIK we’re still having issues with variant support for project libraries. I’m curious how you deal with it @miha-x64? Do you build your library modules in variants or do you simply publish default (release) configuration to the APK module?

but compilation time is a different problem, original question was about separating ui layer from data layer, creating modules to do that is an overkill imo. Ofc for a large project you can consider it but from day1 i wouldn't do that. So as always answer is: it depends;)

Don't get me wrong. I would love to have separate gradle module for each feature. But I know guys that tried it (https://github.com/asymmetric-team/secure-messenger-android) and they didn't like the result.

Due to circular dependencies. In practice, I would have to move nearly all my sources to a “common” library, then have APK module and Kotlin module, both depending on this common library. Still having issues with variants support though. Thanks for the link, I’ll check it

@mgrzechocinski in the most common situation I work with a single module for hours, each build&deploy takes up to 20-30 seconds. After that, I refactor and affect several modules, which may require full rebuild (about 1 minute). I have quite small codebase though (about 5k SLOC, I think, but not sure — can you suggest any measurement tools?), and Java part of this codebase is negligible — several GreenDAO entity classes, and rarely changed library modules (which also publicly available). The main goal of using these modules — an attempt to reuse: finally, I hope to create a JavaFX app from this project’s codebase.

@mgrzechocinski I happened to sit next to them in my previous work 🙂

@miha-x64 but do your modules have variant version? I mean, do you need moduleX to be provided in debug/release version? @mg6maciej ah, ok 🙂 I’m curious what problems they faced?

Build time.

@mgrzechocinski I need, so in ‘library' modules I write

if (/*fixme:BuildConfig.DEBUG*/ true) …

. AFAIK, there’s no way to depend on debug version of ilbrary 😕 Also, I was unable to find anything similar to

buildConfigField

in Java modules.

So your project is filled with these fixmes? I wouldn't like seeing this in my code.

debugCompile project(path: ':lib', configuration: 'debug')
    releaseCompile project(path: ':lib, configuration: 'release')

you can use debug lib like this

@miha-x64 it’s possible to so-called “publish non default configuration” of your Gradle library module to other modules. Huge drawback is that Gradle builds all variants of your library module even if you need one. It takes a lot of time. I’ve heard that Gradle 3.5 should make some improvements in this area

but lib has to

publishNonDefault true

@mg6maciej no, such things appear only while debugging and asserting. @dariuszbacinski thanks, I’ll try it!

but as @mgrzechocinski wrote, lib will be compiled twice for release and debug

pity to say, but have to agree. Hope Gradle 3.5 will change sth

btw: To solve long build time problem we use https://github.com/gojuno/mainframer