3

I've inherited a pretty big and old project with a tiny bit of technical debt which is still under active development. A couple of months ago we made the jump from Eclipse+Ant to Android Studio+Gradle. I don't have much experience with gradle now and had a lot less back then, so a colleague (who is also working on the project now) helped with the porting.

The project is actually 4 apps with a couple of partially shared libraries; i.e. app1 and app2 use library1, while app3 and app4 use library2 which depends on library1; and app1 and app3 (but not 2 and 4) use library3, etc. In the beginning app1 and -2 were practically the same app with minor differences (skinning), same with app3 and -4; much of the business logic is the same in all 4 apps, but over time functionality (UI layer and features - everything except the business logic) began to diverge more and more and today there are as many differences as commonalities.

My colleague lobbied for gradle flavors because that's the way it's done with gradle, but I've always been sceptical: those are not simple paid+unpaid versions or the same app with different skinning and they're growing further apart with each month. Nowadays, a feature is rarely implemented in all four apps; usually only in one or two of them.

In the past, a lot of the app-X only functionality has been built into the libraries with conditionals, which is icky (leads to spaghetti code), while I now try to move app-X only functionality into the top level flavor. The problem i'm running into is that the IDE and many tools don't work that well with flavors when it comes to code analysis and refactoring. Android Lint marks resources used by a different flavor as unused, usage search and most of the refactoring tools don't work well over flavor boundaries, ... - I'm changing one method in a shared library and the inactive flavors break without the IDE protesting - unless I manually switch flavors (or, in practise, jenkins informs me about failed builds). Refactoring is pretty much impossible right now which doesn't help with the debt at all.

So I'm thinking about moving to different app modules within the same project; my colleague protests because that's how it's done in eclipse but not in android studio+gradle and I'm just not "getting it" - but that's pretty much his only point.

Am I really just not getting it or is my colleague abusing the flavor system for something it was not designed for? Are there any downsides or pitfalls of using top level app modules instead of flavors?

stefs
  • 191
  • 8
  • 1
    In my experience, most programmers think that the technologies and languages that are familiar to them are the best. That may even be true, but it certainly doesn't help those of us that don't. In any case, pushing technology on you that you're not familiar with means its your colleague's responsibility to make you "get it," not yours. – Neil Aug 18 '15 at 14:16
  • That's it - he can't really give any arguments besides "you just don't get it". I think he's using flavors just because they exist, but actually using them the wrong way. The more i know about gradle and flavors, the more I'm convinced we're currently abusing that system (others agree). I guess one of the reasons he thinks like this is that app modules weren't supported that well in the early days of AS, but work much better now. – stefs Aug 18 '15 at 14:26
  • 1
    Is he your colleague or your boss? If he is your colleague, try to get him to see reason. Show him an example, show why your way would be better. If he still doesn't see reason, then you can tell your boss that your way would be better. Just be prepared to back up that statement. If he is your boss and not your colleague, best of luck. ;) – Neil Aug 18 '15 at 14:33
  • A colleague. I talked with a different colleague and he agrees with me - actually, he did organize another project the way I suggested and is very happy with it. Together we talked to the boss and she agreed with us - so we're reorganizing the project, even though the other dev might not be happy with it. My question was also about potential technical problems the move could introduce, but dev reported none. – stefs Aug 18 '15 at 14:43
  • Good man. If nothing else, you've learned how to be diplomatic. ;) – Neil Aug 18 '15 at 17:31
  • For what concerns technical problems, count on there being them. It would be silly to think otherwise. I can't help you anymore than that though. – Neil Aug 18 '15 at 17:38

0 Answers0