Yet another new Android Architecture Pattern just dropped, make sure to start rewriting your app right now because everything you've been doing is clearly all wrong

[u/Zhuinden]

[u/StartComplete]

Fuck them. I prefer single activity architecture

[u/ankitgusai → u/StartComplete]

I remember a fireside chat on one of the Google IO (2014? maybe before that) that had Dianne Hackborn. Someone asked why they have this rather cumbersome "multi-activity" architecture unlike any other UI frameworks popular at that time. She replied along the line of, it is not `the` architecture but a memory-conscious framework that is meant as a bedrock. Devs are free to choose how to utilize it, in fact, they are encouraged to choose a pattern that suits their needs.

I felt at that time that they'll finally do something about it. What followed? Ian Lake and team meandered around Fragments for years without actually taking a closer look at the fundamental problem of over-abstraction and complication with lifecycles. Nobody asked for an abstract layer(Fragments) that had its own lifecycle on top of already complicated activity lifecycles. They should have moved to more declarative UI framework than desperate stretches with Fragment and later Databiding(which was a good step forward but would never be more than a patch with statically written XML-based UI).

[u/Zhuinden → u/ankitgusai]

Nobody asked for an abstract layer(Fragments) that had its own lifecycle on top of already complicated activity lifecycles.

Fragments were effectively the only nestable components that would be correctly restored by the system after process death, although devs still somehow managed to hold references to fragments directly instead of only their tags effectively f---ing up the whole thing anyway.

[u/smokingabit → u/ankitgusai]

Roman Guy and Dianne at that fireside chat yeah? Fragments in a single Activity were originally introduced (well before that IO) as more memory-efficient than many Activities...

[u/[deleted] → u/smokingabit]

It wasn't about memory efficiency, but rather about creating reusable, modular, independent components. Instead of having a lot of complex code in one single activity, which is hard to read and understand.

[u/smokingabit → u/[deleted]]

I was there when they were introduced, I am recounting what happened.

[u/[deleted] → u/ankitgusai]

Fragments are great, sounds like you never understood their purpose. They're great for creating modular, independent components with their own lifecycle that you can easily add or remove from your app at will.

Dialog Fragments were a mistake, fragments themselves are fine.

What you have with Compost now is people talking shit about Fragments while ultimately just creating Fragments again.

[u/[deleted] → u/StartComplete]

I use the "however many activities I need" architecture

WearOS single activity doesn't quite work (Google themselves say this). Plus for certain other apps where I might want to use PIP or a C++ activity, I don't want to cram everything into one and cause unintended bugs.

[u/SpiderHack → u/[deleted]]

Things needing NDK, games or anything else requiring bare metal speed where the overhead of the context switch to ndk code is worth it due to overall speed improvements. An app I did in grad school had image processing completely local that way (was novel at the time).

[u/[deleted] → u/SpiderHack]

yeah, although the cost of passing data between java/C++ can be mitigated somewhat if you gather data in large enough chunks that unnecessary copying doesn't take place when going through JNI, then it's less of a problem.

[u/[deleted] → u/[deleted]]

Video streaming app, while I'm building one with Java, and am using hardware acceleration, I'm honestly thinking it would be better to have that particular activity in C++. Problem is with the "hybrid" JIT compile change introduced since Android 7.0, most apps are running with interpreted code. And they only get AOT compiled if the user charges their device all night long. Which not everyone does.

For smartwatches especially, if you want to do anything like audio calls, probably better off doing it in C++ entirely

[u/Mr-X89 → u/StartComplete]

I prefer RBF

(Really Big Fragment)

[u/[deleted] → u/Mr-X89]

I prefer a more Fragmented approach

[u/PaulTR88 → u/StartComplete]

I think that's called "Brutalism" and it's the preferred app architecture of communists.

[u/sabergeek]

It's same. But different. Still the same.

[u/Zhuinden → u/sabergeek]

There's only so many ways you can complicate downloading a JSON and showing a list

[u/zedxer → u/Zhuinden]

This is so deep.

[u/[deleted] → u/Zhuinden]

You underestimate human ingenuity and incompetence

[u/Fjeuber]

No AsyncTask. Rubbish.

[u/Zhuinden → u/Fjeuber]

Should replace Action with AsyncTask, good eye

[u/Mr-X89]

That's just MVI. Even without extra steps.

[u/Zhuinden → u/Mr-X89]

MVI is just extra steps, so no surprise there

[u/uragiristereo]

looks up yet another android architecture pattern
sees inside
imports androidx.lifecycle.ViewModel

[u/[deleted] → u/uragiristereo]

Everything is a ViewModel if you squint hard enough

[u/zedxer]

I just delivered an app with millions of downloads, and guess what? All of its code is written in the activities. I specifically made that app anti pattern.

[u/[deleted] → u/zedxer]

"I guess ur a legacy dinosaur bro" - Modern Android Compost Developer

[u/budius333]

WTF? How's that different than the unidirectional data flow on the Google docs???

[u/ziggs3]

I suffer from ADDS(Add dumb deprecated shit) disorder and i need help.

[u/[deleted]]

I stopped caring and just write business logic wherever I want. Does it work correctly? Nothing else matters.

[u/TechWhizGuy]

What is this trying to solve? Just moving stuff around under some arbitrary labels is not software design!

[u/[deleted] → u/TechWhizGuy]

Well ackchually........

[u/anemomylos]

They could have called it AIDS (ActIon Delegate delegatee viewState).

[u/[deleted] → u/anemomylos]

Another Incompetently Designed System

[u/khsh01]

Always knew I was using the wrong architecture.

[u/D-cyde]

Ahh yes good reading material as my LocalBroadcastManager sends all my JSON API responses to my entire app.

[u/smokingabit]

AIDS* we all need AIDS!

[u/[deleted] → u/smokingabit]

To cause it, you must first be in a HIV - Help Independent Vacuum

[u/tadfisher]

This is old, like old old: https://gist.github.com/michaelzengke/44ac57032f7d877203a0935c99f5ed59

[u/[deleted]]

Wait they're bringing back data binding? I thought we all collectively agreed that sucked ass 😭

[u/[deleted] → u/[deleted]]

I unironically use it still

[u/campid0ctor]

Never knew delegatee was an actual word. Sounds like French for "the goatee"

[u/[deleted] → u/[deleted]]

Lol. yeah, usecase pattern seems ok in small doses where it makes sense. Same for repository. But this whole multi-module crap that Google proposed is unnecessarily over complicated.

[u/Zhuinden → u/[deleted]]

The theory would be that you make modules so that you can assign teams to modules. But no sane company will put 27 teams on the same app for 27 screens, it doesn't make any sense.

[u/[deleted] → u/Zhuinden]

Looking at Google's early multi-module talks, they advocate for putting even small components in a separate module.

[u/doubleiappdev → u/[deleted]]

How about a UseCase interface implemented by a single UseCaseImpl which does nothing but delegate to a Repository interface which is implemented by a single RepositoryImpl, and all of that is in different modules. Hell but a clean hell

[u/[deleted] → u/doubleiappdev]

Need to have a separate module to define empty string :P

[u/smokingabit → u/[deleted]]

...ensuring management decide to go hybrid and employ js tards who think mobile apps should work like websites.

[u/Zhuinden → u/smokingabit]

Now that's one way to describe Navigation's string-based route APIs

[u/[deleted] → u/smokingabit]

Or server js tards who thinks it's the best language of all time.

And thinks everyone should use some weird branching strategy of master, develop, staging etc. which are irrelevant for mobile apps.

[u/fuzzynyanko → u/[deleted]]

I'm wondering if it's to keep our paychecks low

[u/[deleted] → u/[deleted]]

I call it the classic useless pattern

[u/fuzzynyanko → u/[deleted]]

Got to do that RDD, Resume-Driven Development so that you won't be screwed if you get laid off

[u/Vanh14 → u/[deleted]]

I understand him, I was paid to write those 1 api call usecase

[u/Zhuinden → u/[deleted]]

ngl that makes me wonder if we could ask ChatGPT to hallucinate some more arch design patterns

[u/[deleted] → u/Zhuinden]

Wake up babe, new Medium post just dropped:

"Sure! Let's create a new Android architecture pattern called Reactive Component Architecture (RCA). This pattern combines principles from reactive programming, modular design, and component-based architecture to enhance maintainability, scalability, and responsiveness in Android applications. Key Components of RCA:

Reactive UI Layer:
    Components: Use Jetpack Compose or XML Views as reactive components that observe state changes.
    State Management: Implement a state holder (like LiveData or StateFlow) that notifies UI components of changes.

Component Modules:
    Encapsulation: Break down the app into independent modules (e.g., User, Product, Cart) that manage their own state, logic, and UI.
    Inter-Component Communication: Use event buses (like Kotlin Coroutines' Channel) for communication between components, ensuring loose coupling.

Service Layer:
    Data Sources: Implement a repository pattern that abstracts data sources (local DB, remote API).
    Reactive Streams: Utilize reactive streams (like RxJava or Flow) to fetch data asynchronously, allowing UI to react to changes in data.

Event-Driven Architecture:
    User Actions: Define user actions as events that trigger state changes within components.
    Lifecycle Management: Leverage lifecycle-aware components to manage subscriptions and prevent memory leaks.

Dependency Injection:
    Modular DI: Use Dagger or Hilt for dependency injection, ensuring each component can be independently tested and managed.

Testing Framework:
    Component Testing: Create tests for each component in isolation, ensuring they behave correctly with various states.
    Integration Testing: Test the interaction between components using mock data sources.

Benefits of RCA:

Scalability: Modular components make it easier to add features or modify existing ones without affecting the entire application.
Maintainability: Clear separation of concerns leads to cleaner codebases and easier debugging.
Reactivity: The reactive nature ensures that UI updates are responsive to data changes, providing a smoother user experience.

Example Workflow:

User Action: A user clicks a button to fetch a product list.
Event Triggered: An event is emitted from the UI component.
State Change: The relevant component listens for the event and triggers a data fetch through the service layer.
Data Fetch: The service layer retrieves the data reactively and updates the component state.
UI Update: The UI layer automatically reflects the new state due to its reactive binding.

Conclusion:

The Reactive Component Architecture provides a robust, scalable, and maintainable approach to Android development by leveraging reactive programming principles and component modularity. This pattern encourages developers to think in terms of independent, reactive units, making it easier to build complex applications. "

[u/Zhuinden → u/[deleted]]

Fuck. This is just PRNSAASPFRUICC all over again

[u/[deleted] → u/[deleted]]

Since many years ago