# antipattern

Published articles for antipattern.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Structural and navigation anti-patterns in modularized Android applications

DevFeed: [Structural and navigation anti-patterns in modularized Android applications](<https://devfeed.tech/articles/structural-and-navigation-anti-patterns-in-modularized-android-applications-25933.md>)

Original publisher: [Read original article](<https://proandroiddev.com/structural-and-navigation-anti-patterns-in-modularized-android-applications-a7d667e35cd6?source=rss-7a8d96da8cb6------2>)

Author: Gabor Varadi

Published: 2020-12-25T11:38:05Z

Content type: article

Language: en

Sources: [Stories by Gabor Varadi on Medium](<https://devfeed.tech/sources/stories-by-gabor-varadi-on-medium.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [modules](<https://devfeed.tech/topics/modules.md>), [navigation](<https://devfeed.tech/topics/navigation.md>), [Code](<https://devfeed.tech/topics/code.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [RxJava](<https://devfeed.tech/topics/rxjava.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [antipattern](<https://devfeed.tech/tags/antipattern.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [clean-architecture](<https://devfeed.tech/tags/clean-architecture.md>), [code](<https://devfeed.tech/tags/code.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dagger-2](<https://devfeed.tech/tags/dagger-2.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [domain-driven-design](<https://devfeed.tech/tags/domain-driven-design.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [modularization](<https://devfeed.tech/tags/modularization.md>), [modules](<https://devfeed.tech/tags/modules.md>), [navigation](<https://devfeed.tech/tags/navigation.md>), [navigation-architecture](<https://devfeed.tech/tags/navigation-architecture.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>)

### AI overview

This article examines structural and navigation anti-patterns in modularized Android applications. It traces the history of Android Clean Architecture and argues that organizing an application around top-level data, domain, and presentation modules can be problematic, particularly when the structure is adopted from educational examples rather than feature-based organization.

### Source excerpt

Structural and navigation anti-patterns in multi-module and modularized applications: The case against "Android Clean Architecture" and the "domain" moduleTop-level "domain" module is a code smell. Merry Christmas to all! The subject of this article is one that has been on my mind for a very long time. After all, "Clean Architecture" is often seen as the end goal, the hallmark of the finest of Android application code structure -- it is the best of the very best. The name itself, "Clean Architecture", signals that it's a good thing ~ after all, who wants to work with "messy" code in comparison? Of course, the title of this article shows that this isn't the conclusion we'll come to. The following tweet is closer to our final evaluation -- let us analyze why it might be accurate. Clean architecture + Android for us was like building a beautiful sailing boat in your backyard because someone on TV convinced you it's better for crossing the sea than an inflatable, while you live in the mountains and also your house is on fire. https://t.co/iGqy25wk7m The history of "Android Clean Architecture"The origins To understand "Clean Architecture" as done on Android, we must trace it back to its roots, and where/when it was made popular in the first place. As far as I'm aware, it dates back to 2014, the original proposition in "Fernando Cejas: Architecting Android... the clean way?". It was a highly influential article, as it revolutionized the structure of Android apps. Code that is actually separated across layers (back when Fragments were untrustworthy, and all code was in OS-level components), rather than just throwing everything into 2000+ line Activities? A pioneer of its time. One interesting decision however in the representative sample code was that in order to signify the strict separation of layers, these layers were each separated from one another using top-level Gradle modules, each labeled data, domain, and presentation. As we will see, this is the downfall of the sampl

## Calendar Tetris is an antipattern

DevFeed: [Calendar Tetris is an antipattern](<https://devfeed.tech/articles/calendar-tetris-is-an-antipattern-32296.md>)

Original publisher: [Read original article](<https://jack.ofspades.com/calendar-tetris-is-an-antipattern/>)

Author: Jack Tarantino

Published: 2017-06-12T17:55:10Z

Content type: opinion

Language: en

Sources: [Jacopo Tarantino](<https://devfeed.tech/sources/jacopo-tarantino.md>)

Topics: [meetings](<https://devfeed.tech/topics/meetings.md>)

Tags: [agile](<https://devfeed.tech/tags/agile.md>), [antipattern](<https://devfeed.tech/tags/antipattern.md>), [best-practices](<https://devfeed.tech/tags/best-practices.md>), [calendar-tetris](<https://devfeed.tech/tags/calendar-tetris.md>), [meetings](<https://devfeed.tech/tags/meetings.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [scheduling](<https://devfeed.tech/tags/scheduling.md>)

### AI overview

The article argues that "Calendar Tetris"--an overloaded calendar requiring constant rescheduling and causing frequent double-booking--harms lunch breaks and productivity. It discusses how meetings and interruptions can contribute to cognitive errors and lost working time, and questions the assumption that managers and senior employees must attend every meeting.

### Source excerpt

It's time that we took back our work day from our calendars and Calendar Tetris is the first thing that has got to go. Calendars are a tool and like every tool they should be used appropriately. What is "Calendar Tetris"? Does your calendar look like a Jackson Pollack painting?

## Avoid static imports

DevFeed: [Avoid static imports](<https://devfeed.tech/articles/avoid-static-imports-37681.md>)

Original publisher: [Read original article](<https://carlosbecker.com/posts/avoid-static-imports/>)

Author: Carlos Alexandro Becker

Published: 2015-07-05T00:00:00Z

Content type: opinion

Language: en

Sources: [Carlos Becker](<https://devfeed.tech/sources/carlos-becker.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>)

Tags: [antipattern](<https://devfeed.tech/tags/antipattern.md>), [avoid](<https://devfeed.tech/tags/avoid.md>), [code](<https://devfeed.tech/tags/code.md>), [java](<https://devfeed.tech/tags/java.md>), [oop](<https://devfeed.tech/tags/oop.md>), [readability](<https://devfeed.tech/tags/readability.md>)

### AI overview

The article argues that Java static imports should be used sparingly because overuse can obscure where methods and members originate, pollute the namespace, and reduce code readability and maintainability. It recommends importing only a small number of frequently used static members when appropriate.

### Source excerpt

There are a lot of Java API's and Frameworks which rely on static methods and the sort. Arguably, this is a bad OOP practice, but let's not enter this particular subject just yet.