How can such a trivial app be so complex and tangled?

[Zordid]

I am sorry this might seem offending - but as a once-every-other-year developing Android Apps guy, I must really conclude: for this simple app, doing not more than offering Topics and News, how on earth can this project be so complex (with currently 50+ open issues) and still be the show case for developing Android Apps from Google?

I just opened the project, read some readme files (thanks for those, otherwise it would be completely impossible to follow) and must conclude: there is so much boilerplate code and silly lines of code doing not much - it makes me sad that this is supposed to be Android development in 2023... :-(

My app has not been updated for 5 years and I tried to use Google I/O app as a starter app, but really, I can throw it all away and still I would not be sure that this app shows the way on how to do a small, simple app correctly as there is so much weird stuff in there.

Does anybody know a REAL SIMPLE but correct project with a Jetpack Compose Android skeleton app that is easy to understand?

[dturner]

Thanks for the question and the feedback. I'm the tech lead on this project so it saddens me to hear that you've found it complex and tangled.

I can sympathise with your experience if you're coming back into Android development after few years. An incredible amount has changed, there's a lot of new stuff to learn (Compose, Kotlin, Coroutines, Flows, Material 3 etc) and news ways of doing things.

I think we can do a better job of marketing this project because it is not a good starting point for creating a simple app, or learning app development basics. For this, I would recommend the architecture sample or Compose samples (particularly Jetnews). I'd also recommend the excellent Android Basics in Compose course.

To clarify, this project is designed solve app problems at scale (e.g. multiple engineers/designers working on project, features developed in parallel, robust testing infrastructure). This is why it uses modularization, a three layer architecture, various data models, a separate app for the design elements and a bunch of other things which add complexity. It sounds like you're not running into the problems which this complexity solves, so it's just unnecessary noise and complication to you.

That said, I would be interested to hear what you thought was "boilerplate code and silly lines of code" - I'm sure we can do a better job of explaining what that code does and why it's there.

[mveroukis]

I've been programming Android for years, trying to switch over to Compose with navigation etc. Looking at this example is ridiculous and really just turns me off entirely. The whole point to AndroidX was to simplify things, but the reality is there's so much voodoo going on I have no idea how to follow this. Honestly I think I can do better without any of this over engineered shit.

[Danil0v3s]

@dturner said and I quote:

To clarify, this project is designed solve app problems at scale (e.g. multiple engineers/designers working on project, features developed in parallel, robust testing infrastructure). This is why it uses modularization, a three layer architecture, various data models, a separate app for the design elements and a bunch of other things which add complexity. It sounds like you're not running into the problems which this complexity solves, so it's just unnecessary noise and complication to you.

It saddens me to read an engineer gets turned off by looking at a challenging problem but perhaps this isn't really what you're looking for right now, so I respect that.

[dturner]

the reality is there's so much voodoo going on I have no idea how to follow this.

Genuine question, what do you consider "voodoo"? If you (and the OP @Zordid) tell us where you got stuck or what you're finding confusing we can take steps to fix it.

I can understand your frustration with not understanding a codebase, but just saying it's "over engineered shit" without saying why isn't really constructive.

[jari-kuipers]

I would have to call this discussion not very constructive but I have to say that I agree with the sentiment..

I recognize that splitting a project up like this is beneficial for scaling especially when working with multiple engineers.

Though I have to say that I'm definitely not a big fan of all the convention plugins. In my opinion it feels like they are very prone to (almost) duplication. They are also hard to understand especially because they referred to by string name inside the build-logic's gradle.kts file, which does not sit right with me at all. I don't think I will be taking the gradle setup of my project this way.

Another thing that really puts me off is the usage of usecases and repositories. They are used interchangably inside ViewModels. That is something I find odd to begin with since UseCases serve as a really good layer between VM and Repo's which would have helped the separation of concerns, I feel.

Another thing about that is the way that unidirectional data flows are used here. I've personally never been a big fan of using flows unidirectionally from ui to data layer continuously. There are a lot of cases where it can help but I feel that using normal suspend calls make the code easier to understand since you can still read through the code from top to bottom instead of having to dive deeper into the classes that the flow is going through. Because of this it took me quite some time to understand the relation between the SyncWorker and the feature modules.

[SimonMarquis]

In my opinion it feels like they are very prone to (almost) duplication.

This is the main purpose of convention plugins. Avoiding duplication of project configuration. If you don't see the benefit of it, it's probably because your projects did not reach the threshold where it makes sense to have dedicated build logic plugins 😉

They are also hard to understand especially because they referred to by string name inside the build-logic's gradle.kts file

This is not true for local plugins, they can be referenced like that:

-apply("nowinandroid.android.lint")
+apply<AndroidLintConventionPlugin>()

And for external plugins, this is a Gradle known issue that will probably fixed in the near future.

[jari-kuipers]

I stand by what I said. As of right now we have 2 projects that use convention plugins like this and while they might prevent duplication of dependencies to some extend, the convention plugins are prone to duplication themselves. When there are a lot of them it becomes hard to oversee if dependencies have been included in some convention plugins already or not.

So we actually have projects that have reached the threshold and are actually using this structure in production so I'm afraid you can't easily do away with me by telling me that we aren't there yet as if we aren't part of some "people who know" inner circle group.

I'm starting to feel like this is all gatekeeping now and I don't like that thought. I'm trying to understand. If anybody would try to be constructive and explain in more depth, that would be nice. Especially seeing as this is the top discussion on this repo and nobody has given a solid use case or in-depth reason for implementing things like this yet.

[SimonMarquis]

First, I would suggest you to get off your high horse! There are no such "people who know" inner circle group, don't try to fool anyone here. Try to be a bit more respectful.

Then, if you refute even the description given by the Gradle developers regarding the purpose of convention plugins, then I guess we can help you understand it further.

[jari-kuipers]

You being this rude doesn't exactly help do away with the gatekeep-feeling that I'm getting from this discussion. In no way was I disrespectful in my last message and I find your reply to be highly defensive.

I think you also misunderstood what I said. Telling someone "if you don't understand yet, then your project's scale isn't there yet" is definitely giving off the feeling of an "if you know, you know" situation, which is not constructive if you want people to understand why things are done the way that they are. I never said that there are such groups, I said that by saying what you said, you are giving off the feeling that there are.

If these decisions were made because they solve some problem, then I want to know what kinds of problems they solved because I don't see how they solve more problems than they cause in this situation.

I suggest we let someone else join this discussion if we are not going to talk about architecture.