God Activity Architecture — One Architecture To Rule Them All

You and all your friends after using GAA! — Photo by Helena Lopes on Unsplash

In modern Android Development, everyone is trying to push a different architecture on you. I’m about to do that too. In this article, we’ll walk through the God Activity Architecture (GAA), the pros, and the cons.

What is it?

God Activity Architecture is when you place all of your code inside of the activity related to that feature / screen. That’s it. It’s that easy. Can you explain your architecture in one sentence? Probably not.

Pros:

1. Code in one Place

With the GAA, all of your code is placed in the single activity responsible for that screen / feature. Because of this, you and your team do not have to waste time navigating around your app — everything is right there. Similarly, this removes the mental strain of trying to name other classes, since you will only have activities.

2. Low Learning Curve

The GAA has an incredibly low learning curve. The learning curve is so low on GAA because all of us already know it. This is the first architecture all android developers use naively, and rightfully so. The sheer fact that new developers use this architecture without further research is the exact definition of intuitive. The only actual paradigm in android with an easier learning curve than GAA is setting up a multi-modularized app with Dagger 2.

3. Unable to Unit Test

GAA makes unit testing your code near impossible. It is a common misconception among Android Developers that your app should be testable. Unit tests do not actually make your company money — features do. Why would we waste time writing unit tests when we could write additional features, faster? Oftentimes product owners will attempt to encourage your team to write unit tests to build confidence, reduce bugs, and assist in future refactors; but this is a farce. Once you’ve adopted GAA, unit testing will be nearly impossible.

Cons:

After thorough analysis and multiple GAA app implementations, we have not yet came across a single con at this time.

Oftentimes developers that are new to an architecture don’t know which “layer” of the architecture to place certain code in. Let’s take a look at an MVP diagram compared to a GAA diagram:

Comparing MVP architecture (left) to GAA (right). It’s easy to see how the multiple nodes in the MVP diagram make for a convoluted architecture.

There are never any questions about where to place what code while using GAA. The answer is always: Activity.

The following diagram is another alternative diagram widely accepted among the Android community representing the GAA.

Alternative GAA diagram commonly used among the Android community.

The image of spaghetti is representative of the GAA for the following reason:

• The spaghetti noodles are “tightly coupled” — meaning, the noodles are intertwined and difficult to pull apart. With GAA, your code will be tightly coupled, meaning the code is firmly tied together, making it difficult to refactor your code. We don’t want anyone refactoring our code, since it already works. Tightly coupled code also runs faster.
• You can use your finger to follow along a spaghetti noodle to see where it leads to. Similarly, with GAA, you can follow along the code easily since it’s all in one file.

As a final note, I would like to mention that GAA is best utilized when developing alone. Because of this, feel free to fire your entire team besides you — this architecture is so good that you only need one developer to maintain it. It’s a too many spaghetti cooks in the kitchen situation; Cheers!