<@U0F8Y5E5A> why they are heavyweight? I wonder be...

# android

[miha-x64]

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

[mg6maciej]

What's your compile time?

[miha-x64]

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 🙂

[darkmoon_uk]

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

[darkmoon_uk]

@miha-x64 Promotes code-reuse, decoupled design, prevents newcomers to a project inserting code at inappropriate levels. Waiting a couple more seconds at build time is a small price to pay for all these benefits, as I see it.

[darkmoon_uk]

@miha-x64 Question; do you tend to keep all these modules in the same VCS repository, or separate?

[darkmoon_uk]

Git submodules have a bad rep; but I’ve been using them successfully for a while now.

[darkmoon_uk]

They may be otherwise unwieldy but the IntelliJ platform tooling seems to make it a non-issue.

[miha-x64]

@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.

[darkmoon_uk]

@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’.

[darkmoon_uk]

Sure enough, after organising into the modules; we’ve reused lots of it among half a dozen projects.

[darkmoon_uk]

Turns out maybe you just don’t reuse what you can’t (because of shoddy organisation)?

[miha-x64]

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 🙂

[darkmoon_uk]

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]

The fire will never go out Mike, as long as I know there are other brothers out there, staying SOLID, fighting the good fight.

[miha-x64]

@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.

[dariuszbacinski]

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]

And the only reasonable way to separate code is to create gradle module:/ which is overcomplicated imo

[dariuszbacinski]

Still i wouldn't use modules to separate app. You do not need modules to enforce good architecture when you have exp. devs in the team who does peer code review

[mgrzechocinski]

@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?

[mgrzechocinski]

Regarding switching Kotlin, it makes things even more complicated. Adding Kotlin support to such a huge project makes it build times even longer since any single Kotlin change triggers all Java sources to be recompiled and other way too...

[mgrzechocinski]

Summing up, until we find another solution, we have to stay with pure Java and use Kotlin in a future, brand new “Kotlin-only” project. Then it would be real fun and advantage of switching to a modern language. Otherwise, tooling doesn’t support Kotlin-Java interop as much as we need

[dariuszbacinski]

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;)

[mg6maciej]

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.

[mg6maciej]

With multimodule project @mgrzechocinski describes I would be eager to just create new modules using Kotlin only. Why not?

[mgrzechocinski]

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]

@mg6maciej regarding the link you provided, how do you know they didn’t like the result of slicing project into modules? Is there any public discussion around that?

[miha-x64]

@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.

[mg6maciej]

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

[mgrzechocinski]

@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?

[mg6maciej]

Build time.

[mg6maciej]

The project is small enough it's probably easy to merge the modules into a "monolith" (oh, I hope nobody in mobile world will ever reinvent this word) and see the difference.

[mg6maciej]

@karolkowalski @kasper.kondzielski Wanna share some thoughts about multimodule Android projects?

[miha-x64]

@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.

[mg6maciej]

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

[dariuszbacinski]

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

you can use debug lib like this

[mgrzechocinski]

@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

[dariuszbacinski]

but lib has to publishNonDefault true

[miha-x64]

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

[dariuszbacinski]

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

[dariuszbacinski]

i would double consider if you need all of those modules 😉 for me there are more downsides then benefits

[mgrzechocinski]

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

[kasper.kondzielski]

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